Cloud Functions for Firebase and Express

Question

The Firebase docs for the functions.https namespace shows that the function accepts an express.Request object and an express.Response object. Nowhere does it mention that you can pass an express server object to functions.https.onRequest. However, I've found that people have been doing this with no clear indication from commenters that this shouldn't be done (except one person in the functions-samples repo issue #101 thread)

see:

• firebase-functions https://github.com/firebase/firebase-functions/issues/27
• functions-samples for middleware https://github.com/firebase/functions-samples/blob/master/authorized-https-endpoint/functions/index.js

My questions are then:

1. How do Cloud Functions for Firebase or GCP Cloud Functions handle the lifetime of objects initialized outside of the function definition?
2. How does the above affect the lifetime of the function? Does it run until timeout or function similarly to AWS Lambda?

Clarification for 1 & 2: In Lambda any resources outside of the exported function is used on all subsequent invocations of the same Lambda instance while that function instance is "warm". This means the response time of the function is not negatively affected by any complex initialization code you may have beforehand as it is done once per "warm" instance. In this example, it wouldn't then need to initialize an ExpressJS server each invocation, just once while the function is "warm". I'm curious if Cloud Functions do the same?

Also in Lambda, the existence of the ExpressJS server does not extend the execution time of the function (when it returns it's done), I'm also curious how Cloud Functions is implemented here. Does it simply do the same as Lambda, or (because it may handle existing objects differently) does it do something else?

3. The functions.https.onRequest documentation doesn't specify you can pass an ExpressJS server object into it, so how is this working? Are there then two endpoints? Can someone explain what is happening here?

Clarification for 3: I've been seeing people do the following:

// './functions/index.js'    var functions = require("firebase-functions");  const express = require("express");    // setup ExpressJS Server  const expressRouter = new express.Router();  expressRouter.get("*", (req, res) => {    res.send(`Hello from Express in Cloud Functions for Firebase`);  });    // Cloud Function  exports.express = functions.https.onRequest(expressRouter);

And wish to know how this works given the Cloud Functions API only specifies accepting functions.https.onRequest(request, response) params modelled after the ExpressJS API.

These parameters are based on the Express Request and Response objects - firebase.google.com/docs/functions/http-events

Since all questions pertain to the single snippet of code and this one use case I thought it would be better answered together.

Thanks in advance :)

Answer 1

This all works because under the covers, an Express app is actually just a function that takes a Node.js HTTP request and response and acts on them with some automatic sugaring such as routing. So you can pass an Express router or app to a Cloud Function handler without issue, because Express's req and res objects are compatible with the standard Node.js versions. Basically, it's a "double Express" app where one app is calling another.

As far as function lifecycle and shared state goes: functions are spun up in ephemeral compute instances that may survive to process multiple requests, but may not. You cannot tune or guarantee whether or not a function will be invoked in the same compute instance from one invocation to the next.

You can create resources (such as an Express app) outside of the function invocation and it will be executed when the compute resources are spun up for that function. This will survive as long as the instance does; however, CPU/network are throttled down to effectively zero between invocations, so you can't do any "work" outside of a function invocation's lifecycle. Once the promise resolves (or you've responded to the HTTP request), your compute resources will be clamped down via throttling and may be terminated at any moment.