Let me tell you a technical story.
Many years ago, I developed an application with built-in collaboration features. It was a convenient experimental stack that utilized the full potential of early React and CouchDB. It synchronized data in real-time via JSON. . It was used for internal company work, but the broad applicability and potential in other areas were evident.
When trying to sell this technology to potential clients, we encountered an unexpected hurdle. In the demo video, our technology looked and worked great, no problems there. The video showcased exactly how it operates, and nothing was simulated. We devised and coded a realistic use case for the program.
In fact, this became the issue. Our demo operated exactly how everyone else simulated their applications. Specifically, the information was instantaneously transmitted from A to B, even if it were large media files. After logging in, every user saw new entries. With the application, different users could collaboratively work clearly on the same projects, even in the case of an interrupted Internet connection somewhere in a village. Implicitly, this is suggested in any After Effects cut video about a product.
Despite everyone knowing what the Refresh button was for, no one truly understood that the web applications they asked us to create were usually subject to their limitations. And that if they were no longer needed, the user experience would be entirely different. Mostly, they noticed that they could 'chat' by leaving notes for their interlocutors, so they wondered how this was different from Slack, for example. Ugh!
The design of everyday synchronizations
If you already have software development experience, it must frustrate you to remember that most people can't just glance at an interface image and understand what it will do when they interact with it. Not to mention what happens inside the program itself. Knowing what take the parameter is supposed to happen is largely a result of knowing what cannot happen and what should not happen. This requires not only what the software does, but also how its individual parts are aligned and communicate with each other.
A classic example of this is a user staring at spinner.gif, wondering when the task will finally finish. The developer would understand that the process has likely stalled, and that the GIF will never disappear from the screen. This animation mimics the completion of work but is not connected to its actual state. In such cases, some techies like to roll their eyes in disbelief at the level of users' misconceptions. But notice, who among them points to the spinning hourglass and says that it is actually standing still?
This is the essence of the value of real-time. Nowadays, real-time databases are still used very little, and many view them with suspicion. Most of these databases lean heavily towards NoSQL style, leading to the commonly used Mongo-based solutions that are better off forgotten. However, for me, it means enjoying working with CouchDB and exploring the design of structures that a bureaucrat won't just be able to fill with data. I believe I'm spending my time more wisely.
But the real topic of this post is what Iām using today. Not by choice, but due to the indifferently and blindly applied corporate policy. Therefore, I will provide a Completely Honest and Unbiased comparison of two closely related products for real-time database work by Google.
Both titles contain the word Fire. One I recall fondly. The other is a different kind of fire for me. Iām in no rush to name them because as soon as I do, weāll encounter the first major problemānames.
The first is called Firebase Real-Time Database, and the second is Firebase Cloud Firestore. Both are products from the Firebase suite by Google. Their APIs are called, respectively, firebase.database(ā¦) and firebase.firestore(ā¦).
This happened because the Real-Time Database was simply the original Firebase before Google acquired it in 2014. Then Google decided to create a parallel product based on the company's big data and named it Firestore with a cloud. I hope youāre not confused yet. If you are, don't worry, I rewrote this part of the article ten times myself. Because you need to specify of Firebase based on the company's big data and called it Firestore with a cloud. I hope you havenāt gotten confused yet. If you have, donāt worry, I rewrote this part of the article ten times myself.
Because it is necessary to state Firebase in the matter of Firebase, and Firestore in the matter of Firebase, at least to be understood a few years ago on Stack Overflow.
If there were an award for the worst naming of software products, this case would certainly be a contender. The Hamming distance between these names is so small that it confuses even experienced engineers, whose fingers type one name while their mind thinks of another. These are plans that failed spectacularly, conceived with the best of intentions; they fulfilled the prophecy that the database would be on fire. And I'm not joking. The person who came up with such a naming scheme is responsible for blood, sweat, and tears.
Pyrrhic victory
One might think that Firestore is a replacement for Firebase, its next-generation descendant, but that would be a misconception. Firestore is definitely not suited to replace Firebase. It seems that someone stripped everything interesting from it, and most of what's left is confusing in various ways.
However, a quick glance at the two products can mislead you: it seems that they do the same thing, mainly through the same APIs and even within the same database session. The differences are subtle and can only be detected through a careful comparative study of the extensive documentation. Or when you try to port code that works perfectly on Firebase to work with Firestore. Even then, you find out that the database interface lights up as soon as you attempt to drag-and-drop in real time. I repeat, I'm not joking.
The Firebase client is polite in that it buffers changes and automatically retries updates, giving priority to the last write operation. However, Firestore has a limitation of 1 write operation per document per user per second, and this limitation is imposed by the server. When working with it, you have to find your own way to bypass it and implement a rate limiter, even when you're just trying to build your application. In other words, Firestore is a real-time database without a real-time client, masquerading as one through its API.
This is where we begin to see the first signs of the purpose of Firestore. I may be mistaken, but I suspect that someone high up in Google's management looked at Firebase after the acquisition and simply said, "No, oh my god, no. This is unacceptable. Not under my leadership."
He came forth from his chambers and proclaimed:
"One big JSON document? No. You will split the data into individual documents, each no larger than 1 megabyte."
It seems that such a limitation will not survive the first encounter with any sufficiently motivated user base. You know itās true. For instance, we have over a thousand presentations at work, and thatās perfectly normal.
With that kind of limitation, you will have to accept the fact that one 'document' in the database wonāt resemble any object that a user might call a document.
"Arrays of arrays that can recursively contain other elements? No. Arrays will only contain fixed-length objects or numbers, as the Lord intended."
So if you were hoping to fit your Firestore GeoJSON in, youāll find it impossible. Nothing multidimensional is allowed. I hope you love Base64 and/or JSON inside JSON.
"Importing and exporting JSON over HTTP, command line tools, or admin panels? No. You will only be able to export and import data to Google Cloud Storage. Thatās how itās called now. And when I say 'you', I mean only those who have Project Owner permissions. Everyone else can go and create tickets."
As you can see, the FireBase data model is easy to describe. It consists of one enormous JSON document linking JSON keys to URL paths. If you write using HTTP PUT downward API support (simultaneously with this in / FireBase the following:
{
"hello": "world"
} Then GET /hello will return "world".It mainly works just as you expect. A collection of FireBase objects /my-collection/:id is equivalent to a JSON dictionary {"my-collection": {...}} at the root level, its contents accessible in /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}This works great as long as each insertion has non-colliding IDs, for which the system has a standard solution.
In other words, the database is 100% compatible with JSON (*) and works great with HTTP, for example, with CouchDB. But primarily, you use it through a real-time API that abstracts websockets, authorization, and subscriptions. The admin panel has both capabilities, allowing for real-time editing and JSON import/export. If you stick to the same in your code, you'll be surprised at how much specialized code will vanish when you realize that patch and diff JSON solve 90% of routine persistent state processing tasks.
The Firestore data model resembles JSON but differs from it in several critically important aspects. I have already mentioned the absence of arrays within arrays. The model of sub-collections is for them to be first-class concepts, separate from the containing JSON document. Since there is no ready serialization for this, specialized execution paths are required to read and write data. You need to write your scripts and tools to handle custom collections. The admin panel allows you to make only small changes one field at a time and does not have import/export capabilities.
They took a real-time NoSQL database and turned it into a slow non-SQL with auto-merge and a separate non-JSON column. Something like GraftQL.
Hot Java
If Firestore was supposed to become more reliable and scalable, the irony is that the average developer will end up with a less reliable solution than choosing Firebase 'out of the box.' The software that the Grumpy Database Administrator needs requires such a level of effort and caliber of specialists that it is simply unrealistic for a niche that supposedly should have a good product. Itās similar to how HTML5 Canvas is not a replacement for Flash if there are no development tools and players. Moreover, Firestore is mired in striving for data purity and sterile validation, which simply does not align with how the average business user likes to work: everything is optional for them because in the end, everything is a draft.
The main drawback of FireBase is that the client was created several years before its time, even before many web developers learned about immutability. Because of this, FireBase assumes that you will be modifying data and therefore does not take advantage of user-enforced immutability. Additionally, it does not reuse data in the snapshots sent to the user, making it much more challenging to perform diffs. For large documents, its transaction mechanism based on mutable diffs is simply inadequate. Guys, we already have WeakMap in JavaScript. It's convenient.
If the data is given the right shape and the trees are not made too bulky, this problem can be circumvented. But I'm curious, would FireBase be much more interesting if the developers released a truly good client API that utilizes immutability along with serious practical advice on database structure? Instead, they seem to have tried to fix what isn't broken, and it just got worse.
I don't know all the logic that went into the creation of Firestore. Speculating about the motives arising inside a black box is part of the fun too. Such a juxtaposition of two incredibly similar yet incomparable databases is quite rare. It's as if someone thought: "Firebase is just a function we can emulate in Google Cloud", but at the same time has not yet discovered the concept of defining real-world requirements or creating useful solutions that meet all those requirements. "Let the developers think about that. Just make the UI look niceā¦ Can we add more fire?"
I understand a couple of things about data structures. I can clearly see that the concept of "everything in one big JSON tree" is an attempt to abstract any feeling of large-scale structure from the database. Expecting the software to simply handle any questionable fractal of a data structure is just madness. I don't even need to imagine how bad it can be; I've conducted tough code audits and I've seen things that you, people, wouldn't even dream of.. But I also know what good structures look like, and I can imagine a world where Firestore would make perfect sense, and the people who created it would believe they did a good job. But we don't live in that world.
The support for building queries in FireBase is poor by any standard; it is virtually non-existent. It definitely needs improvement or at least a reevaluation. However, Firestore is not much better since it is limited by the same one-dimensional indexes found in basic SQL. If you need queries that people execute with chaotic data, full-text search, multi-range filters, and arbitrary user-defined ordering are required. Upon closer inspection, the features of basic SQL are too limited on their own. Moreover, the only SQL queries that people can perform in production are fast queries. Youāll need a specialized indexing solution with well-thought-out data structures. For everything else, there should at least be incremental map-reduce or something similar.
If you search for information about this in the Google documentation, hopefully, it will point you in the direction of something like BigTable and BigQuery. However, all these solutions come with such a load of dense corporate sales jargon that you'll quickly find yourself back searching for something else.
The last thing you need in a real-time database is something created by people and for people working on a salary scale for management.
(*) Itās a joke; thereās no such thing as .
Advertising
Looking for a server for debugging projects, development, and hosting? You are definitely our client š Daily pricing for servers of various configurations, anti-DDoS, and Windows licenses are already included in the price.
Source: habr.com
