Don’t get me wrong, I like Firebase — but with everything dev related, there’s always a good and bad side, with a pinch of annoying that no one really wants to talk about.
What is Firebase? It’s Google’s all-in-one cloud service, neatly packaged and delivered to developers who just want something up and running quickly. No need to worry about provisioning or elastic cloud structures. All you have to do is connect it to your front end andviola! everything just works.
While this is great for rapid prototyping, cost management can get out of hand if you’re not careful.
Personally, I’ve been working with Firebase for the past two years, at different product complexity levels. In these past two years, I’ve discovered interesting things about the platform, especially about how to think and what it can mean for creating a production-ready application.
Without further ado, here’s the good, the bad, and the annoying parts of Firebase — specifically Cloud Firestore.
The good parts of Firebase
Firebase is fantastic if you want to create something out of nothing in a flash, making it great for rapid prototyping. If you’ve got the general gist of what you want to do and need a fully configured backend you can connect to, then Firebase can be your go-to service.
Being a Google product, it means that it’s fully integrated into other services within its ecosystem. This includes Google drive products — specifically Google Sheets.
In Google Sheets, you have the ability to create custom scripts that can connect to your Firebase database. From here, you can import the data straight into Firebase, fully formatted at the right levels, and with the correct set of key-pair values.
This can come in handy when you have a set of mock data, generated from another non-dev based department such as finance, commercial, or marketing, or you just need to create something that’s fully functional to show the boss in a short amount of time.
It also lets you delegate your data needs over to someone else, and make the process of migrating datasets to new applications much faster. Being able to modify and deal with data in formats that native to the department can also speed up communication and the process of understanding how the data works.
Alternatively, you might not be highly skilled in backend technologies or lack the time or resources to create an entire backend integration system from scratch. Firebase makes a great solution by bolstering up your technical weaknesses so you can focus on delivering the user experience with your frontends.
In short, Firebase is fast, lightweight to bootstrap, and has mostly integrated parts you need. It’s more than just a database. It’s a static file hosting platform, a microservice backend, as well as ready to go database.
The bad parts of Firebase
Firebase works really well when you’re working from scratch. Working with legacies and cross integrating between different types of projects can be a difficult process.
The data you put in is ‘stuck’ inside Firebase unless you write a function to export the entire dataset. There’s no cloning or creating mirror databases with the same data, without some sort of programmatic intervention.
When your dataset is small, this isn’t too bad.
When your dataset is large and has bad structures, cloning a database can be a costly exercise. Why? Because Firebase charges based on reads and writes. If your data is not structured in the most efficient manner, it can result in a doubling the bill (one bill for reading one database and another for writing to your clone mirror).
While paying for only what you use can be a perk, when leveraged and utilized properly, it can also be your application’s downfall if cost management is not part of your thinking process.
Firebase might be quick and easy to boot up, you still need to think about how your data is going to look and where it’s going to go. It’s not hard to suddenly find yourself racking up massive costs when a page’s data request results in 50 read requests to the Firebase database.
How is this possible? Imagine a cart page — you have your cart details, your individual product lines, your user information, your ancillary details, upsells, cross-sells, promotions, and whatever else you can potentially put in a cart checkout page. This list already has seven things listed. Now imagine a customer with more than three items added to the cart. Your data requirements are already starting to creep up.
The issue with many devs picking up Firebase is that we tend to think with a SQL mentality of structuring and querying data. However, this can be your application's downfall because when it comes to getting charged based on requests rather than the hour, the same applications of concepts and structuring doesn’t work.
The annoying parts of Firebase
When it comes to Firebase, many developers find themselves locked into the service through the data and the frontend code created.
While data can be exported (at a price), creating frontend code that’s separated from the process of calling and dealing with Firebase is something that’s not discussed widely enough.
This can lead many devs down the slippery slope of becoming too tightly coupled to the database itself. Although Firebase makes it easy to boot up something from scratch, forward-thinking about your app’s architecture is still required.
To be honest, front end architecture is needed regardless of what kind of project you’re working on. However, a lot of us do fall into the habit of just making things because we can. Cleaning up and structuring is often a last port of thought in these situations.
To decouple your Firebase database from your frontend application, you’ll need to create an extra layer that keeps data services separated from your UI. Most of the time, I just use an adapter or bridge pattern, depending on the situation, predicted future requirements, and potential direction.
Weighing it all up
As a disclaimer, I’m not affiliated with Firebase in any way. This is written from the perspective of a user of the service and what I’ve discovered so far in the two years of working with it for various projects.
The major perk of Firebase is that it takes away a layer of complication that comes with working as a full stack developer. In a way, it’s cheating the fullstack tag and delegating the foundational tasks of setting up servers, backends, and databases to someone else.
This isn’t necessarily a bad thing. Sometimes, you just want to stick to working on the frontend rather than wrangle with data and writing APIs. Firebase’s support of GraphQL also makes life easier through the single interface and standardized methodology of retrieving data.
Firebase’s major downfall also doubles up as a perk. In part, it’s because the strength or weakness of the service is defined by how the developer uses it. While SQL based databases are charged by the hour, Firebase’s pay-per-use model can result in lazy data structures, leading to exponential costs if your application is public-facing and goes viral. This startup, for example, ended up with a $30k bill in 72 hours. No one wants that.
While the potential cost of Firebase can seem overwhelming and dangerous, it shouldn’t deter you. Rather, it should act as a cautionary tale about keeping an eye on how your structure your data.
It should also be noted that Firebase isn’t expected to the final and only solution to your data needs. In the past, I’ve used it more as a hybrid solution with other types of databases to store and manage important master sets of data.
Firebase is good for transient and persistent data, where the structure needs to be flexible and changeable to be in-step with constantly changing demands.
So what’s the final verdict on Firebase after two years?
I still like it, even with its bad parts. Why? Because the bad parts of Firebase are manageable and I can still directly impact and mitigate its effects. There are things that Firebase does better than SQL (which requires a separate backend to act as the interface), and the service comes with its own set of pre-integration that makes the development flow move faster.
Firebase is not bad. While it’s not exactly the perfect service, it does what it advertises — provide a platform that lets you rapidly create applications with a mobile-first approach.