Using custom Firebase UIDs for keys of related database records is good or bad practice?

Question

Are there any problems using the user UID (which is generated by Firebase when creating the user through Firebase Auth) as a key for related database records?

For example, here:

/config/user.uid/configObject

... each user has one configuration entry. Because of the Firebase database rules (where the parameters for the parent node apply to all child nodes), it is often necessary to create a separate configuration tree (according to an example where the tree /usersshould be read and write protected).

The only reason I can see that this can be bad practice is when the user UID ever changes ... Does Firebase mean this will never happen? Anything I miss?

Answer 1

The UID for a specific user will never change (although they changed the format a few months ago , the old format included a provider).

This is a good practice, necessary in many cases and perhaps recommended somewhere. You want to denormalize user information across multiple nodes for better performance and authorization, as you mentioned. It might look something like this in pseudo code / rules:

- users_private (.read: $uid == auth.uid)
  - $uid
    - email

- users_public (.read: true)
  - $uid
    - name
    - photo

- users_roles (.read: dependent on some other rules)
  - $uid
    - is_admin
    - is_editor