3 ms·

I can't say enough good things about Firebase and GCP in general, but I'm always cautious when using Firestore in particular. I usually avoid unbounded queries

I can't say enough good things about Firebase and GCP in general, but I'm always cautious when using Firestore in particular. I usually avoid unbounded queries altogether, and treat it primarily as a key/value store to get by id. When I do use queries, it's always in places where the results have a well-defined limit (usually limit = 1), e.g. finding the most recent X or the highest X. With the above two, you get all the greatness of Firestore, but with a well-defined (low) cost that you can calculate ahead of time.

itcmcgrath 8y ago
We've also been rolling out updates to rules to enable you to enforce these types of things. There is performance implications to limit queries for the real-time update system at scale, but for most use cases this shouldn't be a problem. Definitely more we can improve here for control, and we're open to feedback.
- fefb 8y ago
  Hey, thanks for listening. I believe in short time would be nice to have a way to use for the query the create, update and write time of a document. Now, I am doing the creat time manage inside of my document with Date.now(), but when I was running a bunch of promises to create the documents, the createTime between the documents that I was manipulating was in same case the same, so my pagination failed. Another things, like compound queries inside of subcollections should be nice. A way to export all the database for backup. A flag to alert the Firestore to return the document when I do an update in this document in the same response (one round trip (dynamoDb has it). I know I can reach this goal witht transaction, but I believe it is simpler than a transaction. A way to update a array without transaction. Thanks
- degenerate 8y ago
  My open feedback is to get these rules in place as soon as possible. This story/blog makes me realize that GCP/Firebase does not currently play nice to dumb mistakes and 24h away from the dashboard can be disastrous. Multiple rules/filters need to exist to trigger SMS/Email alerts, or a pre-defined action, upon certain conditions.

itcmcgrath 8y ago

We've also been rolling out updates to rules to enable you to enforce these types of things. There is performance implications to limit queries for the real-time update system at scale, but for most use cases this shouldn't be a problem. Definitely more we can improve here for control, and we're open to feedback.

fefb 8y ago
Hey, thanks for listening. I believe in short time would be nice to have a way to use for the query the create, update and write time of a document. Now, I am doing the creat time manage inside of my document with Date.now(), but when I was running a bunch of promises to create the documents, the createTime between the documents that I was manipulating was in same case the same, so my pagination failed. Another things, like compound queries inside of subcollections should be nice. A way to export all the database for backup. A flag to alert the Firestore to return the document when I do an update in this document in the same response (one round trip (dynamoDb has it). I know I can reach this goal witht transaction, but I believe it is simpler than a transaction. A way to update a array without transaction. Thanks
degenerate 8y ago
My open feedback is to get these rules in place as soon as possible. This story/blog makes me realize that GCP/Firebase does not currently play nice to dumb mistakes and 24h away from the dashboard can be disastrous. Multiple rules/filters need to exist to trigger SMS/Email alerts, or a pre-defined action, upon certain conditions.