Google Cloud Firestore is the latest no-sql database offering in the Google Firebase suite of products. Unlike MongoDb, Firestore is cursed with a number of constraints and limitations that can at times seem challenging … but you won’t care because, in spite of all of its problems, its revolutionary new approach to a mobile/web application design will save you time and money.
So what’s so special about Firestore?
Goodbye REST API — If you consider the typical architecture of a mobile or web application you will invariably find yourself using a database and writing a REST API to access the database. Coding the REST APIs is always a tedious task that requires time and energy to build and test. Then you have the task of deploying the REST API on a server somewhere and having to deal with all of the DevOps associated with hosting an API. With Cloud Firestore you don’t need a REST API.
Offline Mobile Database — The benefits of Firestore don’t stop there. For mobile applications, it also provides a local “offline” copy of the database on the device. This enables ultra fast local access to data even we out of network coverage.
Push Updates — Finally the last feature that truly changes the way you create your mobile and web application is the ability for the Cloud Firestore to “publish” data changes to mobile and web clients.
So what’s the catch?
By now you are likely sold on the benefits of Cloud Firestore and are ready to refactor your entire stack … but beware … all that capability comes at a cost. Below are the major limitations we’ve discovered while working with Cloud Firestore and in most cases, how to work around the limitation.
No Unique Constraints on Documents
This was one of the first limitations we ran up against that we took for granted in other databases. Other than the ID of the document, there is currently not way to define a unique constraint on a property in the document.
Workaround — The only way we found around this was to create custom IDs for documents that contained the unique properties. In most cases, there would only be one property that had to be unique, but in a few cases, we would combine two or more properties to create the document id.
Limited Support for Document References
When you query a document, any references it may contain to sub-collections or other documents are not resolved. This is both good and bad. Its good because it ensures that you don’t end up pulling down the entire database when you query a document. The downside is that in those cases when you would rather do a “deep” pull.
Workaround — In the event that you do need to create a reference, do so using its “path” within the database (ex. “/airports/sfo” or “/aircraft/N74BY-258”). With a path you can quickly query the data using the following:
One Database per Project
A project is a Google Firebase concept. It encapsulates all the services that are to be deployed under a particular domain name. For whatever reason, they have determined that you only should have one CloudFirestore database per project.
Workaround — The only workaround is to create projects for each database you will need. In our case, this worked out well as we only need a database for each of our dev, stage, and production environments/projects.
No support for Native Geo Queries
Most databases, including no-sql database, have native support for GEO-Queries. A GEO-Query is a query that looks something like “Give me all airports within 20 miles of my current location”. CloudFirebase is supposedly working on this capability, but there is now support for it as of the time of this article.
Workaround — The good news is that there is a pretty effective 3rd party library called GEOFirestore that will bridge the gap until the native features become available.
More hackable than your typical database
In a traditional database deployment model you have a firewall between the database admin interface and the public network. Access is typically granted via a REST API which limits access further. Cloud Firestore, in contrast, is accessed directly by a client over the network. As a result, there is great opportunity for data hacking or compromising your data. Further creating an issue is the fact that it is common to leave the database wide-open during development.
Workaround — Get very comfortable with the security rules features on the system. Make sure only the right operations are accessible from the outside and also incorporate the Firebase Authentication services to further lockdown access.
No run local option for developers
The last aspect that caused us issues is the fact that there is no way to run a local version of the database for unit testing. Any access requires a Firebase project. While this is fine for established environments like “test”, “stage” or “production”; it is less helpful to the individual developer.
Workaround — Give every developer access to their own Firebase Project. There is a free tier available and has all the capabilities required for basic integration testing during development. Just make sure to externalize the project settings so that these aren’t included in the source code and can be configured by the CI/CD system.
