Over a million developers have joined DZone.

Mixing Google Cloud Functions and Express

DZone's Guide to

Mixing Google Cloud Functions and Express

Let's split an Express handler into individual functions, which we'll run via Google Cloud Functions, working around the deployment-time kinks along the way.

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Google Cloud Functions are an awesome tool, which I have already described a couple of times in other posts. If you look at the functions triggered by HTTP calls, they turn out to be regular Express handlers. There are probably some differences in the internals, but that’s not something that would drastically change how you write your functions.

So, the question is: Can you run the functions written with Cloud Functions in mind with an Express application? Or, the other way around: Can you split your Express application to separate Cloud Functions? This question may sound like a pure experiment, but I can imagine a situation where this could be useful. You may have already an application running in an App Engine instance, but you don’t want to handle that anymore — splitting into a bunch of Cloud Function makes perfect sense.

Let’s assume we have a very simple application, with a single handler. All the handler does is return a piece of text:

// hello.js
module.exports = function hello(req, res) {

And the code to serve that is regular Express boilerplate:

// server.js
var express = require('express');
var app = express();

var hello = require('./hello.js');

app.get('/hello', hello);

app.listen(3000, function() {

Nothing unusual for now. You can run the code in an App Engine environment, you can create a Docker container out of it, but also you can create a Cloud Function, without getting rid of the Express part at the same time. This is very useful for larger refactorings, when you want to maintain the same functionality until the new dependency is resolved everywhere.

Here’s the thing about Cloud Functions. In order to run properly, it requires an index.js file or function.js file in the main folder that’s deployed. We don’t want to change anything in the current structure of the application, so here’s a simple workaround:

// function.js
exports.hello = require('./hello');

The bottom line of this is we make our handler available as an export so that Cloud Functions can pick it up at deployment time. And so, to deploy the function you only need the specify the name of the function, and it needs to be identical with the exported name in the function.js file:

$ gcloud beta functions deploy hello 
--entry-point hello 
... other parameters

And that's it! You successfully converted a configured Express handler into a Cloud Function!

As you have probably noticed, there are some caveats with this. Cloud Functions don’t have the router included, so all the calls are being targeted to a specified address. That can pose a problem when your handler takes only specific HTTP methods — for example, using it to read values from a form on your website.

Another drawback is that you need to add every single exported function in the function.js file. Usually, it shouldn’t be a problem, but when you have many functions to deploy, just going through them may be troublesome. Not to mention that you have to deploy your full application to the Cloud Functions!

All the files are available as a Gist. Feel free to fiddle with them!

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.

google cloud functions ,express.js ,cloud ,tutorial ,http calls

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}