Database Privacy Architecture for Advanced Usage

We’re looking into upgrading our approach to database privacy from standard role-based (e.g., user, admin) to a more robust approach where user’s access to other user’s data is limited to members of their communities.

Has anyone gone with this type of structure (where it’s tailored to each individual instead of simply a few roles)? Any insights or lessons learned? Did it change page load speeds at all?

My primary takeaway so far has been that since database privacy in Bubble doesn’t allow searches, we’d need to add fields to our users table and communities table so that each user has a list of communities that they’re a member and each community would have a list of members. So, this would duplicate some of the data in our database which we’d need to make sure stays in sync - not ideal, but workable.

Happy to share added insights as we have them. Also curious to get feedback from the community.

I’m not sure if it changed load speeds, but this is how most of my projects have been structured. There’s an org with various lists (one for each "role), then each user has a list of orgs they belong to.

I’ve also done it where there’s a connecting object, something like a Membership, that has a User, an Org, and a Role. Then, the Org has a list of Memberships, as does the User. I’m not really sure of the Bubble-benefits or tradeoffs of doing one or the other.

1 Like