0

I'm working on a side project and want to let my users check if their friends have accounts.

Currently I've implemented it like this:

  1. Read phone contacts for emails
  2. Loop through the emails
    1. Make .get() query on the user database1 for users with that email
    2. If data comes back, the friend is on the platform and an invite button is displayed
  3. Free quota2 exceeded within an hour

The thing is that any .get is considered a read operation, even if no data comes back. Their doc.exists can only be tun after a .get so a document read is needed to check for existence.

I'm sure I'm overlooking something obvious, what I want to do is in essence to an .exist() like query that does not 'cost' a read.

1: I'm not actually storing emails in firestore but their hashes, and am querying those. Same effect, but it allows me to query a secondary user database that doesn't expose true emails and other data.

2: Not trying to be cheap per se, but if this app turns commercial this would make the billing a nightmare.

Mentor
  • 965
  • 9
  • 21

1 Answers1

1

According to your comment, you say that you keep the contacts in memory and for each contact (email address), you search in your existing Firestore database for matches.

Free quota exceeded within an hour

It means that you are searching the Firestore database for a huge number of contacts.

The thing is that any .get is considered a read operation, even if no data comes back.

That's correct. According to the official documentation regarding Firestore pricing, it clearly states that:

Minimum charge for queries

There is a minimum charge of one document read for each query that you perform, even if the query returns no results.

So if you have for example 1000 contacts and you query the database for each one of them, even if your queries return no results, you're still charged with 1000 read operations.

I'm sure I'm overlooking something obvious, what I want to do is in essence to an .exist() like query that does not 'cost' a read.

That's not how Firestore works. This means that every query incurs a cost of at least one document read, no matter the results.

1: I'm not actually storing emails in firestore but their hashes, and am querying those. Same effect, but it allows me to query a secondary user database that doesn't expose true emails and other data.

As you already noticed, doesn't matter if you store the actual email address or the corresponding hash, the result is the same.

2: Not trying to be cheap per se, but if this app turns commercial this would make the billing a nightmare.

Try for this feature, Firebase realtime database and believe me, both work very well together in the same project.

Community
  • 1
  • 1
Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • Would a RTDB read of an entire tree (e.g. users) count as one read then? I'm a bit fuzzy as to why the RTDB would solve the issue. – Mentor Jul 23 '19 at 13:16
  • 1
    Only in Firestore the pricing model is about the number of reads and writes. In RTDB is about the amount of data you get, which in my opinion for this use-case is significantly cheaper than the cost of 1000 read operations. Check [this](https://firebase.google.com/docs/database/rtdb-vs-firestore) and [this](https://firebase.googleblog.com/2017/10/cloud-firestore-for-rtdb-developers.html) out. Will help you decide how to use them. – Alex Mamo Jul 23 '19 at 13:24
  • Wow I didn't realise that, thank you for clarifying that! – Mentor Jul 23 '19 at 13:29