Making a Firebase server worker in the cloud

In order to maintain data consistency in your Firebase app, it can be a good idea to consider having a server worker somewhere in your setup. Although there are a few options available, I prefer to work with NodeJS since it is the most straight forward way to build a small server worker. Also because it’s the easiest Firebase supported library to work with JSON structures. And you will be doing a lot of JSON juggling in this application, so that should be a priority for your consideration.

Once again, my mastery in Google Draw free me from any need for attribution, apart from the brands displayed in this image as they are mentioned in the article.

If you’re building third party system integrations into your Firebase backed application, you might end up with a more complex server worker. You should still feel confident to implement it in NodeJS. The only consideration you need to take into account is where you will host your worker and what support that platform has for running your application in the language that you choose.

In this article we will be looking a Google App Engine Flexible Environment and make reasoning around the choices for that.


The purpose of the server worker is to take care consistency in your denormalized data structure. The great part about doing it in a server worker is that you don’t need to maintain this logic in many places, if you for example have both an Android and an iOS version of your application.

Another good thing is that we can control the update schedule for the server worker, so whenever we’re adding in new paths or views for our data we have better control of consistency. Mobile clients might still be running old versions that doesn’t know about the new places where data should be fanned out to.

How to structure the data

The way I prefer to do it is to have a set of “master records” placed on the paths that are the simplest way to refer to the data. It might be “/chats/{chat_id}/topics/{topic_id}” if topics are never retrieved outside of the context of a chat. But it might be “/users/{user_id}” if users can appear under several sub-paths in many different context. So in the latter case, the best way to maintain the “master records” of users would be in a flat structure of all users.

Now, the job of the server worker is to fan out the data and maintain consistency. In the example below, we’re having a master record of visits and for the application there are views for either listing all visits to a certain business or all visits made by a member.

The NodeJS server worker also maintains a meta-data record for each visit which is on a separate path that is neither readable nor writable by any client application. The meta-data records are only used by the server application for audit and for third party system integrations.

Limiting write access

In order to limit your clients from writing in the wrong place, the security definitions are only allowing clients to read from the denormalized data (duplicated data) and read/write to the master record.

Read more about the Bolt database rule definition language on Firebase’s own github project for it or in my previous article about Firebase security.

By structuring your data as the security rules above suggests your clients will effectively limit managers to only update the master record, and the NodeJS worker will take care of propagating that change to the memberVisists and businessVisits paths.

Where to put your NodeJS worker

Another reason why NodeJS is a good choice, is because it is easy to deploy. If you got your own VPS somewhere you can setup your server worker to run from there. But I recommend that you look into setting it up on Google App Engine Flexible Environment. You can’t use the standard GAE environment since Firebase relies on long lasting web socket connections. The standard environment executes in short lived threads, and you can at most get a 10 minute window for any executing job. That’s way too short for anything useful for what we’re trying to accomplish here.

The Flexible Environment (previously known as managed VMs) is a good middle ground between running in a sand-boxed environment such as the standard GAE and having to setup and manage your own VM. It allows you to get some of the benefits from access to cloud platform dashboard features for your VM instances. And it allows you to run NodeJS applications (which the standard GAE doesn’t).

For details on how to automatically deploy to GCP from your git repository, I recommend that you read my previous article that is a step-by-step guide on how to do it with Gitlab.