4

I have a Firestore collection called users that stores all my user info. When registering a new user, I first register them with Firebase Auth, then create the record in the users collection. Right now I'm storing the UID as a field, which means when I want to query a user's info, I need to do a query with a WHERE clause. However, one alternative to faster querying would be to store the UID as the document ID for the collection. That would make it so that I could query the collection with a specific ID, which intuitively seems faster.

Using the UID as the doc ID makes me worried about some stuff:

  1. I'm not sure if I can assume that uniqueness for the UID in Firebase Auth implies uniqueness when using it as the doc ID in a Firestore collection.
  2. I watched a tutorial video by Todd that said that querying is faster if you use the auto-generated document ID that Firestore provides. Given this, I wouldn't want to take a risk using something else when the provided doc ID is known to be faster for querying.

What would be the better approach to make querying as efficient as possible, assuming you are querying only based on UID? Or is the difference so negligible that this is a moot point?

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
whatwhatwhat
  • 1,991
  • 4
  • 31
  • 50
  • Using Firebase Auth's UID is convenient as you fetch a single document by ID using instead of querying using 'where' as well as in security rules. Also which video are you referring to? – Dharmaraj Oct 24 '22 at 04:59

3 Answers3

4

yes, that is the most recommended approach because firebase auth ensures that your users have a unique id so no need to worry about duplicates. Another thing is storing separate id other than the uid is redundant because what you'll need most of the time in your app is the user uid to make sure that the auth user and the stored user are one and only the same person.

john
  • 1,438
  • 8
  • 18
1

I'm not sure if I can assume that uniqueness for the UID in Firebase Auth implies uniqueness when using it as the doc ID in a Firestore collection.

The document IDs that are generated by Firestore are completely random. So there is nothing to worry about.

I watched a tutorial video by Todd that said that querying is faster if you use the auto-generated document ID that Firestore provides. Given this, I wouldn't want to take a risk using something else when the provided doc ID is known to be faster for querying.

When you only need to read a single document, for instance, the user document, it's always recommended to create a document reference that points to that document rather than performing a query. A query basically means that it needs to evaluate all records in order to provide a result.

And using the UID as a document ID is a quite common practice.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
0

If the uid in Firebase Auth is unique, and you're building the users collection based on the uid from Firebase Auth, then it follows that the uids which will populate the users collection will also be unique.

The only way this wouldn't be the case is if you're going to be mixing manually generated entries into the users collection with your own uids that aren't following Firebase Auth's generation procedures.

I did a mini project like this earlier this year that pretty much did exactly this (users sign-in with google, uid gets added to the users collection, and then their data gets stored under their uid in the collection). It wasn't a commercial product and my userbase was fairly small, but I didn't observe any reason for concern at the time.

Re: speed, I'm not sure what the impact is, but I would expect it to be negligible enough to call it moot. Querying a collection is basically just searching a list/array for a value, and most backends tend to handle a basic operation like that pretty efficiently.

A. Trevelyan
  • 136
  • 5