Express.js on Cloud Functions for Firebase

💻 Auto-scaling APIs in seconds

Express is a minimalist web framework for building APIs with HTTP routes, payloads and sessions on Node.js. Combining this library with Cloud Functions we can deploy a serverless, auto-scaling web server in seconds!

Source

Why use Express with FaaS?

Scaling web servers is difficult due to fluctuating traffic as users come and go throughout the day and a product’s lifetime. Load Balancers help, but maximising throughput, minimising response time and avoiding system overloads is still complex, even when using the right tools.

Functions as a Service (FaaS), like Google Cloud Functions, are small containers that automatically scale up and down with requests, making them great for hosting a web API with little hassle. They are also cost effective as you only pay when a request is being fulfilled, and no more.

Express & Cloud Function Compatibility

HTTP triggered Cloud Functions are designed to use the same APIs as the popular/most-common web frameworks for the language they support. For instance, Python HTTP Cloud Functions have Request and Response objects compatible with the Flask web framework. Similarly, Node.js Cloud Functions use the Express.js API. As per the Firebase documentation:

Use functions.https to create a function that handles HTTP events. The event handler for an HTTP function listens for the onRequest() event, which supports routers and apps managed by the Express web framework.

In addition, the request is automatically parsed with Express Body Parser.

Below are some examples using Express with Cloud Functions for Firebase:

Using Middleware

One of the most used Express middleware is cors. It’s a small package that enables Cross-Origin Resource Sharing (CORS) with various options. The code for adding middleware is the same here as in any other environment.

The corsServer in server.js shows configuring cors for a single endpoint.

Caveats

Trailing Slash “/”

Since we’re using Express you’ll need to add a trailing / to the URL as Express requires. Illustrated below:
us-central1-<project-name>.cloud-functions.net/api
us-central1-<project-name>.cloud-functions.net/api/

If you do not append the slash, you’ll get a 500 error:
Error: could not handle the request

As seen in cleanPathServer in functions.js we skip passing the whole Express app through to the Cloud Function and instead append the required / to the request URL before passing to our Express app.

Body Parser

Since all requests are automatically parsed using Body Parser before they reach our code we have no way of defining the parser options. This also makes defining the parser in your own code superfluous. Cloud Functions uses the request’s content-type to determine which Body Parser options to use. Thus, if you can set the content-type, then you have some control over this.

The complete example can be found here:

jthegedus/firebase-gcp-examples

If you like Firebase, you might want to check out Awesome Firebase 😎

jthegedus/awesome-firebase

Conclusion

Express on Cloud Functions is easy to get started with thanks to the shared request/response object structures. We get to seamlessly port our existing API servers to an auto-scaling environment while maintaining the middleware and authentication practices we have come to expect from the ecosystem.

Sources

📚 Cloud Functions for Firebase Documentation
💻 Express.js

Need something else to read?

📑 Table of Contents
An index post for my Medium Series

💬 The State of Cloud Functions (mid 19)
Google Next 19 in a Nutshell

💻 Cron & Cloud Functions for Firebase
The Serverless Cron we wanted!

💬 The 3 best features of Google Cloud Run
King of Serverless Compute?

If you found this useful, please share with your friends & colleagues.