Angular application configurations. Best practices.

How to manage environment configuration files and targets

When you create your angular application with Angular CLI or Nrwl Nx tools you always have a folder with environment files:

<APP_FOLDER>/src/environments/
                       └──environment.ts
                       └──environment.prod.ts

You can rename environment.prod.ts to environment.production.ts for example, also you can create additional target-specific configuration files, such as environment.qa.ts and environment.staging.ts.

└──<APP_FOLDER>/src/environments/
                          └──environment.ts
                          └──environment.production.ts
                          └──environment.qa.ts
                          └──environment.staging.ts

File environment.ts is used by default. To use other files you should open angular.json and configure fileReplacements section in build configuration and add target blocks to serve and e2e configurations.

To build or serve your application with specific target run the following commands:

ng build --configuration=staging
ng start --configuration=staging
ng e2e --configuration=staging
Actually 
ng build --prod 
is just a shorthand for 
ng build --configuration=production

Create interface for environment files

Don’t use environment files directly, only through DI

Using global variables and direct imports breaks OOP approach and testability of your classes. So better variant to create service for injecting in your components and other services. Here is an example with possibility to use default value.

Distinguish environment configuration and business configuration

Environment configuration files should include only environment specific values like apiUrl. In best case environment configuration files should consist of just 2 properties:

export const environment: EnvironmentInterface = {
  production: true,
  apiUrl: 'https://api.url',
};

This files can include property to enable debug mode debugMode: true. Also you can add name of deploy server environmentName: ‘QA’ , but don’t forget that it is a bad practice for application to know anything about server it is working on.

Never put any sensitive information like passwords or secret keys in your environment files.

Other configuration values like maxItemsOnPage or galleryAnimationSpeed should be stored in other place, and in best case provided by some configuration.service.ts which can request backend endpoint or at least download config.json from assets folder.

1. Async configuration approach (use when config may be updated at runtime)

2. Sync configuration approach (use when you have constant config)

Replace environment files at deploy or at runtime

A lot of teams violate the “Build once, deploy many” DevOps rule by rebuilding the app for every environment instead of just changing the configuration and use the same build.

Don’t create separate builds with different configurations, use just one production configuration and replace needed values at deploy or at runtime. There are several ways to do it:

1. Add placeholders in environment files that will be replaced at deploy time

export const environment = {
  production: true,
  apiUrl: ‘APPLICATION_API_URL’,
};

At deploy time string APPLICATION_API_URL should be replaced with corresponding api url, i.e. http://api.your-app-server.com

2. Use global variable and inject it using docker volumes

export const environment = {
  production: true,
  apiUrl: window.APPLICATION_API_URL,
};
// in index.html before angular app bundles
<script src="environment.js"></script>

Thanks for reading, feel free to contact me for any related questions or corrections.

— — — — — — — — — — — — —

🚀 Follow us on Medium, Telegram or Twitter to read more about Angular, Software architecture, Best practices building web applications!