You're nesting multi data types under a single root, which is something most Firebase Realtime Database developers recommend against. Some of the most important reasons for this are:
- Firebase will always read entire nodes, so you cannot read a user's properties without also reading all their conversations. There are many scenarios where this is wasteful, such as when you only want to show a list of user names.
- Once you grant a user read access to a node, they have access to all data under that node. You cannot take this permission away at a lower level. This means in your case that anyone who can read a user's profile information, can also read all their conversations. This may not be what you want.
- You may try to work around this last concern by giving the user read permission to the specific property of the users, so
/Users/$uid/name
, etc. that way they can read the names, but not the conversations. On a individual user node this will indeed work. But with this structure you cannot get a list of user profiles anymore, since you don't have read permission on /Users
.
The common way to model what you shared is to split the conversations and the user profiles into separate top-level nodes, each keyed on the user's UID:
Users
$uid
name: "Matias Celiz"
gender: "..."
Conversations
$uid
...
If you want separate public profile information and private profile information, add another top-level node to split the two:
Users
$uid
name: "Matias Celiz"
gender: "..."
Profiles
$uid
name: "Matias Celiz"
Conversations
$uid
...