I have a single-page application running in the browser, served locally by Firebase Emulators. It fetches documents from Firestore.
Is there a way to see/count how many documents and/or collections were requested when I open the page?
I would like to know how much opening this page will cost me.
I can not add counters to my code, because this would require deep knowledge of how the Firestore client library works.
Example 1: When my App has two components on a page. And both components subscribe to the same document. Do I have to count 2 loaded documents (because I requested the document twice)? Or do I have to count only 1 (because the Firestore library reuses the subscription from the first component)?
Example 2: When I have a subscription to a query that loads 10 documents. And another subscription to another query that loads 10 documents. But there is an overlap of 5 documents that are returned in both subscriptions. Do I have to pay for 20 documents or just for 15?
Could I perhaps somehow interpret the network traffic in Chrome Developer Tools?
2
Answers
You could add something like
This returned
Number of queries: 17
for me tested in a firebase/firestore app I have running.EDIT: I saw your comment, and I think I see what you mean. What I do is make sure that I query my database once (much like above), and then essentially cache it in some state variables of type interface[]. Then all my other functions/componenets that "query" for some info, are really just looking through the cached data, until there is some addition/edit to the database, in which case I call the function that re-fetches the data and updates the cache. I hope this helps, but I don’t understand really what you mean by you cannot edit your firebase code.
The most important thing when it comes to Firestore is that you’re always charged for reads that happen on the server. That’s it.
If you’re attaching two real-time listeners, on the exact same document, one of the listeners will read the data from the server, while the second one will be able to read the data from the cache.
On the other hand, if you’re using get() instead of using listeners, the result is totally different. This means that you’ll have to pay for two document reads. Why is this happening? It’s because when there are no active listeners, the client SDK doesn’t know if the document is changed or not between the two calls. This also means that it will have to check with the server whether there are updates or not. So these operations result in charged reads.
The above explanation is available in the case of queries too. If you’re using real-time listeners, you’ll have to pay 10 reads for the first query, and only 5 more reads for the second one. Why? Because the other 5 documents can be read from the cache. Cache reads have no costs.
Besides that, I think that the following resource will also help: