Runtime sharing of env vars

[chrisj-back2work]

What do you want and why?

Some way to share runtime env vars between server-side and client-side, similar to how the blitz.config.ts "env" option works for build-time variables.

The Blitz doco (https://blitzjs.com/docs/environment-variables#exposing-environment-variables-to-the-browser) describes how to use the "env" key. By experimentation, I've found values set in "env" are all determined by the env var values extant at build time / not overridden at run time.

Although some env vars are appropriate to set at build time, most need to be set at run time. In our case, we make Docker image builds one time and configure them with different settings (always env vars) in each environment. E.g. the app name could be set at build time, but log settings, auth0 client info and many others items will differ by environment (= runtime).

Possible implementation(s)

Next has two options in next.config.js: "publicRuntimeConfig" and "serverRuntimeConfig" that seem parallel to the "env" key used by Blitz. The "public" flavor shares values between the front and back ends, while the "server" flavor provides values to the back end only. I've tried using these. Both flavors work as advertised for the back end, however the public flavor does not share values with the front end. Maybe that could be enabled for use with Blitz?

Big picture: we need (1) a way to define env vars that are set only at build time and shared between front end and back end -- that's satisfied by the "env" key -- an env var defined like env: {SOMEVAR: process.env.SOMEVAR } can be referenced by the front end and back end as process.env.SOMEVAR and the same build-time value is used; (2) a way to define env vars that are only available to the backend -- that's satisfied three different ways: (a) any env var NOT referenced in "env" can be referenced on the back end as process.env.SOMEVAR and the run-time value is used; (b) the serverRuntimeConfig approach described by Next doco, and (c) the publicRuntimeConfig approach described by Next doco; and (3) a way to define env vars that are set only at run time and shared between front end and back end -- not aware of a current way.

Additional context

Is there a reason the Next publicRuntimeConfig approach doesn't already work?

[beerose]

Is there a reason the Next publicRuntimeConfig approach doesn't already work?

It should work, and I'm not sure why it doesn't. However, what publicRuntimeConfig does is make a call to the server to extract env vars. So an alternative to using that is creating a Blitz query that returns an object with public environmental variables. You can then call this query on the frontend.