5 reasons why you should use Firebase

A while ago, in one of my blog posts, I discussed a few reasons why you shouldn’t use Firebase and some potential alternatives to this serverless platform. However, I didn’t feel so good leaving it as-is, because I’m a frequent Firebase user myself.

So, today I’m flipping the switch and instead of talking about alternatives and downsides, we’re going to talk about all the advantages that Firebase provides and why you might consider using it for your next project. You can see it as a kind-of Firebase primer/overview if you’re new to the service or as a reassurance of your choice if you’ve already used it. Either way, I hope you’ll enjoy it and find it useful. Let’s dive in!

Free tier

Starting with the most obvious reason - Firebase has a really good free tier. The so-called “Spark plan” provides you with quite generous usage limits (one of the top offerings in the business as far as I know) for all of Firebase products. You can find more details on the pricing page.

Free tier tips

Now, the free tier is really good as is, but I’d like to point out a few things to keep in mind to better utilize its potential.

First off, it’s important to remember that we have a few completely free services, like Authentication, and Cloud or In-App Messaging. These services, although often missed, boost Firebase’s already tremendous value by a fair bit. You get them completely free no matter the plan, so if you’d use only those few services, you might get away with paying nothing.

Secondly, the cost for services like Firestore, Realtime Database (RTDB), and Cloud Functions depends heavily on your usage.

The first two serve the same purpose (realtime database), with Firestore being newer and coming with some additional perks. However, differences in storage models aside, it’s the pricing that matters the most. Firestore can handle more concurrent connections and writes per second, but additionally, apart from “usual” storage and data transfer costs, it charges for the number of reads and writes. RTDB on the other hand can handle a bit less (with low free plan limitation of only 100 concurrent connections presumably for the initial push to using Firestore), and charges only for the stored data and GB transferred (only a bit higher than Firestore). Thus, depending on your use-cases and scalability requirements, you might be better off going with the older RTDB than the shiny new Firestore.

The same goes for Cloud Functions - the pricing depends heavily on your usage. With some initial planning, you might be able to pay less, while not missing out on functionality.

And lastly, some Firebase products like Hosting can still be replaced by other services, while still using the other Firebase products. In this case, the first service that comes to mind is Vercel, which might allow you to pay nothing, but again - depending on your use-cases.

These are only some general tips from the top of my head, but let me know in the comments if you’d like to see more of those in a potential follow-up post.

Full package

Getting back to the main topic, we’ve got another Firebase advantage - the fact that it’s kind-of a full package.

When researching the previous “Firebase alternatives” blog post, I must admit that my appreciation for Firebase slightly grew. The fact that this single platform provides pretty much everything that an average serverless app would require is really hard to compete with.

From hosting and database, through static storage, messaging, analytics, and app distribution to cloud functions and machine learning, Firebase is truly an all-in-one solution. Sure, you can always go and find some better alternatives for each of these products individually, but I guarantee you won’t achieve the same level of integration and polish between them, as you would with Firebase.

Easy API

Speaking of polish, Firebase API is simply a pleasure to work with. Now, I’m a web developer, so everything I say here is mostly related to the Firebase JavaScript SDK. I know that Firebase provides SDKs for other platforms such as Android, iOS, C++, or Unity and I assume these are equally good, but just keep in mind that I can only speak of my personal experience.

And I must admit - my personal experience has been really good so far! Support for CDN, as well as more in line with current times NPM installation, as well as full TypeScript support with detailed typings, is nice to see.

Beyond that, the overall structure and feel of the API are also really good. When using NPM, everything is structured into modules, which can then be imported when needed, thus keeping the resulting bundle size to a minimum.

Great docs & community

An important detail that boosts the API usability is of course good documentation. And here, Firebase also doesn’t let down (at least from my JS SDK experience).

Detailed API reference, number of guides, sample projects and code snippets, as well as a vast library of community-curated content created by Firebase users from around the world, makes solving any potential problems a breeze.

“Serverless standard”

Lastly, with all these points in mind, Firebase is a de-facto standard and go-to choice for the vast majority of serverless apps. The all-in-one package, a great set of features, API, and community, coupled with years of experience and presence on the market are all benefits of Firebase.

Now sure, for anything more complex or custom, you might be better off with a cloud provider like Google Cloud Platform (GCP), Amazon Web Services (AWS), or Microsoft Azure. However, all these platforms (related costs aside) have a certain level of complexity associated with them. If you want simplicity and are sure that Firebase suites your needs, then by all means go for it. Even if you change your mind down the line, the integration that Firebase has with GCP (it’s a Google service after all) will make your transition smooth down the line.

Opinions anyone?

So, these are (in my opinion) the biggest and most important advantages of Firebase. Again, if you want the other take on this (i.e. downsides and potential alternatives) then I encourage you to go and check out my previous article.

Either way, let me know your thoughts on Firebase. Do you use it in any of your projects, or maybe you’re planning to after reading this post? Can you think of any additional advantages or disadvantages that the service has? The comment section is yours!

For more up-to-date Firebase and web development content, be sure to follow me on Twitter, Facebook, or through my newsletter. Thanks for reading this piece and happy coding!