Finally here I sit getting time to write. I know, I know, my very short first post was nearly 4 months ago, what gives! Well time has a way of not relenting when you want to do fun things like write blogs posts. I will do my best to not let it happen again! I have some exciting stuff that I am working on right now that I can’t wait to tell the world about soon. Anywho, here we go!
FIRESTORE!!! Why it is (soon) my new jam! So first some background about Firestore. Firestore was released October 3, 2017 out of Alpha to the world. Many celebrations occurred, maybe a couple riots, it was a crazy time. Not really, but it was exciting none the less. Much like Real Time Database, Firestore is a cloud NoSQL datastore. I think the most common question I heard in those early days was ‘I thought RTDB was a cloud NoSQL datastore, why are they creating yet another one?’. The answer to that is that while RTDB is indeed a NoSQL store, and a fantastic product, Firestore is the evolution of that idea. It builds and improves in certain ways that are not really compatible and has very much its own way of fitting into the Firebase ecosystem. That is what I hope to explain here and build on the many great resources already out there on this topic. For this quick high level comparison, go ahead and check out this page, I will wait here RTDB vs. Firestore. Alright, all caught up? I guess our work is done here! Still kidding, as Sheryl Crow once said, “I try to conduct my life with a little levity” ~Internet.
TL;DR Start learning it now, it is what you are going to want in the future to compliment your current setup.
Let’s summarize some of the points on that page and what they mean for you.
One of the things I love and loathe about RTDB is the simplicity of storing JSON the way I expect my app to see it. Part of the problem is that sometimes that is not possible as it would be inefficient with memory and/or redundant causing me to do several look ups. It gives you a great deal of freedom, but can be a real headache when it comes to validation of storage because it is so free. Firestore enforces somewhat stricter principals in that is now stores everything in Documents, which allows you to efficiently store data in collections. You can even have sub collections which was generally frowned upon in RTDB. I know most of us are over flatting our complex data structures, Firestore hopes to solve some of that. Along with this added vantage is that Documents can now enforce and maintain types better. This is a huge win for a number of reasons, but mostly I love it for its explicit nature. Trying to determine if something was stored properly and converted properly could sometimes be a pain, no more here. This is also incredibly useful for sorting purposes which we will touch on next. Lastly the reason this has the most impact is that now, rather than a giant JSON file, we have a distributed store of documents which means we can scale up to millions of records without having a JSON file (and Firebase Console) that locks up on us.
This one is probably my favorite. Anyone that has tried to query data in RTDB knows that is not really a thing. We had to take the approach of “I guess the client is just going to have to load everything” or do the most basic of filters only to then re-filter and sort on our clients. This is fine when you’re talking at most a couple thousand records, but what about apps that need to support millions? Because of the data model discussed above Firestore is the clear winner when it comes to scaling out. With this also comes a significant improvement in getting the data you need. Firestore supports a complex system of filters and sorting that is closer to what you would expect from a traditional database model. This allows us to not have to ingest data that ultimately, we might not use or display saving on costs while improving user experience. I really cannot overstate how helpful and useful this is when it comes to building an enterprise grade product, it was the thing RTDB needed most.
This is sort of the last and most important. Thankfully (or maybe not depending on how you look at it) all of my Firebase projects to this point have been closed systems for enterprise so RTDB has sufficient abilities to handle the throughput I need. I have seen however from being in the community the larger projects operating in this realm have had to start looking into sharding. Now that process if you have already established a structure is actually harder than it looks and is the constant consternation of some of the people dealing with it. This is where Firestore also really shines as it is already at its core a heavily distributed (think multi-region replication) store and I am sure as it leaves beta will really show us what is has got.
So here is where I have to raise the concerns about using this product. The first and most obvious is that this is a product still in beta. Now I know you love going out on the limb and putting beta products into production products, but I might suggest you wait just a little bit before investing on this. There are several large companies however already using this at scale so it is up to you. One thing I have found as the most deterministic argument to wait implementing is load times. I had that tough decision recently on a re-write for a client and wanted to demo some of the new hotness from Firebase. For that demo we needed to load 3000 or so records up front. Now in RTDB, this is pretty efficient and trivial, but to my surprise when trying to do this in Firestore, it was very visibly slow. There are a number of technical reasons for this but mainly it has to do with the offline support and the time it takes to populate the local database. You can see an example of comparison in load times here that I made. RTDB Latency Firestore Latency. You can find the code for those examples on my Github. You can see through those examples how RTDB is very quick (partly because web does not support offline) and Firestore takes 2ish seconds to load. Any “reload” after that is super quick because your local store is populated. This is something the Firebase team is aware of and know they will further iron out. With the immense talent they have, I have no doubt we will see those times drop quickly!
Here is where I tell you which one is better and use it but that is not really accurate advice. Even if you do go to using Firestore fulltime, RTDB can have many great uses as a complimentary partner. Think loading a config up front, the simple nature of a JSON document is perfect for that. I for example when running my CI, inject the values from the angular environment file into my RTDB to have the client compare. They do not match? Looks like the user needs a suggestion of a refresh! These documents load incredibly quick and our pushed into my own state, so I do not need offline support for that! There are many further examples, but the core of the argument is do not think of Firestore as the replacement, think of it is as the new big sibling. Overall, I am super excited to see where Firestore goes and look forward to finding more projects that it fits with to really put it through its paces.
Have any further questions? Find me on twitter, LinkedIn, or email and let’s connect! I would love to help you out!