Firebase is a back-end-as-a-service platform and offers different services such as analytics, authentication, database, notifications, and cloud functions. The project I'm writing about has a web app and a mobile app for Android and iOS, and we signed up for Firebase's Blaze plan (not the free one).

The goal of this article is to tell you about our experience with the database (FireStore Database), its benefits, the problems we had, and what we learned.

In our company, we spend a lot of time discussing how it should be structured, thinking about relationships and entities. For those of us who come from a relational world, we have problems here (since it's all about schema and data normalization), while in Firebase denormalization is perfectly fine.

Firestore database is a NoSQL database based on documents and collections.

We are used to thinking in a relational way because for a long time, the only option for data storage has been relational databases. However, you've heard the term NoSQL, databases that, thanks to their way of handling data to solve different problems (for example, searches, large-scale web applications, social networks, etc.) have been drawing our attention.

How to Structure Your Data

Based on what we learned with relational databases, we know that we should avoid duplicating data, but in the case of Firebase it is something that allows us to save a lot of time by reducing queries, denormalized data is very common here.

Think before structuring, the queries you will need to perform since with Firestore we can make efficient queries within a collection or subcollection, but not between collections.

Shallow Structures (And Save Money)

When data is less nested, it is easier and faster to retrieve it without having to navigate through multiple levels of subcollections or nested documents. And why would we save money? Because in Firestore read, write, and delete operations have an associated cost. Deeply nested data structures can lead to a higher number of reads and writes if you need to access specific information within these nested documents and that would make you pay more than you probably should.

Firebase Cloud Functions

Cloud functions are Serverless, meaning we don't need servers or manage them. The system automatically scales the number of function instances based on demand. While when using Firebase, most of the application logic is on the client, you may want to move some of the code to the back-end and this is where we use cloud functions, which allows you in response to certain events triggered by the different Firebase functions and HTTPS requests to automatically execute back-end code.

I also highlight that in this project we use authentication, storage and push notification services as well as hosting.