Google offers a range of products for hosting, database management, and even authentication. Firebase, however, is an incredibly unique, easy, and affordable BaaS (Backend-as-a-Service). Firebase, Inc. was acquired by Google in 2014. Google saw something special in the product and made it something greater. Imagine a cloud-hosted database that scales, has real-time subscriptions, storage, security, testing, authentication, and just works out of the box. It was the first mobile and web development platform of its kind.
TL;DR#
Firebase is a popular cloud service to host your website or application. It offers two of the best cloud-hosted databases that offer real-time data support. Cloud Firestore is the newest database on the platform that is extremely easy to learn and get going. Firebase Authentication is free, and all other services on the platform are relatively cheap. You have to pay to use Cloud Functions. Firebase is perhaps the easiest to use of all cloud-hosted database BaaS. Period.
Firebase Realtime Database#
Before Google bought it, Firebase used the Realtime Database as its main product. It is a JSON tree NoSQL database. It is schemeless, as you don’t need to define your data types before you add data. This is different from the popular Document Database that is MongoDB. Imagine a large JSON object where you can fetch a node and get the whole child database back in JSON form.
WebSockets#
What makes Firebase so special is the ability to subscribe to changes to the nodes. This means you can receive immediate updates to your data, live, by subscribing to changes to the database. When a node is created, updated, or deleted inside the node you’re watching, you will receive an immediate update.
The Firebase Database watches for changes on the server and sends out a message to the subscribers every time there is a change. All the subscribers are notified in real time. Implementing a WebSocket feature like this can be cumbersome to do manually, but with Firebase, you just install the client SDK, run the subscription method, and you get the results immediately. Firebase uses these WebSockets under the hood, and you don’t ever need to think about how it works.
Long Polling#
Firebase also uses long polling in cases where WebSockets are not available. In polling the client intermittently keeps polling, or fetching, the server until there is changed data. In long polling, the server stays open and doesn’t send any data back until there is a change or a certain time has passed. This is only necessary on older client systems or browsers, and it uses JSONP in the script tag to receive the data.
Caching#
If you have a history with WebSockets, you know it usually just returns the changed data, with the changed event. Firebase Realtime Database nevertheless returns all data in all events, although this is not what is actually happening under the hood, as Firebase makes things easy. Firebase fetches the data first, then saves it to a cache. When there is a change, Firebase will send only the changes back to the client, combine the changes with the cached version, and the user gets the full changed node (or lack thereof in case of a delete). You can subscribe to the root changes, or you can select which event type (create, update, delete, moved) you want to listen to for the child node and respond to that manually.
Optimistic Updates#
Due to Firebase needing a cache for the real-time data to work properly, you get optimistic updates as a wonderful side effect. This means when you add a new document, your cache is updated immediately and the document will be visible in your application with no delay. If there is a server or an authorization error, the new document will be removed from the cache and the changes will be backpedaled. Your application will show the changes in real-time before the server gets to update the real database. Usually, IDs are generated on the client, so the cache already has all the data it needs to display the changes in your application. Things like server timestamps, however, will cause your cache to get updated twice on a document change, as there is no way for the cache to know what the server date is just from the cache. The cache is really what makes Firebase so powerful.
Offline Capabilities#
Why would the cache’s uses stop there? You’re able to keep your application running by using it as a database. Your users will not notice a difference, and the data will get populated or removed as soon as the network becomes available again, but you can detect and deal with disconnections using simple functions from the SDK. This is pretty cool.
Transactions#
Firebase RTDB has the feature to create atomic transactions. This means you can modify several items at once, or nothing happens. You can also modify one field based on the value of another field, ensuring it doesn’t get changed in the interim. The mechanism with automatically retry in case of problems.
Security Rules#
Firebase Realtime Database uses a JSON-like validation system to ensure access control and data validation. Some SQL languages like Postgres will filter the data, Firebase RTDB just prevents things from happening before they do.
Cloud Firestore#
Due to the popularity of document databases, some scaling and organizational issues, and the lack of multiple filters, the Firebase team decided to build a new database. Again, the focus is on the real-time data changes, which are amazing.
Document Database#
Cloud Firestore has a slightly different structure. Instead of one large JSON tree, imagine a bunch of small JSON trees called documents. Each document has a unique path. The path consists of a folder-like structure and the document id. The folder-like structure is called a collection, and the JSON document itself is called just a document. You can also have a collection within a document path, which is called a subcollection.
posts/POSTS_DOCUMENT_ID_HERE/comments/COMMENT_DOCUMENT_ID_HERE
Here the posts are the collection, and each post has a document id. Each post can also have a comment, which is the subcollection, and each comment will have a document ID.
The Full Document ID#
In reality, or under the hood I should say, there are no collections or subcollections. The entire path is just the document ID. That means for a collection or subcollection to exist, there has to be a document in it. If you create a collection, and there are no documents, there are no documents whose paths use that collection name in it, so that collection does not exist.
Automatic Indexes#
A collection is a means for Firestore to index documents. You can only query documents across one collection. The exception to this is that you can query across subcollections that share the same collection names. This is called a collection group query. You need to manually create an index for this.
Filters#
In Firebase Realtime Database, if you want to filter by multiple properties, you have to manually create indexes (duplicate data) to do this. You may, for example, create a composite index to filter by the post and the post-created date at the same time by duplicating the data. post_id__created_at may look like 123__2024-03-15T01:47:25.794414. Cloud Firestore does all of this automatically, and in the case of complex filters, you can easily click a link to manually create them. There are also new filters that are not complex that are available.
Offline Persistence#
Firestore also adds automatic use of the caching and offline mechanisms so that a user can not tell when it is offline. It updates the backend when things come back online.
New Abilities#
Cloud Firestore is generally an upgrade in every way to Firebase Realtime Database, and new features are still being added. Security Rules are similar to RTDB but work on the document level. There are counting aggregations available. It can scale faster and larger. It would be impossible to name all the features in one post.
Authentication#
Firebase actually has a 3rd database. Firebase authentication stores all your user authentication data automatically in one place. You can use this database with Cloud Firestore or Firebase RTDB to secure your data, or you can trigger data creation when a new user is added or removed. It has password handling, oAuth handling, and even templates for email messages. It is the real deal, and it is free. Google is smart enough to know that if you rely on one product, you will probably make them money from another product once you get locked in.
Cloud Functions#
To make a NoSQL so powerful, you need a way to change the data automatically. Firebase can access the databases and authenticate the user inside functions. Generation 1 uses Google serverless technology, but Generation 2 uses Google Cloud Run technology which is faster and scales better.
Serverless#
Cloud Functions are a serverless technology. This means they get spun up on each new function invocation. When there are many invocations, the functions duplicate themselves to support scaling. When there is no activity, they die off. A function stays online until there is no activity. This also means that the first invocation has to load a mini-virtual server. This could take a few milliseconds to a few seconds. This is called a cold-start time and is the biggest negative to serverless technology. Cloud Run is as good as it gets with Google.
Callable#
You can call a function from your app using the Firebase SDK, or a fetch. This is great when you need to calculate something securely, return the data, and get the data back in your app.
Trigger#
There are also trigger functions that get triggered on certain events. You may need to copy or aggregate data when a document is created. There are events you can trigger to call a function. You can also create a user document automatically when a new user signs up. Trigger functions allow you to do things automatically on the server.
Hosting#
It is also possible to host your server-side app using Cloud Functions. You can call your function from a URL, and make the function call public. Firebase has a CLI to make doing this easy. It then uploads your static files to Firebase Hosting and caches them in a CDN.
Storage#
All apps need the ability to store files. Usually, these files are images, but they could also be a whole static site, frontend JS, or CSS files. The Firebase SDKs can create storage buckets easily, and allow you to validate them with Security Rules as well. All of this works well with your app.
Firebase Emulators#
Firebase is a cloud service. You used to have to create a second database if you wanted to do testing. Now you can just spin up the Firebase emulators on your local machine, and test how your app interacts with Cloud Firestore, Authentication, Storage, and Cloud Functions. You can write your unit tests and you don’t have to pay for any serverless usage. This will make your development a breeze.
Firebase Platform#
When most people say Firebase, they are referring to Cloud Firestore. However, Firebase is actually a group of tools to build your Web and Mobile apps. You can check your app’s statistics, create A/B testing, secure your app, put ads on your app, and even use machine learning. Firebase has evolved to be Google’s easy-to-use service, and it has many other features I didn’t mention.
Negatives#
There are negatives to every option you would want to use.
Vendor Lock-In#
Unfortunately, you can never get off of the Firebase platform. You can’t self-host it, and you can’t use another cloud service with the same features. You would have to export your data and use a completely different service.
Charges#
Firebase Pricing can be relatively cheap for small databases, and free if you don’t need Cloud Functions. However, you need to model your data correctly keeping in mind every read and write is another potential addition to your bottom line.
Limits#
There are limits to the size of a Document (around 1MB). This means you cannot store all of your info about an entity in one document. You need to get good at Data Modeling so you understand the best and cheapest way to do things. Another limit worth mentioning is the inability to write to the same document more than once a second. This is important when calculating counters.
NoSQL Vs SQL#
The worst and best part of Firebase RTDB and Firestore is that they use a NoSQL database. This means you have to forget about joins and learn aggregations. You have to repeat data, which is usually a no-no in database normalization. You must think about everything differently, and it can be a lot more work for complex data structures. Again, you must master Data Modeling.
No Text Search#
Yes, Google does not have a way to search data in their NoSQL database. You can do exact queries, but you cannot search within a field. This is odd to me, and I hope they add at least the ability to full-text search at some point, but fuzzy and relevance searching would be better. I’ve added it to my Firebase Wishlist.
Firebase Realtime Database Vs. Cloud Firestore#
There are only a few cases where I believe Firebase RTDB is better.
- Your data is flat and you don’t care about scaling or complex filters.
- You need to prioritize real-time capabilities, and you are using RTDB in conjunction with Cloud Firestore.
- You are worried about the pricing of reads and writes so you prefer a pricing model based on data transfer AND you don’t care about scaling or complex filters.
Should I use Firebase?#
If you want to build a secure app quickly that needs authentication, security, and storage, and you don’t have overly complicated relationships, Firebase is your go-to option. Just like everything else, it depends. However, when you use Firebase, you will need to use several features together to get your needs met. This could be the perfect database for your style.
J