This article is the first part of a series about getting started with Firebase.

I will introduce you to what Firebase is, its strengths, but also shortcomings you should consider if you're planning on writing a new project.

What's Firebase?

Firebase is Google's owned PaaS, a service that enables developers to build and deploy web and mobile applications.

We could also label Firebase as a user-friendly skin on top of Google Cloud Platform (GCP), a vast suite of Cloud products thought for larger projects.

Every Firebase project is also a GCP project: it's possible to use the GCP console and other services (more about this ahead).

Firebase comes with its own set of independent products for increasing the Developer Experience and making building an application an easier feat than ever before: DX-friendly SDKs, a fully-local Emulator Suite, Extensions, and more, make Firebase an ideal service for both developers and end-users.

Pricing-wise, Firebase is likely one of the cheapest options on the market: it comes with a highly generous free-plan and fair pricing after that, which makes the service suitable to developers and teams of any size.

Is Firebase for Mobile or Web Applications?

Many think Firebase is exclusively for Mobile applications: while there's some truth in that statement, it's not the case.

Firebase has many features that can work only on mobile applications, such as Crashlytics, Machine Learning, Dynamic Links, Messaging, and more.

So, Firebase may be an excellent skin on top of GCP leaning towards mobile apps: this does not mean that it's unreasonable or wrong to use Firebase for web applications. Not at all.

There's a lot more to Firebase than the features above. It also allows you to:

• use authentication with many 3rd party providers (such as Google, Facebook, Twitter, etc.)
• use invisible ReCaptcha v3 protection with Firebase AppCheck
• use two types of Databases according to your needs (Firestore and Realtime DB)
• upload any object on Firebase Storage
• host your web pages, scripts, styles, etc., on Firebase Hosting
• execute any back-end code with Firebase Cloud Functions
• have baked-in Google Analytics with advanced segmentation and audiences
• use Remote Config for feature flags, A/B tests, and settings configurable by advanced segmentation

Any non-trivial (web or mobile) application will end up needing support for the above, and Firebase makes using them a breeze.

What shortcomings does Firebase have?

Despite being a fully-featured platform, Firebase does lack some features, which makes it unsuitable (by itself) for specific applications.

If you decide to use Firebase for your next project, you should also consider the following cons.

Lack of Full-Text Search

One of the most significant gripes with Firebase is the lack of full-search text in both of its databases products.

It's fair to say that most applications have some full-text search, and Firebase won't help.

In these cases, it's suggested to index the data using a third-party service, such as Algolia (which has a Firebase-built extension), ElasticSearch, TypeSense, etc. Alternatively, to use a different database in the GCP offering that supports it.

The downside to this is that you will need to manage and copy the data in multiple databases. In addition, the data will only be able to be read by using Cloud Functions' external network requests; that means your account will have higher billing costs as a result.

Weirdly, THE search company doesn't allow search, but for now, the alternatives above will be your best bet if "search" is an essential part of your project.

The inability of setting "real" billing budgets

Firebase allows to set billing budgets in the GCP Console, but these are limited to sending notifications to the project owner, rather than disabling the project itself, for example.

This issue affects many developers scared of DDoS attacks (for some reason), but most importantly, coding errors that make tons of requests are far more common.

A simple Google search will show many stories about sky-high invoices due to errors.

Far too many I've talked to are skeptical about adopting Firebase due to this. However, it's fair to remind you that the company waived large invoices caused by programming mistakes in many situations.

Slow Cold starts

A cold start affects Cloud Functions, e.g., the product to build fully custom back-ends.

Whenever your function scales down to 0 instances (for example, during periods of inactivity), the functions wake up from scratch; it's common and expected in the serverless world, with no definitive way to entirely remove these from the equation.

The issue is more accentuated when a cloud function uses Firestore, but it's a well-known issue: cold starts are particularly slow. As slow as 15 seconds, in my experience.

Slow cold starts can make Functions, not the best product for serving data in customer-facing products.

Vendor Lock-in

Vendor lock-in is likely the most considerable downside of using a fully-featured PaaS, in this case, Firebase.

A sizeable part of the developer community is not in love with Google for various reasons, among which:

• its tendency to shut projects down very easily
• the (rare) shut-down of accounts out of the blue

And with this, I can relate a lot.

There's a nagging feeling that a Google technician could, out of the blue, decide your app violated a rule, and as a result, suddenly suspend your account.

This sort of event, while rare, is something I'd encourage everyone to take into account.

What are Firebase's greatest strengths?

Now that we've talked about the bad parts of Firebase, let's focus on the good ones.

Firebase will be a valid option at any size, but where it shines is being a product for Front-end developers who want to build full-stack applications by themselves.

As a (primarily) front-end developer, I understand.

The ability to build fully-featured full-stack applications was always a dream of mine: nothing made it as easy as Firebase does.

Easy Databases Products

Databases can be intimidating. Realtime DB and Firestore go out of their way to be as approachable as possible.

As a very inexperienced database designer when I was starting, having something as simple as Firestore was crucial in overcoming the imposter syndrome and fear of messing up.

While it is too simple for some people, and the limitations make it unsuitable for some tasks, Firestore is one of the easiest DBs you'll find, making it perfect for beginners.

One thing to watch out for is that Firestore is a NoSQL DB, and it is not relational. I found designing for NoSQL a bit harder than relational databases, especially for the limited literature about the former.

It's easy to start but just as easy to make bad decisions with it.

Fully Serverless Backend

Thanks to both Firestore and Realtime DB, You'll be able to make 90% of your application's data-fetching using the Firestore client SDK (e.g., you don't need to write specific back-end code).

However, there will be many situations where you will be required to code custom Cloud Functions: for example:

• for fetching data from an external API
• performing heavy DB operations
• sending emails
• etc.

The good news is that Firebase will take care of the infrastructure for you; no more messing around in complex consoles, working on stuff that doesn't directly contribute to your project's success.

You focus on the product: for front-end developers, this is a god-send.

Vast GCP ecosystem

Firebase may lack basic functionality for larger projects, such as caching, asynchronous tasks execution, secrets manager, etc.

Fortunately, as we've said before, every Firebase project is a GCP project; that means you can use products such as Cloud Tasks, Cloud MemoryStorage, and the rest of GCP's products roster.

Final Words

Even if not perfect, Firebase is one of the best cloud providers out there.

Its simplicity, fair-pricing, community, etc., make it a valid option for kick-starting your project and scaling with it.

Remember: if you ever outgrow the Firebase Platform, graduating to GCP is a seamless process.