Change for loading UI Env Vars

[danoswaltCL]

Is your feature request related to a problem? Please describe.
As a dev I want to load env vars from the docker container OS at build time so that it's easy to manage different build configs for local, dev, staging, and production environments separately, the same way the backend does via AWS config files.

This is an enhancement request that springs from a bug: Currently (Angular 8), frontend vars are partially loaded from environment.ts files that are part of the source code, and partially via environment.json file that is statically loaded from S3. This merged approach of compiling some of the environment vars from typescript source code at build time (environment.ts turns into environment.js) and then assigning additional fields to that js object later no longer flies the way modules compile in Angular 13.

Even if this was not now breaking, it's not an ideal setup. The environment.ts files live with the source code and are compiled during the angular build, and thus require a code change to get deployed. The enviroment.json file gets around this by getting statically loaded after the build, but that means it is always blocking the app from loading as it completes an extra network request. Best would be to use the docker container OS to load in things at build time if possible.

Describe the solution you'd like
Ideally, something like this: https://indepth.dev/tutorials/angular/inject-environment-variables, which describes a way to consume node env vars the same way the backend does.

This would 1) separate environment configs from source code, 2) eliminate loading extra assets in the browser, 3) enable us to manipulate env vars for backend and frontend in same way.

Describe alternatives you've considered
If that scenario isn't so easy to get working, we should either completely load environment configs in typescript, or completely load them via fetching them at runtime. I think I would prefer the latter, since this would at least prevent needing to rebuild and deploy anything to see env config changes (just change the static file, and refresh). If we went this route, we should not continue to use jQuery and window object in the index.html to accomplish this, the angular way is to use APP_INITIALIZER, which blocks the app from loading some initial data is fetched.

Additional context
Apparently this is something that create-react-app allows, and vue-cli can too, but angular has yet to incorporate this much-asked-for feature: angular/angular-cli#4318

[jerith666]

cc @kschaefe

[danoswaltCL]

@mfugate1 @jerith666 @kschaefe @VivekFitkariwala @ppratikcr7 @jreddig maybe someone can help me rationalize whether the change I'm hoping to do even makes sense:

I've got a branch where I can demonstrate being able to pull OS env vars into angular code environment.ts during the build process (not normally supported) via node process.env. The reason I want this is 1) so we can avoid hardcoding "environment" details into source code files (we're not really leveraging "fileReplacements" in angular.json to target actual environments anyway, just a "prod" vs "local" build), and 2) to avoid fetching environment details at runtime from browser from static environment.json file on S3 bucket (see above for the info on the exact scenario that got me going down this rabbit-hole).

Where I run into questions is whether I'm really solving anything or just adding complications. My goal is to emulate the process for backend somewhat, where we can change env vars in the config for that AWS environment and retrigger a new deployment without a code change (for example, flipping a boolean for some feature, etc).

It seems though that if I want to do this, I'll need to have env vars loaded into a github action runner during frontend build step, which would necessitate different build artifacts/actions for different environments, maybe those env vars are pulled from a file on that host env's S3 bucket...

When I type it out, I start to think that fetching env details from browser at runtime isn't such a bad approach, but utilizing github actions this way seems interesting, I need devops brains to help me think it through...

[jerith666]

This sounds very similar to what @kschaefe did for our internal cli-services in INF-1420 and related. I think it's best to wait and let him explain that though.

[kschaefe]

We use the environment.ts file and the standard replacement environment.prod.ts to handle this problem.

The base environment.ts file contains default values usable during development.

export const environment = {
  production: false,
  CUSTOMERS_API_URI: "//apis.qa-cli.com/services-fido/customers",
};

While the environmet.prod.ts file contains replacement values.

export const environment = {
  get production(): boolean {
    return String(true) === "%PRODUCTION%";
  },
  CUSTOMERS_API_URI: "%API_HOST%/services-fido/customers",
};

This allows for the production of a single artifact that can be deploy to any container. Part of the deployment process is to replace the variables (%...%) with real values and those values can come from process.env. @asheperak handles the Bamboo deployments that updates the values.

This doesn't seem too different from what the blog post is suggesting other than we're handling this all within the environment.ts and the deployment scripts. Ideally, I'd like the UpGrade process to be similar to make it easier for both dev and SRE to understand what's going on.

[mswartzCL]

@danoswaltCL will complete a short term fix for this release. Will create a DevOps JIRA ticket to work on long-term fix.