16. Introduction to Cloud Firestore

Written by Dean Djermanović

In the previous chapters, you learned how to use Realtime Database for storing data in the cloud. Firebase offers another product that you can use for storing data in the cloud: Cloud Firestore.

Cloud Firestore has a similar feature set as Realtime Database. It allows you store data in the cloud and sync data across devices, but it’s designed to overcome all of the drawbacks of the Realtime database — and it also stores data within a single JSON document. This chapter introduces you to the Cloud Firestore and discusses the differences between Realtime Database and Cloud Firestore. More importantly, it also helps you determine when it’s appropriate to use one over the other.

What is Cloud Firestore?

Cloud Firestore is a NoSQL database similar to the Realtime Database. It stores data in a structure that looks like a tree, but where data is stored as documents.

Documents and collections are the primary building blocks of the Cloud Firestore. It’s helpful to think of documents as files, and that these files consist of key-value pairs known as fields — this is similar to how models work. The values can be anything, strings, numbers, binary data, or even nested objects in a map format that resembles a JSON object. Collections, on the other hand, are simply groups of documents.

When working with Cloud Firestore, there are a few rules to keep in mind:

• First Rule: Collections can only contain documents. For example, you cannot add a String to the collection.
• Second Rule: Documents cannot contain other documents; however, they can point to subcollections. For example, your collections can contain many documents, and those documents can point to other collections. This is how things are formatted in a tree-like structure.
• Third Rule: The root of the Cloud Firestore database can only contain collections.

For example, in the WhatsUp app you created earlier, you could have a Posts collection that contains a document for each post. Each document would point to a Comments collection that contains comments for that post, and the document that contains the comments would point to another collection, and so on.

When you worked with the Realtime Database, you learned that you should avoid these deeply nested hierarchy structures. In Cloud Firestore, however, these deeply nested structures are typical because the queries are shallow, meaning that querying data from a document will get you only that document; you don’t have to query the entire collection or the subcollections within the document. This also means that queries are more efficient and flexible than in a Realtime Database, especially when it comes to filtering and sorting the data.

With WhatsUp app running with Cloud Firestore, you could have a collection of posts and any other collections you need to represent the data.

Cloud Firestore vs. Realtime database

Due to the similarity between the Realtime Database and the Firestore, you may be wondering how they’re different. Both of these products offer a cloud-based database solution with real-time data syncing for mobile clients, so what gives?

You can think of the Cloud Firestore as an improved version of the Realtime Database because it’s designed to overcome the drawbacks of the Realtime Database with things like scaling, data structuring and querying. Since the Realtime Database stores data as one big JSON tree, it’s challenging to organize and scale complex data.

Firestore has a new and intuitive data model, and it handles complex data using subcollections within documents. Because of how documents and data are stored, the Firestore has faster queries than the Realtime Database, and it supports indexed queries with compound sorting and filtering. Additionally, in the Realtime Database, you cannot sort and filter the data in the same query, and when you query the data, the result is the whole subtree. Firestore allows all kinds of query chaining that NoSQL databases allow, and instead of querying entire collections or a document, you can query subcollections within a document. Furthermore, in the Realtime Database, you need to perform write operations in a single query; in the Firestore, you can collect all of your data and write it as a batch operation. This means that one large job is executed in small parts to improve efficiency.

Firestore has a lot of advanced features too. Both the Realtime Database and the Firestore offer offline support; however, the Realtime Database offers it only for the mobile clients, while the Firestore offers it for web apps as well.

In the Realtime Database, you need callbacks for transactions. In the Firestore, you don’t. Transactions are completed automatically until all of them are finished.

Scalability in the Realtime database isn’t that big of a problem, but when the data exceeds the limits you learned about in Chapter 15, “Usage and performance”, you needed to shred your data across multiple database instances. In the Firestore, you won’t need to do that regardless of how big your database will be — the database scaling is handled for you. This is a considerable improvement for large scale projects.

Like the Realtime Database, Firestore is free, up to a certain point; you need to pay for your database to scale. Firestore charges based on the read and write operations that you’re performing on the database.

Because of the improvements that the Firestore offers compared to the Realtime Database, Firebase recommends using the Firestore for all new projects.

Cloud Firestore data structure

In this chapter, you learned that the Firestore is a NoSQL database, meaning there is no SQL. But if there’s no SQL, you can’t build queries that will take one piece of data from one part of the database, and another piece of data from another part of the database, and merge them. In the Firestore, to get data from two different parts of the database, you must make two different requests. If you run into that scenario, it’s likely that you need to re-structure your data in a way that you’ll always be able to get what you need in one request.

You also learned that the Firestore database consists of collections and documents. Take the WhatsUp app, for example. While it’s possible to have a Posts collection that contains individual posts as documents, WhatsUp has the feature where every post can contain comments. Maybe you can make it so that every post document contains a Comments subcollection, and that that collection contains comments for that post. With that setup, you could easily fetch the post and the comments in a single call. However, that’s not how you want to do that.

When you think about it, you don’t need to know about the post comments until the user opens the post by tapping on it. It’s only when the post details screen appears that you need the comments. In this case, a better approach is to have a Comments collection stored as a separate collection rather than as a subcollection. You can then put the post id to the individual comment, so you’ll know to which post the comment belongs. Finally, when fetching comments, you can filter them by the post id and get all of the comments that belong to a specific post.

There is one drawback to this approach, however, and that is data duplication. Every comment has an author so you’ll likely want to know who wrote the comment. In WhatsUp this is not the case, but in other apps, you could have another collection of users, and then the comment would need to contain the user data.

By doing that, not only do you fill the database with duplicate user data objects in each of the comments but also if the user chooses to change the data, you’ll need to update all of the comments, as well. So, perhaps a better approach is to store the author id in the comment; then, when you need to get the user data, you can filter out the independent Users collection using the available id.

One significant advantage of the NoSQL database is that it can distribute data across multiple machines easily. In relational databases, when you have an app that’s becoming more popular and needs more storage space, you’d need a more powerful and bigger machine. This is known as vertical scaling.

In many NoSQL databases, including Firestore, when you need more storage, Firestore spreads your data across many servers. This is known as horizontal scaling, and it’s much easier to scale horizontally than vertically. Why? Because it’s much easier to get many moderately powerful machines than to continually upgrade a single machine to handle everything. Machines have their limits too, you know!

Collections and documents

You learned that the Realtime Database stores data as one large JSON tree that contains keys and values. You also learned that these values can be objects containing other key-value pairs. The Firestore is a collection of objects that are stored in a hierarchical structure that resembles a tree. Every object in a collection is represented as a document. The document consists of key-value pairs known as fields in the Firestore. These values can be strings, numbers, binary data, or nested objects in a map format. The limitation, however, is that the document size must be less than 1MB.

In simple terms, collections are nothing more than a group of documents. A document cannot contain other documents, but it can contain another collection known as subcollection.

Cloud Firestore supports many data types. To learn more about them, visit the official documentation at https://firebase.google.com/docs/firestore/manage-data/data-types.

Key points

• Cloud Firestore is a NoSQL database similar to the Realtime Database.

• Firestore stores data as a collection of objects which are stored in a hierarchical structure that resemble a tree.

• Documents and collections are the main building blocks of Cloud Firestore.

• Documents consist of key-value pairs known as fields.

• Collections are a group of documents.

• Collections can only contain documents.

• The root of the Cloud Firestore database can only consist of collections.

• A document cannot contain other documents, but it can contain another collection; these are known as subcollections.

• It’s easier to query, filter and sort data using the Firestore since it can all be done within a single request.

• It’s best to use foreign-key-like fields in objects, as you don’t want to duplicate data and clutter the database.

• The Firestore scales horizontally; this is easier than the Realtime Database which scales vertically.

Where to go from here?

In this chapter, you learned the basics of Cloud Firestore. You learned what the Firestore is, the differences between the Firestore and the Realtime Database, and how the Firestore structures the data. You still have a lot to cover, so be sure to visit the official documentation here: https://firebase.google.com/docs/firestore to understand the specifics of the Cloud Firestore better. You can find it here: https://firebase.google.com/docs/firestore.

In the next chapter, you’ll learn how to manage the Firestore data using the Firebase console and how to add and delete data from the database.