Solution to provide Angular app deployment flexibility

[ActionAnalytics]

Routing information is being placed in at develop time in the Angular api service files. This makes deployment involve app code changes. Here are the hardcoded values:

https://github.com/bcgov/nrts-prc-admin/blob/c9801020d838d4eed869d3a0955efbe20b529046/src/app/services/api.ts#L154

Background

This has been a challenge to address up to now in API backed Angular front-ends (architecture diagram) that are built using the s2i built approach (build diagram), which creates a high performance web server image but at the cost of extra build complexity.

Solution

Here is a simple pattern from Eagle EPIC that solves this in a few lines, meeting the https://12factor.net Factor III, "Store config in the environment" and allowing the app to be deployed based on settings alone. It handles the more complicated s2i builds (other projects that expose environment settings in a similar pattern like MDS use a much simpler build process).

Please see the following areas of code:

1. Here's where the Angular app consumes the settings from the server and replaces the hardcoded routes
2. Make sure this line gets placed in the HTML head as it needs to run prior to app load
3. Create the landing point for the environment variables at server build time
4. When the pod starts up, and on every subsequent redeployment, set the variables. Javascript was chosen over JSON as it's a direct plugin for the existing variables in api.ts without having to do overhead to handle the JSON. MDS uses JSON.
5. Pass the environment variables along
6. Settings exposed in OpenShift

You can check if your settings are exposed by (if you used the same pattern as above) visiting https://your-front-end-url/publicServerEnvironmentSettings.js

And remember to set your app to redeploy on environment variable change. That way your app will get new environment settings without needing a build.

Cheers!

PS. If you have a discrete admin site, the above solution uses the same pattern with slight variations on the path (/admin in the server build and image startup script but html stays the same). Note the use of uniquely named client-side variables to avoid collisions (public vs admin).

[basilv]

Nice solution! I'd use an OpenShift configMap mounted as a volume instead of the startup script within the container (which I believe assumes a non-read-only filesystem).