Configuration Management for React App

4 min readJul 3, 2021

Context

Configuration management is essential for every application that will be deployed into multiple environments, which is pretty much the majority of Apps and APIs. Focusing on React Apps in this note, we will cover how to store configurations in your APIs, how to configure them, and finally how to read them.

By the way, this topic belongs to the series to set up a Single Page Application using React, Redux and Asp.NET 5.0.

Configurations vs Secrets

Configurations are different from secrets. Secrets are values that should be protected and never be stored as plain text sitting in your repositories along with the rest of your code. The focus of this note is merely configuration management, and not secrets. Also you need to keep in mind, that everything which is shipped with your React application, is going to be accessible publicly. Hence in a nutshell, no secret for front end apps.

Configuration Types

There are different types of configurations in a React application:

1. Environment Dependent

Those configurations that change from one environment to the other. A good example would be FQDNs (Fully Qualified Domain Names). A URL in your local dev environment, might point to https://localhost:6500, however the same URL in production, would point to https://pellerex.com.

1.1 Storing Environment Dependent Configs

The way we manage these types of configurations is through env files which you will need to have a separate one for each environment.

Typically you would have:

.env: for your local dev environment
.env.test: for test environment
.env.production: for production

When the application is packaged for each environment by WebPack, the right configuration file will be picked up. The content of such file is key-value pair, such as below:

No Secrets Here!

The content of .env files in any environment should be considered public knowledge, and there should not be any risk in exposing them to public.

Key Names

The key names need to start with REACT_APP_ for them to be accessible in your js code.

For .env.(environment), you should have the same set of keys in each file, with different values specific to that environment.

1.2 Reading Environment Dependent Configs

To access these config values, we simply use process.env.(key-name) in any js file; an example would be REACT_APP_RECAPTCHA_SITE_KEY.

Note
Configuration, plumbing and troubleshooting your software foundation take a considerable amount of time in your product development. Consider using Pellerex which is a complete foundation for your enterprise software products, providing source-included Identity and Payment functions across UI (React), API (.NET), Pipeline (Azure DevOps) and Infrastructure (Kubernetes).

2. Static Configurations

Static configurations are the ones that don’t change from one environment to the other. Examples would be routes (/v1/email), telephone numbers, company names, messages and copies, etc. We simply store these values in a separate file, as they might be subject to change from time to time, and this makes it easier to find and change them.

2.1 Storing Static Configuration Values

One way to manage these configs, is to store them in simple json file, such as below:

JSON structure also enables you to store the values in a specific hierarchy which makes it easier to manage.

2.2 Reading Static Config Values

All you need to do to access such config values, is to import it in your .js files and access the values like any other json object:

import config from '../../config.json';

and then I can write:

config.locations.fetchCountriesUrl

3. Constants

The other alternative to manage static values in code, is through JS objects. You typically manage two types of values using JS objects:

To store/read those values that are highly unlikely to change from time to time, but you want to keep them separate from your code anyway
To store/read those values that won’t be stored in JSON files as they are (and not as strings), such as Regular Expressions (RegEx)

An example would look like below, and you can read them exactly like Option 2, as above:

Pellerex Foundation: For Your Next Enterprise Software

How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.

Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.

Check out Pellerex and talk to our team today to start building your next enterprise software fast.