I recently had to solve a similar problem on a project and did so in a different manner, but with largely the same results, using *nix's `envsubst` and nginx's `subs_filter`. I really like the SSI approach, but I'll share our approach as well as it covers it slightly differently.
We had a set of static frontend apps (React) that were built in CI, and which had to support being served either out of S3 buckets in a variety of environments, or in walled-off on-prem environments, and therefore had to support a variety of API endpoint URLs. There was an 85% likelihood that the endpoint URL would be one main one (our primary distribution platform), but the other 15% could be anything.
I set up a global variable attached to `window` (gasp!) in the frontend's index.html that would point to the API endpoint, and by default our CI build would spit out the common scenario URL. When doing local development, the URL was supplied via an environment file, which worked perfectly.
For all other production scenarios we served the app out of a Docker container. At container launch, we passed in via env vars the proper endpoint URL, and a script would absorb the passed env var and embed it into the nginx config file using `envsubst` like the OP's article. This config file was configured using `subs_filter` to find our global variable in the index.html file and replace its contents with that of the env var, which was now hardcoded in a sense into the file.
This setup was a bit convoluted, but it allowed us to not have to change anything while in local development, be able to change the endpoint URL each time the container was launched without any rebuild, and didn't require any additional requests to a configuration script. It was the best fit in our situation to allow local development to continue unchanged while also supporting pretty much any future scenario.
Was looking at doing something similar but settled on a slightly different approach:
1. Bundle the app image with a “container.json.template”
2. Have the UI request this file first, along with a preload in the head
3. Use Nginx envsubst to populate the config.json from env vars on container start
It’s an additional HTTP request and templating JSON via string interpolation isn’t fun but it was quite simple and kept the build clean with config injected at run time.
Given the interpolation problem (I.e chaos when someone uses a number value and it’s undefined), I’d probably ditch env subst and perhaps do something else to build the JSON.
We had a set of static frontend apps (React) that were built in CI, and which had to support being served either out of S3 buckets in a variety of environments, or in walled-off on-prem environments, and therefore had to support a variety of API endpoint URLs. There was an 85% likelihood that the endpoint URL would be one main one (our primary distribution platform), but the other 15% could be anything.
I set up a global variable attached to `window` (gasp!) in the frontend's index.html that would point to the API endpoint, and by default our CI build would spit out the common scenario URL. When doing local development, the URL was supplied via an environment file, which worked perfectly.
For all other production scenarios we served the app out of a Docker container. At container launch, we passed in via env vars the proper endpoint URL, and a script would absorb the passed env var and embed it into the nginx config file using `envsubst` like the OP's article. This config file was configured using `subs_filter` to find our global variable in the index.html file and replace its contents with that of the env var, which was now hardcoded in a sense into the file.
This setup was a bit convoluted, but it allowed us to not have to change anything while in local development, be able to change the endpoint URL each time the container was launched without any rebuild, and didn't require any additional requests to a configuration script. It was the best fit in our situation to allow local development to continue unchanged while also supporting pretty much any future scenario.
Hope that might spur some ideas for someone.