As a freelance web developer for many small and large companies, having developed many web applications on back-end as well as front end, there has been one problem that has always remained challenging — configuring the web application.

There are two types of web application configurations, one for the front end that needs to be public and one for the back-end that needs to be private. The public configurations may be kept in the front-end source code. They contain information like OAuth client id for third-party sites, base domain name, environment name, etc. The back-end configurations contain items like secret keys for 3rd party integration, environment names, database connection keys, secrets, etc.

These days, the most popular method of storing configurations is in a JSON file. This file can be different for front end and back end application.

Configuration Storage

For back end application, the configuration file can be kept in these locations –

• Root of source code folder
• File location in application Server
• Cloud based configuration source
• Database
• Environment Variable

There are pros and cons of keeping the configuration in any of the above locations. To understand the pros and cons of each location, we need to first understand the how applications use configurations and what challenges are faced in configuration storage, retrieval and change.

Back-end Configuration Lifecycle

Major events in the application lifecycle that are concerned with configuration are as below —

• Initial Load — Getting configuration for database, environment or cloud secrets
• Module Load — Sub-modules loading their own specific configurations after application initialisation
• Configuration Change — A change in configuration, notified through an event or through a reload call, causing configuration to change or reload
• Continuous Read — Some applications read configuration before each request to make sure only the latest configuration is used

A back-end application could be a service running permanently on server such as Apache, Nginx, MongoDB, or it could be an application serving users on port 4000 such as a node.js web application. It could be a microservice running on AWS lambda. Any application needs configuration to initialise and configure itself. When a change of configuration is required, some applications can be restarted after change, while other applications are required to be online without being restarted. For some applications, the configuration managing team is different from the application development team. Applications that can be restarted after a configuration change, generally store configuration in a file in same server, or environment variable. Examples of these are services running in a linux machine. Web applications sometimes need to be live 100% and cannot stop for configuration change. Such applications can store configuration in a database. The reason to store configuration in database is also developer specific, e.g. systems like Moodle, WordPress etc. store database configuration in a file and then the rest of the configurations in a database. Configurations that can be applied without needing an application restart can be stored in database. Configurations that require a application restart need to go in a file. Initial secrets, like database connections, api secrets, cloud secrets are stored in a file so that system can make the first connection to a configuration store and then initialise the rest of the application.

In a web application, the handlers can either load the configuration all at once or read the configuration before serving each request. If the applications reads the configuration all at once, then change in configuration in live application will require restart of the application. For distributed application, it could mean that servers have to be restarted one by one. So the configuration cannot be applied to the whole application all at once and during the deployment of new configuration, some request will be served with old configuration. If the application reads the configuration before each request, then a change in configuration can be deployed almost instantly for all request handlers and the change will happen simultaneously for the whole application. This means that after a change in configuration, no requests will be served with old configuration. This is a major point to consider for application architects, lead developers and CTOs. Depending on the type of application, the decision to choose right configuration read method has to be taken carefully. Later change in this method could mean a complete re-write or a major refactoring of the application.

Challenges In Back-End Configuration Management

There are multiple challenges in managing the configuration of a web applications. These are described below.

Environment Management

Each environment can have it’s own specific configuration. Managing different configurations and making sure that configurations do not get mixed up is a huge challenge. A mix-up of stage and production environment can cause major damage to a company’s revenue. For managing different environment configurations correctly, tools like AWS AppConfig are useful. Application environment is generally the first environment variable that is supplied in the configuration, so that the rest of the configuration is correct. Some teams prefer to keep such information in different branches of the code repo, so that any change in environment configuration goes through PR review process and mistakes are caught before deployment.

Conflict in environments is another challenge. Local and dev servers might have much different configurations than stage, QA or production servers.

Secrets Security

Loss of secret keys could mean major financial or data loss for any company. There are many ways through which secret configurations could be lost –

• Keeping configuration in source code
• Keeping configurations in database and not having proper security with database configuration
• Passing configuration in environment variables and logging environment variables in the application
• Keeping configuration in files and not having proper server security, allowing read access to unauthorised users or processes
• Allowing access to configuration stored in database to non-authorised users in a web application

To keep secrets safe, many safety practices are developed that apply for each type of configuration storage method.

Configuration Change

For each type of configuration method, the change in configuration is a major operation. For an application deployed over multiple servers across global locations, making configuration change requires use of server configuration management and deployment tools. Change could be different for each environment, so change deployment may have to be planned carefully. Wrong configuration can break a feature on the production.

Some modules may need to be reloaded on change of configuration. In this case, application needs to implement event based module reloading and listen to configuration change events.

Configuration Load Hierarchy

Some applications are written as modules and each module load has it’s own set of configurations needed. In this case, as per the hierarchy of module loading, the configurations have to be available.

Pros And Cons of Various Configuration Storage Methods

Source Code Repository

Use Case

Default configuration for initialisation and reference of an application are kept in the source code repo itself. This can be kept separate for different environments using code branches.

Pros

• Changes are clearly reflected in PRs
• Environments are easily managed
• Changes over time are recorded in history
• Change is recorded by user, allowing blame detection in case of mistakes

Cons

• Not a scalable method
• Secrets cannot be kept in source code, cannot be versioned

File Location

Use Case

• System services in web servers
• Applications hosted as container service
• Application that don’t require much configuration change over the service time
• Configurations that don’t need to be secured

Pros

• Configuration is clearly visible
• Automation is easier for changing configuration, making large scale deployment easier

Cons

• File and server access needs to secured to not lose secrets
• Application needs to restart or reload after change, which might cause downtime

Cloud Storage

Use Case

• Configuration for large scale deployment
• Configuration for serverless applications
• Secure configurations
• Configuration requiring automation

Pros

• Scalability, reliability, availability, security
• Modularity for serverless applications
• Separation of concern between application and configuration

Cons

• Managing local or dev environments could be a problem
• Improper handling or bad access control may lead to secrets loss
• Deployment and environment management is additional work

Database Based Configuration

Use Case

• Open source web applications where configuration management is part of the application
• Third party integration requirements, e.g. wordpress modules have their own configuration and can declare more configurations
• Applications where downtime is not desirable
• Application where change in configuration must be effective immidiately

Pros

• UI can be easily created for configurations
• Change is immediately effective
• Server reload is not needed

Cons

• Database may not be encrypted
• Logging must be implemented to identify the user who made a change to configuration
• Authentication and Roles must be implemented
• DB Synchronisation has to be maintained in case a large application

Environment Variables

Use Case

• Small server initialisation secrets
• Environment settings and secrets

Pros

• Easily and quickly available
• Change is easy to deploy
• Can work with both continuously read configuration and one time loaded configuration

Cons

• Passing the variable may be insecure
• Access to environment variable must be secured
• Large configurations may not be passed a as environment variable