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/27functions-samples
for middleware
https://github.com/firebase/functions-samples/blob/master/authorized-https-endpoint/functions/index.jsMy questions are then:
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?
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:
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 :)
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.