2
votes

I am trying to understand the cost of using Firestore realtime listeners. In my case it is for an editor (realtime collaborating).

Words in an editor may correspond to documents in Firestore. And a document in an editor may be a collection in Firestore.

There may be thousands of words in a document in the editor.

Each time a user opens a document in the edtor a snapshot for the corresponding collection must be set up, something like this (https://firebase.google.com/docs/firestore/query-data/listen#web_3):

db.collection("cities").where("state", "==", "CA")
    .onSnapshot(function(querySnapshot) {
        var cities = [];
        querySnapshot.forEach(function(doc) {
            cities.push(doc.data().name);
        });
        console.log("Current cities in CA: ", cities.join(", "));
    });

I am a bit worried about the cost for this call. And I can see no way to charge users for this. (I think I read some years ago that the cost for this call was very low, but if I remember correctly now it has changed.)

Can someone clarify this for me, please?


EDIT: Trying to make my question more clear.

  1. Let us say that there a 5000 words in a document in the editor.
  2. This will be 5000 Firestore documents.
  3. Opening the document in the editor will call the Firestore to get a snapshot and setup a listener (see code example above).
  4. As I understand it this will now be charged as reading 5000 Firestore documents.

My question is about point 4 above. Do I understand that correctly?

And what happens when the users reopens this editor document? Will there be a charge for 5000 Firestore documents each time?

(I am expecting the users to open each documents many times due to the nature of the app I am writing.)


EDIT 2: Since I believe it is now clear that the code above actually will be charged for 5000 reads (see point 4 above) I think I now can ask the real question without raising too much confusion:

How is this handled when firebase.firestore().enablePersistence() has been done?

Is there any point where this can be alleviated? It looks to me like Firestore collection might be such a point. (Last change time could be stored for a collection, perhaps. I am not sure. But I think this must be done on the Firestore side, not in my code, or?) Is something like this implemented in Firestore?

2
It's not entirely clear what sort of answer you're expecting here, or where you are stuck computing the cost of your query. You also seem to have a second question here related to accounting and user billing. I suggest narrowing this question down to a single, discrete question with clear data to work with.Doug Stevenson
The documentation is pretty clear see Pricing which states Document reads: $0.06 per 100,000 documents. So reading 100,000 documents is $0.06. Then add in the stored data pricing shown at that same link. Is there something more?Jay
I'm still confused. I'm not sure what you mean by the "firestore editor". Is your question about how the Firestore web console works when you use it, or how the code you provided works? It should just be about one or the other. They don't work the same.Doug Stevenson
What is the "editor" you refer to? That's entirely unclear to me. I don't understand what is involved in each step.Doug Stevenson
The point of persistence is to allow a user to continue to interact with your app in situations where the internet connection is interrupted - like when a user is going through a tunnel. If they write a bunch of data during that time, when the connection re-establishes, it writes that data to firebase and you are charged for it. Read's behave similarly. You should not rely on persistence to alleviate any billing and fully count on every 100,000 reads to cost .06.Jay

2 Answers

2
votes

I'm not too clear on what your confusion is. But the simple fact of the matter is this:

If you make query that fetches 5000 documents from Firestore, you will be charged 5000 document reads.

There's nothing you're showing here that indicates that anything else would happen. Every time your code executes that query, you will be charged.

1
votes

According to firestore docs,

When you listen to the results of a query, you are charged for a read each time a document in the result set is added or updated. You are also charged for a read when a document is removed from the result set because the document has changed. (In contrast, when a document is deleted, you are not charged for a read.)

So that means, the firestore cost for this is quite lower than performing repetitive fetches on intervals, and it hasn't changed anytime recent.

Regarding how to charge users for this, the handler to onSnapshot is called with a docSnapshot object that contains reference to which documents were added, modified or deleted, so should be easy to infer billing from that