Think of the Firebase query API as a stream management API
Those words are paraphrased on a best effort basis from a conversation with Google Developer Expert Chris Esplin last night.
The more I dig into the Firebase platform (read: the database), the more I feel that it’s a largely underestimated technology. Actually, “underestimated” is not the word. But it’s the first that comes to my mind. Perhaps “misused” is better?
Looking at the amount of websites on Firebase is also somewhat confirming that; there are more website’s that has historically used Firebase than there are websites currently using it. I find that interesting.
We know of 13,867 live websites using Firebase and an additional 16,918 sites that used Firebase historically. — builtwith.com
I don’t think it is that people are abandoning Firebase for something better. I really perceive Firebase as a sticky product. It’s beautifully presented, simple to use and has a fresh take on data storage that packs a punch.
But that’s the thing, I suspect that a lot of those historical websites that has once used Firebase were results of experimental projects or people trying things out, playing around.
Looking at it with the wrong kind of goggles
As a lot of people do, I started my software development career with SQL databases and learning to mentally visualize systems in form of normalized SQL tables. Not until much later I was introduced to NoSQL and relearning about de-normalization.
My first few years of NoSQL was with Couch Database, a document storage that only can be accessed via its HTTP REST API. I wouldn’t say that it was an experience that could be described as an epiphany. But at least it made me curious to dig down further and wider. To one point where I found Firebase.
I didn’t managed to introduce Firebase as a replacement for our outdated version 0.11 of CouchDB, which had dependencies that not even our old Ubuntu LTS x.04 version supported anymore.
Perhaps I failed to convince my team because I failed to communicate the real potentials and powers. Why would we change from one NoSQL document storage to another?
You could use the Firebase query API just as any other NoSQL database, just to find that perhaps the API is not as feature rich. But when you think of the Firebase query API as a stream manager API, it becomes magnitudes more powerful.
What if you had a sorting and selection filter applied to a data stream that is constantly feeding the state of data in the cloud, in real time?
How awesome would that be? The query API is not so much for a question-response interaction as it is a viewing-angle of the data set. With your query API you are configuring you app to hold a filtered state of your data. Not to mention how all of your clients uniformly agree on the state that you’re seeing.
As I say it, I kind of think that’s how I liked to think that my apps were doing it in a traditional setup with SQL storage before also. But remember how those views are built up by a (more or less) frequent querying to a state at the time of the query. And each result needs to be applied to the UI in a strategy that is best representing the new changes. With Firebase, representation is default.
In the following weeks I will be following up with a practical example of using Firebase as a “traditional NoSQL document storage” and at the same applying queries on that data in a way that makes it easier to see how it can actually be seen as a stream management API.