Firebase Pros and Cons

and How to Deal With the Cons

Pros:

• JSON (Javascript Object Notation) storage means no barrier between data and objects
• simple serialization of app state
• 3-way data binding via Angularfire
• minimal setup
• easy access to data, files, auth, and more
• no server infrastructure needed to power apps with data
• massive storage size potential
• real time
• pretty much the most advanced hosted BaaS solution
• highly secure
• serverless
• hey, it’s Google!

Cons:

Update. These cons are based on the original “Realtime Database”.
Things have changed with new “Cloud Firestore”, which has a few cons itself, but I won’t go over that now. The new Firestore is designed by Google specifically for Enterprise use, whereas the original database was developed by another company that got bought by Google. The new Firestore has improved querying significantly and offers aggregation solutions.

• not widely used or battle tested for Enterprises
• very limited querying and indexing
• no aggregation
• no map reduce
• can’t query or list users or stored files

The Problem

TL;DR — If you understand data storage, the problem is that JSON can be disorganized and forms a tree shape that’s hard to navigate and search.

In my opinion the pros definitely outweigh the cons and I’m sticking with Firebase. However, those are some really challenging cons. Storing your data is a snap! Oh, I’m sorry, were you hoping to get your data back?
Uhhhh, well, um, yeah, see, the thing is…
From an old Firebase blog post: “Querying has been a frequently requested feature…” Um, it’s a database (OK, technically a data store). Querying shouldn’t need to be a requested feature.

So why has Google come up short in this critical aspect of their data store? The problem lies in the structure of the data.

Traditional databases (RDBMS) use tables and reference keys (think linked spreadsheets) to store and organize data. This has worked well for years. However, the RDBMS has run into issues recently when dealing with massive amounts of data. Also, the data that comes out of an RDBMS needs a lot of preprocessing before it can be communicated consistently and presented in a human readable way.

The most prevalent solution has been JSON based (NoSQL). JSON stores data as loose objects, rather than as rigid tables. JSON data takes a tree shape, so each unit of data data can contain more data that contains more data. It’s turtles all the way down. JSON removes a lot of the constraints from the RDBMS in favor of scalability and standardized data containment. JSON is excellent for AJAX communication and can be treated like native objects by Javascript. These 2 features make JSON ideal for web based data communication.

The RDBMS tables are predictable, rigid, predefined, and easily indexed so they can be searched without too much difficulty. With JSON, there are no constraints to data structure at all. You can store your data in the most haphazard sloppy way imaginable, no problem. (I don’t recommend this.) And what’s more, Firebase lets your objects nest up to 32 levels deep. So you can have a million objects, that all contain a million objects, that all contain a million objects… And none of those objects need to adhere to any sort of structure whatsoever.
Seriously, turtles all the way down.

So how did Google handle this nightmarish problem of data searching that could potentially crash their servers with horribly structured ginormous data stores?
They didn’t.
For now, that’s your job.

In short, the problem is that we need a way to retrieve our data when our objects have any kind of relationship with each other.

The Solutions

FYI — These solutions are theoretical in nature. I intend to share more concrete solutions in the future.

Addressing the cons in order:

• enterprises — The tech is still new; give it time.
• querying — DIY organization.
• aggregation — Firebase may not be right for you.
• map reduce — It’s available for other JSON data stores. I believe it may yet be coming.
• stored users and files — Duplicate the items as data with a reference to the users or files.

So let’s break down solutions for Querying.

We could try using a tool like Flashlight or MongoFB. Both of those solutions require having a server, which for me, defeats the purpose of using Firebase in the first place. Looks like we just have to get our shit together and organize our data ourselves.

Once again, I can think of 2 options. We can take an Object Oriented approach or we can alter our data to be more self-reliant.

The Object Oriented approach.

TL;DR — This doesn’t work.

Let’s say we’re making a travel log app and we want to allow people to upload a bunch of images and assign one image to each destination.
We’ve established that we need to store image data in addition to the images themselves.
That might look something like this:

{
  "trips": {
    "trip_1_id": {
      "destination": "Disneyland",
      "description": "The happiest place on earth!"
    },
    "trip_2_id": {
      "destination": "Paris, France",
      "description": "The happiest place on earth!"
    },
    "trip_3_id": {
      "destination": "Siberia",
      "description": "The happiest place on earth!"
    }
  },
  "images": {
    "image_1_id": {
      "location": "The Haunted Mansion",
      "notes": "I see dead people.",
      "download_URL": "some firebase storage location"
    },
    "image_2_id": {
      "location": "The Eifel Tower",
      "notes": "'It looks like a giant p...'; 'Hush now Billy!' 'projectile, what?'",
      "download_URL": "some firebase storage location"
    },
    "image_3_id": {
      "location": "Snow",
      "notes": "Winter is coming.",
      "download_URL": "some firebase storage location"
    }
  }
}

So when we want to assign an image, we remove it from images and stick it in trips.
Done!
But wait, what if we want another page that shows a list of all pictures and where they’re assigned.
Now we need to query all trips… but we can’t and that’s why we stuck the data in there in the first place.
Blaaaarrrgghhhhh!

The data-centric approach.

TL;DR Duplicate all your data or create a linking scheme.

One solution is to duplicate all the image objects and put them in with each trip. This is an acceptable approach in certain situations. Since the data store is designed to house massive amounts of data, a reasonable amount of duplication is not going to break your data. It requires more maintenance and forethought however. And it can lead to problems with stale data that may or may not be an issue.

Another solution is to create bi-directional references with only a little duplicate data like so:

{
  "trips": {
    "trip_1_id": {
      "destination": "Disneyland",
      "description": "The happiest place on earth!",
      "linked": "true",
      "linked_to_id": "image_1_id",
      "linked_to_name": "The Haunted Mansion"
    },
    "trip_2_id": {
      "destination": "Paris, France",
      "description": "The happiest place on earth!",
      "linked": "false",
      "linked_to_id": "",
      "linked_to_name": ""
    },
    "trip_3_id": {
      "destination": "Siberia",
      "description": "The happiest place on earth!",
      "linked": "false",
      "linked_to_id": "",
      "linked_to_name": ""
    }
  },
  "images": {
    "image_1_id": {
      "location": "The Haunted Mansion",
      "notes": "I see dead people.",
      "linked": "true",
      "linked_to_id": "trip_1_id",
      "linked_to_name": "Disneyland",
      "download_URL": "some firebase storage location"
    },
    "image_2_id": {
      "location": "The Eifel Tower",
      "notes": "'It looks like a giant p...'; 'Hush now Billy!'; 'projectile, what?'",
      "linked": "false",
      "linked_to_id": "",
      "linked_to_name": "",
      "download_URL": "some firebase storage location"
    },
    "image_3_id": {
      "location": "Snow",
      "notes": "Winter is coming.",
      "linked": "false",
      "linked_to_id": "",
      "linked_to_name": "",
      "download_URL": "some firebase storage location"
    }
  }
}

This is my preferred solution. The only disadvantage here is that you have a trade off in deciding how much data to duplicate as that becomes a maintenance issue. But if you don’t duplicate all your data you’ll have to make multiple server calls. The big advantage here though, is that there is consistency in naming and structure. That means that you can write reusable boiler plate code to maintain your links.

Summary

You may have to jump through a few hoops to get things to meet your expectations with Firebase. The tradeoff is that your app can be up and running in a small fraction of the time it takes to get a server based app up and running. And once your app is up and about, it takes a lot less work to evolve and manipulate your database schema.

I say Firebase is still the best solution for a BaaS. And it’s likely to only get better.