Many React Apps are created using the NPM (CRA) package. It creates apps without build configuration and that is more than enough for many use cases. A simple google search would give you a good idea about the pros and cons of this approach. Some interesting articles: , and . SPA Create React App one two three One of the main advantages of CRA is how easy it allows you to build apps as static/minified files. Once you have a set of static files, you could use any HTTP Server for serving the app, e.g. apache, nginx, S3. What I just commented above sounds great. However, because everything is static, adding dynamism to the app can be a challenge. The model assumes that any dynamism comes from outside, usually an API. That works well for most cases, but sounds like an overkill for config files. A common challenge to face is when you need to specify different backend(s) base URI(s) depending on the environment. For example: could be or BACKEND1_BASE_URL https://mybackend-dev/api/v1 https://mybackend/api/v1 You could overcome the challenge mentioned above using and deploy the app to (TAS) using the , super easy! Take a look at the following . Custom Environment Variables Tanzu Application Service Static Buildpack bash snippet However, one important drawback of the commented approach is when you need to maintain/store artifacts per build. You’d end up with a nightmare of different versions per environment that can significantly increase your inventory management complexity. Just imagine: , , and ! myapp-dev-v1.0.zip myapp-sit-v1.0.zip myapp-uat-v1.0.zip myapp-prod-v1.0.zip There are other possibilities you could use for avoiding versioning hell. Some related to custom hostname resolutions or proxy intermediaries (e.g. reverse proxy). In this post I want to focus on a proxy intermediary approach that relies on different files for each environment. In order to better explain the approach, I’ve decided to code a simple React App and deploy it to TAS. Why TAS? Because I truly believe there is no easier way to deploy/maintain your app! You have all the goodies plus the tiles and accumulated app development knowledge from Pivotal and VMware. Cloud Foundry The approach You can find the app live and the source code . Excuse the poor CSS and UI taste! I just want to demo how the config files can be changed via environment variables. If you run the app locally, you’d see: and if you run it on TAS: . here here Welcome, Dev! Welcome, Prod! Following the detailed explanation of all the changes introduced to the React App commented above, created initially with: npx create-react-app Configure env files Declare a : new config file in your index.html … … < = > script src "%PUBLIC_URL%/config.js" </ > script And then add the config files for running the application locally ( ) and for different environments (e.g. ). When you run the application locally ( ) it just uses the file. config.js prod.js npm start config.js Configure NGINX I’m using the instead of the because the approach requires changes to the file. NGINX Buildpack Static Buildpack nginx.conf You could find the full , specially important for this explanation the following lines: nginx.conf here …
location /config.js { $config_file ;
  try_files / config_file = ;
}
… set "{{env " CONFIG_FILE "}}" $ 500 NGINX would serve the config file depending on the value of the environment variable , for example: . See the CONFIG_FILE prod.js manifest.yml In order to deploy the app, the easiest part if you’re using TAS, you’d run: cf push -f manifest.yml Final words Hope this post helps! At least, I expect it triggers some thoughts :-) Some benefits: Eliminates multiple artifacts per environment. Reduces ops complexityRespects the principle. Frontend config stays at the frontend.Eliminates endpoints for getting App Config. Separation of Concerns Some challenges: You need HTTP Server config! If you just want to use S3 or similar, then it wouldn’t be feasible.A file named config for the local configuration might cause confusion. I still don’t have a final word about “the way to go”. I guess it depends. In any case, certainly this approach could keep your app simple when handling multiple environments, especially if you need to create versions and don’t want to generate several files per environment. Read behind a paywall at https://medium.com/javascript-in-plain-english/deploying-multi-environment-react-apps-with-tanzu-application-service-7e332416165

Apache

Google

Super

Python Cheatsheet: Mock Object Library

Managing Multi-Environment Configurations For React Applications with Tanzu

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Building a To-do List App with Python: Data Access Layer with SQLAlchemy

Avoid complex infrastructure when building simple things

Cloud-Native Buildpacks, BuildKit, and Container Images: Qu'est-ce Que C'est?

Common Mistakes to Avoid When Migrating

How to Script the CF API With `CF OAUTH-TOKEN` and Python

Spin Up a BOSH VM Faster Using BoshLite

Building a To-do List App with Python: Data Access Layer with SQLAlchemy

Avoid complex infrastructure when building simple things

Cloud-Native Buildpacks, BuildKit, and Container Images: Qu'est-ce Que C'est?

Common Mistakes to Avoid When Migrating

How to Script the CF API With `CF OAUTH-TOKEN` and Python

Spin Up a BOSH VM Faster Using BoshLite

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps