Navigating BaaS Providers: Understanding Firebase in Business Applications

Where’s the best place to deploy bespoke software?

You could optimize any and all of:

• Your cloud bill
• Provider robustness
• The sum of all costs associated with deployment, i.e. cloud costs plus man hours

Firebase walks the line on ease of deployment and scale pretty well. Being part of the Google Cloud Platform family, it also fits in with a wide array of other services. K-Optional used to recommend Firebase for all web endeavors. In 2022, we moved away from Firebase for green projects. Even so, we are still quite invested in the product, maintaining a dozen or so active apps. This then is an attempt to distill the advice we give to Firebase clients.

What is Firebase

Firebase is a backend-as-a-service (‘BaaS’). That means it provides custom cloud computing, but within a sort of framework. The good news is you won’t have to wrangle cloud resources or coordinate groups of nodes. The bad news is that if you want to do those things, you’re out of luck.

Some stuff comes out of the box but at the expense of choice. With Firebase, cross off a few of the bespoke software essentials like a database, frontend hosting, and file storage, but get used to JavaScript-only server code, NoSQL persistent data, and SPA hosting.

It’s batteries-included with Firebase

Avoiding bespoke software pitfalls on Firebase backends

Aspects of Firebase are prone to misuse which will have palpable effects on your business. We’ve advised clients who stepped into these traps; either resolve to avoid them or weigh the risks when deciding where to house your bespoke software.

Database administration

You should want to have a window into your application’s data. In doing so, you lessen the gap between your business and the system that underpins it.

The Firestore browsing dashboard leaves a lot to be desired

We’d advise you to have your bespoke software vendor set-up data dashboards with precise metrics. Don’t employ the Firebase dashboard for your insights! Accidentally touching live data can mess with your application. More unique to this platform though, Firebase & Firestore poorly illustrate system records and their relationships:

• NoSQL data doesn’t fit the familiar spreadsheet-esq view.
• Firestore collections nest within other collections, so you could have to hunt a little to find the “table” you care about.
• Custom Triggers tend to distribute data and obscure the single source of truth you expect.

Finally, the Firebase GUI leaves a lot to be desired. If you really want to look at raw Firestore data, Firefoo is the best option.

n+1

“Joins” and “pivot tables” don’t exist in NoSQL databases.

Firebase and Firestore adopt a purist approach, not enabling any sort of combo query for two or more models. In the long term, you can develop robust custom apps by embracing NoSQL. But inept bespoke software vendors always seem to make the same mistake with Firestore: the n+1 query.

Imagine that you are building a custom apparel storefront on Firebase. Let’s say that the database has one table with related purchases and another with product info. An inexperienced software company might ask the database for a shirt’s related_purchases and for each then follow-up and ask for the price.

Make a single query for this storefront data [Source: TailwindUI]

That means we have incurred 5 read operations instead of 1 for this data, which has dramatic effects on your cloud bill and user experience.

Vulnerabilities

Below we touch on Firestore Rules and how nice they can be.

Failing to employ good rules undermines your whole system. Since so many companies turn to Firebase, hackers can easily target a large cohort automatically. We actually see this quite a bit in our logs— unsavory internet users testing to see if they can access something they’re not supposed to. And unfortunately we also see lots of folks who neglect database security.

By virtue of Firestore being so flexible, it can attract developers and firms that lack attention to detail. Ask your vendor about their ideas on securing the database; hopefully you can tell if they haven’t given bespoke software security much thought.

Database backups

Everyone knows how important it is to periodically backup data, just ask Myspace.

Unlike say, Supabase, Firebase hasn’t supported automated backups right out of the box. Instead your software vendor must write custom code to save snapshots. Make sure they do this, 100%.

Nice Firebase Features: Safe Software & More

Firebase rules

Firebase Rules secure Firestore Databases. People often ask how they can keep data safe if the client can subscribe to any collection; the trick is to know how they work.

Firebase lends itself well to a lean and active development cycle. Consider the baked-in database security mechanism:

• The browser or mobile app calls the shots: instead of writing server code to define all your logic, the “frontend” app can alter your database on the fly.

A traditional API is a bit like a CD in that songs are encoded ahead of time— like API endpoints. The listener can choose any song that’s already on the CD. In contrast, the client-side access model of Firestore compares to a music streaming service; you can string together a dynamic query like someone can string together a playlist on the fly.

• To prevent misuse like illicit database access, you encode who can do what with Firebase rules. A plain English version of these rules looks something like this:

  • “Users who login can access messages in their groups”
  • “Users can only create messages that have a sender_id matching their user_id.”
  • “Users cannot delete messages”

The rules vs logic split turns out to be quite convenient. It enables you to segment your efforts, and be deliberate with how you want users to access data. With a more conventional application, you might write security logic next to business logic. That model tends to muddle both, and also fails to communicate your app security policy.

Firebase Rules offer another advantage: a superior prototyping experience. Trying to build a demo? Worry about rules later. You can focus on functionality and then secure your application before putting it on the live web. This helps a lot during a proof of concept when you haven’t solidified your data model yet. If you end up modifying some table (called a collection in the context of Firestore), then you haven’t lost any time writing rules that you will throw out.

Finally, Rules tend to be lightweight. With an API-centric framework like Laravel— which, by the way, is a great framework— security code exists in multiple places (middleware and request validation to name a few), taking up a lot more space.

Real-time data for free

As web users in 2023, we’ve gotten used to a “realtime experience”; we take for granted the work that eliminates the manual refresh. That logic isn’t trivial: it may involve a 3rd party integration (i.e. Pusher), a custom Websocket or server-sent events integration, or clunky, timed background checks.

With Firebase, our apps can subscribe to changes in the Firestore database. That means that if one user inserts a message into a chat collection, another user could see it without any added logic (provided that meets the Firestore Rule configuration).

If your envisioned application includes realtime data, then Firebase can reduce the amount of system engineering your vendor will have to do.

Is Firebase the right BaaS provider for your business application?

People build great things on Firebase, and unlike other quick-start cloud frameworks, it scales.

For better or worse, the fault mostly falls on the artisan and not the tools when it comes to bespoke software. So by elucidating the strengths and weakness of this tool, we hope to help you vet the people holding it. Don’t hesitate to reach out with any questions about Firebase or your bespoke software.