Granted not all of them are due to this philosophy and some are just hard problems due to other constraints like the security rules verification system.
RE projections: this is actually due to some limitations in processing security rules and not a limitation in the query matching.
Edit: RE matching on missing attributes. This is due to Firestore having sparse indexes and being schemaless, if you write explicit null values you can query for those fields being null.
If your building a reactive website then firestore is actually great.
Edit: but yes IMNSHO, there are also some design mistakes (schemaless, silly limitations on keys, ...) both in the service and the client libs. I only used the python and js clients though. I might be biased
Yupp, certainly don't disagree. It's not a perfect system - to comment on those two issues: there were some pipe dreams when I was there to support schemas, including partial schemas, but we needed a better migration story (and someone to convince the powers that be it was the right thing to work on). The limitations on keys are mostly due to the system being compatible with Cloud Datastore.
Here is a post from a while back where I explained some of the reason for some of these limitations; https://groups.google.com/g/google-cloud-firestore-discuss/c...
Granted not all of them are due to this philosophy and some are just hard problems due to other constraints like the security rules verification system.
RE projections: this is actually due to some limitations in processing security rules and not a limitation in the query matching.
Edit: RE matching on missing attributes. This is due to Firestore having sparse indexes and being schemaless, if you write explicit null values you can query for those fields being null.