Feature Request: Params

[inlined]

We at Firebase don’t always develop in the open. It’s easier to test with a limited audience and then announce it more broadly with a PR splash. Today we’re going to go into depth about our upcoming roadmap, because Cloud Functions for Firebase is between generations of configuration options and the new features don’t seem as full-featured as the old system (yet).

We recently released support for dotenv files and Cloud Secret Manager. Many of you have noticed that, unlike Runtime Config variables, these environment variables are not available when we’re reading your code during deploys. Additionally, Runtime Config variables are not available in Cloud Functions gen 2 environments. We are aware of this feature gap and are working diligently to close it.

Runtime Config: a history

Runtime Config is a strange feature of Cloud Functions for Firebase that exists purely for historic reasons. Runtime Config was originally conceived to allow Cloud Functions for Firebase to dynamically be reconfigured without redeployment. Unfortunately, this flopped during alpha testing: reading the initial state of Runtime Config added about 100ms to cold start latency and any transient outage in Runtime Config would cause uncatchable failures in your Cloud Functions. After discovering this, we immediately removed the “realtime” features of Runtime Config. We kept a dependency on Runtime Config because it served another purpose: it was a way to add “config” values at a time where Cloud Functions did not yet support environment variables.

For configuration at runtime, environment variables and cloud secrets manager are always a better solution. They are standards compliant, keep secrets out of prying eyes, and have emulator support built in. Runtime Config will not exit beta and we’ve been asked to move customers off of it. The removal of Runtime Config support in the firebase-functions SDK and firebase-tools CLI will be announced once their replacement is ready.

Params: the future

Params are an upcoming layer atop of the existing support for environment variables and Cloud Secret manager. They will be very easy to use:

const language = params.defineString(“LANGUAGE”, {
  description: “What language to translate into”
});

export const translate = functions.database.ref(“/messages/{id}”).onCreate(await (ref) => {
  const translated = await translateInto(ref.child(“original”).data(), language.val);
  // …
});

Here, your code depends on the environment variable LANGUAGE at runtime. But this has a few benefits over simple environment variables. The first is that Firebase knows your code needs a “LANGUAGE” environment variable. If we don’t see one, we will prompt you for its value during deploy. This makes it harder to push broken apps to production and makes it easy to get set up with sample code.

The value of a param cannot be read during deploy time, but they can be used to templatize your code:

const bucket = params.defineResource(“BUCKET”, {
  type: “resourceSelector”
  resourceType: “storage.googleapis.com/Bucket”,
});

// bucket.val is the empty string during deploy, but you can assign any attribute of your cloud
// function (e.g. the bucket, your region, min instance counts) and your code will be templatized
export const thumbnail = functions.storage.bucket(bucket).onObjectFinalized((object) => {/*...*/});

We see this as the future because it allows us to provide better features. In the example above, we can provide a dialog that prompts you for a Cloud Storage bucket if your config is missing. The Runtime Config analog would just behave unexpectedly. This feature will make it much easier for developers to create and use templatized sample code or even their own Firebase Extensions. Stay tuned, the future is bright!

Sincerely,
The Firebase team

[ftzi]

This is interesting. Ain't clear to me if this allows local envs var for dev environment. I use Stripe, and to do local tests, I setup the local Stripe emulator, get its generated secret and set it as a env var to be read in the Functions code, all in a npm script ("STRIPE_DEV_WEBHOOK=$(./stripe listen --print-secret) firebase emulators:start").

[DibyodyutiMondal]

This covers environment variable that we need at run-time. But what if we need a deploy-time environment variable, like NODE_OPTIONS?

Why would I need an environment variable that I don't use at run-time?
To specify 'NODE_OPTIONS=--experimental-specifier-resolution=node'.
This is so that I don't have to add '.js' to each and every typescript import in the entire dependency tree of the cloud function.

Without that environment variable, there will be a deploy-time error. Because firebase tools will try to load my esm modules and fail. I either need that environment variable, or I need to add '.js' everywhere. And I'd rather use the environment variable.

Again, even if I define params, the typescript files where the params are defined won't be loaded unless the environment has NODE_OPTIONS set in this case.

So far, the dotenv-based solution has allowed me to run the cloud functions with NODE OPTIONS set. But deployment and the emulator both requires monkey patching firebase-tools to include NODE_OPTIONS in the child environment where the triggers are being parsed and executed, respectively.

[inlined]

@SrBrahma Your use case is interesting but should be unaffected by this. CCing @taeold for thoughts on how to allow customers to provide (real) secret values without serializing to the filesystem. Maybe with a commandline flag? We drop environment variables from the emulator so that customers don't accidentally depend on local environment variables and push broken code to prod.

@DibyodyutiMondal ESM is/was an exciting development in the Node and TyepScript landscape. I think this is an interesting use case to consider, but we can't easily allow setting build-time environment variables. They're simply not compatible with our long-term roadmap without careful consideration. My team will take this offline to see if there's something we can do though.

[DibyodyutiMondal]

@inlined

I wouldn't call them build-time variables. My dotenv file contains NODE_OPTIONS and it works in production without any problem. Cloud build has no problems at all. The environment variable is set in the functions. So when they start up, firebase-functions has no problem loading my code, because the env variable is already set.

Very specifically in the context of the problem I'm describing, it is a deploy-time variable, that too on the developer's machine, not the cloud, when firebase-tools is parsing the triggers.

As it currently stands, when parsing the triggers, and while emulating, the firebase-tools library creates a child process, but that process does not inherit environment variables from the parent process. It loads user environment variables after parsing the code. But it can't parse the code without the user environment variables (NODE_OPTIONS), because it can't load the files without the specifiers. Thus it becomes a chicken-or-egg question, and I had to monkey patch so that it could load my code.

In fact, if the child processes I mentioned had the environment variables set before it loaded my code, that would be closer to how the code functioned in the cloud.

EDIT: Unless this behaviour in production is going to change in the new generation. Of which I have little idea.

EDIT: I have many environment variables, but the only one I need to add into the child process is NODE_OPTION, so if the firebase tools gave an option for just that env variable, that would work too. Running the command by passing node options from the command line does not currently work because, as I mentioned, it does not inherit environment variables/options from the parent process. (Which I think is a great, and should not change).

[ftzi]

@inlined I am stuck on a older version as env vars aren't supported anymore... I hope you guys can find a way to solve this, so we can set vars on dev env.

[trex-quo]

Is this expected to be released by CFv2 GA? My team has been preparing for our migration and only recently realized that we cannot use CFv2 at all as we cannot deploy functions that rely on environment variables

[inlined]

This will be part of Cloud Functions for Firebase v2 GA but is not a blocker for public preview. We are considering multiple avenues, including build env files.