3

I want to have the users in the database structured in a way that makes it easier for a human to read and manage. Using the users email address as the property name instead of the User ID:

Users:

  "Users" : {
    "emailaddress@domain.com":{
      "id": "DK66qu2dfUHt4ASfy36sdfYHS9fh",
      "name": "A Display Name",
      "groups": {
        "moderators": true,
        "users": true
      }
    },
    {...}
  }

So that if I have a list of users in a group, they can be read as a list of emails and not a list of user IDs.

Groups Such as:

  "Groups": {
    "moderators":{
      "name": "moderator",
      "members": {
        "emailaddress@domain.com": true,
        "emailaddress2@domain.com": true
      }
    }
  }

Groups Instead of:

  "Groups": {
    "moderators":{
      "name": "moderator",
      "members": {
        "DK66qu2dfUHt4ASfy36sdfYHS9fh": true,
        "K2fkHYQDFOge3Hw7SjRaGP3N2sdo": true
      }
    }
  }

However, using rules to verify a property of the user (such as their group), would require me to maintain two list of users, one like the list above, and another essentially a table of key-value pairs of ID's and email addresses so I can get the users email address from their uid.

Pseudo-code rule: Users[UsersKeyVal[auth.uid]].groups.moderator == true

With firebase, what would be considered the most acceptable practice? What are the pros and cons of both?

Douglas Gaskell
  • 9,017
  • 9
  • 71
  • 128
  • Is the plan to have a user log into Firebase directly and read and mange the data manually through the Firebase Dashboard? – Jay Jun 06 '16 at 18:23
  • @Jay Sadly it's needed if I want another user to create new Email/Password users, since the default behavior of such actions is to automatically log you in as the newly created user, I or the other admin would need to log back out, then back into our own accounts to then setup the user in the database. It's just easier, and less awkward to add the new user via the firebase console. Which why I was considering making it human-readable until such time as it can be handled programaticly. However, after reading your answer, I may not. – Douglas Gaskell Jun 06 '16 at 18:27

2 Answers2

2

In my opinion there is no problem with your data structure.

According to the Doc

This is a necessary redundancy for two-way relationships. It allows you to quickly and efficiently fetch your members memberships

Also using the generated UId from firebase or your custom Id (here your e-mail) doesn't change the way firebase works. You just have to make sure your e-mail are unique.

0xCrema.eth
  • 887
  • 1
  • 9
  • 22
  • Thanks Crema. However, after thinking about it for a bit, my concern is with maintaining another chunk of data that is just key-value pairs of email addresses and user ID's. Which is only necessary because I am using email addresses as ID's of sorts, and Firebase auth only contains the `uid` of the authe'd user. It would not be necessary if I went with using the User IDs instead of emails. In this case, I'll have some redundant data 3x over. – Douglas Gaskell Jun 06 '16 at 08:03
  • Oh I see. I forgot this part since I'm using a custom Auth system where I can directly use my members emails for my verification rules. – 0xCrema.eth Jun 06 '16 at 08:07
  • Oh, do you have a reference I could read up on for this? Is the user info storage/security such as passwords still handled by firebase? – Douglas Gaskell Jun 06 '16 at 08:10
  • Sure : https://www.firebase.com/docs/web/guide/login/custom.html the old doc I used (I can't find this in the new one). But this require you to have a server (or a proxy and here is mine : https://github.com/CremAlex/proxy-whiteboard) – 0xCrema.eth Jun 06 '16 at 08:18
  • Oh I see, thanks for the info. After some deliberation, I've come to the conclusion that the thrice redundant data is necessary if I want the database to be human readable at all. Which it definitely needs to be as long as email+password users cannot be created programmaticly. Thanks! – Douglas Gaskell Jun 06 '16 at 08:21
2

Please do not store user data under their email address! This will be BIG TROUBLE later.

Your users node should follow the 'standard' Firebase design pattern

users
  uid_0
   name:
   gender:
   etc
  uid_1
   name:
   gender:
   etc

The bottom line is that in general, it's best to disassociate the dynamic data stored in the node from the key of the node.

Why?

Suppose you build a complex structure with all kinds of links and references to frank@mycoolcompany.com and then @mycoolcompany.com gets acquired by @mynotsocoolcompany.com. Well, you will then have to go in and rebuild every reference to franks's email in the entire database. ugh.

Then what if there are 100 or 1000 users @mycoolcompany.com! Ouch.

If you disassociate the data, like my per above suggested structure, you just change the email address within the node and everything else... just works!

PLEASE, read this answer on stack overflow - written by a Firebaser and addresses your question

Firebase data structure and url

Community
  • 1
  • 1
Jay
  • 34,438
  • 18
  • 52
  • 81
  • Jay, thank you for your reply. This makes sense and is the exact type of insight that I'm looking for. Thank you for linking that answer, that is very enlightening. The ONLY reason I am considering doing it the way in the OP, is because I have to manually set up users data in the database and auth since there is no way to programmatically create email/password users. So myself, and anyone else that needs to be able to add new users, has to access the firebase dashboard directly, instead of just making an admin panel on the site. – Douglas Gaskell Jun 06 '16 at 18:23
  • Firebase can easily create users in code. We do it all the time. It would probably be much easier to give your 'admin' users a front end UI that would allow them to add or change users as needed. – Jay Jun 06 '16 at 18:37
  • This is unrelated to my question in the OP, but how? The only way that I know to create a new user is via `createUserWithEmailAndPassword` API method [here](https://firebase.google.com/docs/reference/js/firebase.auth.Auth#createUserWithEmailAndPassword) which also logs you in as the newly created user automaticly. Adding the database information can be done programmatically, but actually creating the user's auth can't afaik. – Douglas Gaskell Jun 06 '16 at 18:43
  • @DouglasGaskell That's a great follow up comment. With 2.x, the developer could create users via code without logging them in. It was a very powerful way for an application that had a Manager or Admin user structure to create additional users for the account or app. That capability has been removed in 3.x, so your options for adding users are limited at this point. I have been told the Firebase team may be investigating other options, but for the time being, manually creating them is the only option. – Jay Jun 07 '16 at 17:21