How to structure Firestore Security Rules & Data Structure for granular access

Question

I am building a community-type app based on Firestore where users should have granual control over what kind of information they share with whom.

Users can have properties such as name, birthdate, etc. and for each of them they can decide to share it with the one of the following groups/roles:

• Private
• Contacts
• Admin (Admins of organizations that user is a member of)
• Organization (Members of organizations that a users is a member of)
• Public (All users of the app)

As documents in Firestore will always be retrieved as a whole, I already know that I somehow will have to segregate my user properties by access level.

I've got two approaches so far:

Approach 1

• Store each user property in a separate document that contains a field access level
• Store some metadata in, for example /user/12345/meta/roles, so that I can point the security rules to those documents to validate access

Benefits:

• Easy structure
• Flexibly
• (Almost) no data duplication

Drawbacks:

• Lots of document reads for getting a user's profile

Approach 2

• Store user profile in, for example /user/12345/profile/private and duplicate the public information into /user/12345/profile/public, and do the same for each access level

Benefits:

• Reduced document reads

Drawbacks:

• Complexity
• It feels wrong to duplicate that much data

Does anyone have any experience with this and any suggestions or alternative approaches they can share?

Follow-up question:

Let’s say I store the list of members of an organization in a subcollection, that is only accessible for members of the organization (for privacy reasons). Doesn’t that mean that when querying that list of members from client side, I have to do it „blindly“, meaning I can’t know if the user can access that document until I actually try? The fact that the query might fail would tell me that the user is not actually a member of that organization.

Would you consider this kind of query that is set up for failure bad practice? Are there any alternatives that still allow to keep the memberlist private?

Answer 1

I think you are moving from a SQL environment to NoSql now which is why you are finding the Approach 2 as not the right way to proceed.

Actually approach 2 is the right way to proceed there are couple of advantages

1.) Reduced Document Reads - More cost savings. Firestore charges by number of reads and writes if you are reducing no of reads and writes optimally its always the way to go for. Also the cost of storage due is increased reads will always be less than the actual cost of reads if you are scaling up your application.

2.) In NoSql database your are allowed to duplicate data provided it is going to increase the read / search speed from the database.

I am not seeing the second approach as complex because that's the tradeoff you are making when Choosing a NoSql over Sql