An look into using Firebase for Multiplayer Game
Tags: firebase, multiplayergame, firestore, realtimedatabase
Published: 2019-03-14 16:24:05

---
title: An look into using Firebase for Multiplayer Game
published: true
tags: firebase, multiplayer game, firestore, realtime database
description: Firebase is awesome, unless you choose the wrong product for the wrong job. A theoretical analysis of Firebase pricing for powering multiplayer games.
canonical_url: 
---

> Firebase is awesome, unless you choose the wrong product for the wrong job. A theoretical analysis of Firebase pricing for powering multiplayer games.

# Cloud Firestore vs Realtime Database

In [October 2017](https://firebase.googleblog.com/2017/10/introducing-cloud-firestore.html), Firebase launched [Cloud Firestore](https://firebase.google.com/products/firestore/) as a new fancy hot cloud database. This new service is operated side by side with [Realtime Database](https://firebase.google.com/products/realtime-database/) and can confuse new user of which to use for their purpose. Firebase’s effort of driving user to the new service makes it even more confusing, delivering an impression that Firestore is there to replace Realtime Database. When you go to any page of Firebase documentation site on [Realtime Database](https://firebase.google.com/docs/database/), you will see a highlight section on the top of the page encouraging you to explore Firestore.

[![](http://netcell.netlify.com/assets/img/firestore-promo-docs.jpg)](/assets/img/firestore-promo-docs.jpg)

On Features, Firestore is in fact far better than Realtime Database: _better structure, better querying, better rules writing and more concurrent connection_. The only downside: _its pricing_. While Realtime Database is mainly priced by the amount of _data you are using and transferring_, Firestore is priced by the amount of _read/write operations_ you are making on the database. This makes using Firestore awkward for realtime applications since each client will react and issue read operations on database changes and that costs money.

_Who would have thought that Realtime Database is better for realtime applications right?_.

Of course no one is using database synchronization for realtime multiplayer games, but turn-based or asynchronous multiplayer games can benefit greatly with Firebase approach. However, one game session can easily invoke 1000 operations, meaning you can support 20 game sessions daily with free plan and 100 game sessions daily with $25/month plan. Realtime Database on the other hand can support 100 CCUs for free plan and 100,000 CCUs for $25/month.

[![](http://netcell.netlify.com/assets/img/firebase-database-plans.jpg)](/assets/img/firebase-database-plans.jpg)

It is the best to use both of these database, Realtime Database for game sessions and Firestore for anything else. With this, you can open connections to realtime database only when the game session starts and close it with [`firebaseRef.off()`](https://stackoverflow.com/questions/40186819/firebase-web-close-connection-to-the-realtime-database) when it ends to optimize the simultaneous connections count.

Furthermore, if you are only using realtime database for game sessions, scaling with multiple databases becomes pretty easy since you don’t have to share any data between these database. While Firestore is supposed to be able to automatically scale indefinitely, I don’t think its benefit outweights the cost in this case.

# Cloud Functions HTTP Triggers

Since you are making changes to database, you probably want to make some logic not dependent on the client. Cloud Functions provides you with the ability to create [HTTP endpoints](https://cloud.google.com/functions/docs/calling/http). However, the functions are _billed by invocations_, which is really really bad since there is no protection available for the endpoints if you are using it with CORS.

[![](http://netcell.netlify.com/assets/img/cloud-function-pricing.jpg)](/assets/img/cloud-function-pricing.jpg)

People can make mass requests to these endpoints and you will be billed accordingly. Rejecting from inside cloud functions code doesn’t work since the invocation is already counted. This is not the end of the world though since you can setup CloudFlare and use [rate limiting](https://www.cloudflare.com/rate-limiting/) feature to protect your endpoints. This service is only [billed by good requests](https://support.cloudflare.com/hc/en-us/articles/115000272247-Billing-for-Cloudflare-Rate-Limiting) - requests that are allowed to reach to your endpoints.

[![](http://netcell.netlify.com/assets/img/cloudfare-rate-limit-pricing.jpg)](/assets/img/cloudfare-rate-limit-pricing.jpg)

However, there is another aspect you need to consider: pricing. Free plan gives you 125,000 invocations monthly and $25/month gives you 2 million. This is far less than the amount of write operations you are allowed on Firestore. If you don’t want to use CloudFlare or if you think this limitation might cause trouble, you may want to explore the option to migrate to your own server.

A very interesting point about Cloud Functions endpoints is that you can use frameworks like [`express.js`](https://expressjs.com/) to [wrap these endpoints](https://firebase.google.com/docs/functions/http-events#using_existing_express_apps) into a single Cloud Functions HTTP trigger. Since the Firebase admin library can be initialized on any server, you can bring your entire `express.js` section of your code to another server and it should work just fine. This is important because you can start developing your application with Cloud Function which makes your life much easier, knowing that you can migrate anytime you want.