26
votes

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:

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?

  1. 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 :)

2
Note that using middleware is covered briefly in the docs and in functions-samples.Kato
Your statement "API only specifies accepting functions.https.onRequest(request, response) params modelled after the ExpressJS API." is not entirely accurate. From the Firebase Cloud Functions docs, they actually pass in a function (arrow function), and not just the request and response params.Kevin Lee

2 Answers

30
votes

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.

5
votes

You shouldn't expect to hold any resource beyond the lifetime of a function. You should expect that the container will completely clean up after the function's final promise has been resolved or the HTTP response has been fully sent. There is no shared state between any function invocations. This is the only way that Cloud Functions can scale. If you need shared state, store that in the database and read it on every invocation, protecting it with a transaction if necessary.

I'm not sure what you're asking in the third question. It kind of seems unrelated to the first two questions - maybe it should be its own question? There is only one endpoint for your backend, as far as I know.