Inject config into app

[jamesgorrie]

Motivation

Proof of concept PR

Currently we receive a set of images from the frontend API with a list of fixed sizes. This is OK, but doesn't give us the freedom to truly optimise how we serve images to readers.

To serve images from DCR directly, we would need to embed config into the app. The current recommendation is to use AWS Parameter store. We have a recommended way of using these in Scala, but not Node.

There are a number of ways to do this, these are outlines below.

We should choose a way to move forward with. Any learning can be shared upwards and possibly added to the recommendations.

Options

Use .env

We could use a script, similar to something similar to what we already have to fetch AWS parameters, and create a .env file from this.

Dev flow:

• Check for valid .env file
• If needed, generate .env file
• Inject .env into app (probably via webpack)

✅ - requires AWS creds once on generation
✅ - supports multiple environments
✅ - easily inject via dotenv, or webpack-dotenv
❓- Is this something we should use in CI and prod as it creates a plain text file with secrets in?
❓- If ☝️ isn't recommended, would we have to have this, and CI, and prod implementations to support?
❓- is this what .env is for, normally it's for having values that are different between environments?

Fetch values, and inject on start

On start, we could fetch the values with something similar to what we already have to fetch AWS parameters, and add them to the app from memory, probably via webpack.

❌ - requires AWS creds every start
✅ - supports multiple environments
✅ - doesn't require us to create a file exposing values

Combo of .env locally and fetch on prod/CI

We could use the .env solution locally to avoid having to have creds all the time, and use the fetch into memory for CI prod for security. We currently split on how we do DEV and other environments for DevX reason, so that's not unconventional.

✅ - requires AWS creds once on generation locally
✅ - supports multiple environments
✅ - doesn't require us to create a file exposing values
❌ - might slow down start time (it's AWS though, which is fast)

Fallback

We would want to support running the project without .env. We should fallback to something that would prtect us from someone spamming the image optimizer, but allow for the page to render acceptably in DEV.

• main image, no optimisation
• fake image
• ...

[jamesgorrie]

Secrets / env vars in CI / PROD

Another way to get the environment variables in CI / PROD would be to use nest-secrets in our infrastructure, which does decouple it nicely. It does get all the values, so it might be worth thinking about what values we want from Parameter store.

[jamesgorrie]

Working locally

As much as creating the .env file only needs AWS creds for the initial build this might still be a little bit too much of a barrier. What other options might we offer?

• Make sure the site works acceptably without env vars (see Fallback in the initial discussion)
• Copy / paste?

[mxdvl]

I think this is a tricky one to get right, but if we use the Makefile, we should be able to wrap this behaviour inside make dev.

As a reference, this is what a front looks like with all images being identical–it’s surprisingly viewable.

[jamesgorrie]

I think this is what was suggested, I also like that we don't lose the ability to ensure that our image optimisations are working. If someone wants the real content we always have other ways to share the salt that's not Janus dependant.

[jamesgorrie]

We're pulling off the config work and image work as separate pieces.

[jamesgorrie]

This has been implemented here with an ADR explaining what was done. Fabulous.

[jamesgorrie]

We implemented dotenv, but then moved to allowing certain values to certain properties through to the image resizing service.