Differing B2B Architecture Approaches

[Charlie Maloney]

Hi All! 

I have a question regarding the “proper” setup for a B2B application. In the firebase docs, it says to avoid using multi-tenancy. Instead, it recommends setting up a new firebase project for each major customer (https://firebase.google.com/docs/projects/learn-more#multi-tenancy). 

Yet, I see that they added support through Google Cloud IDP to enable tenancy (https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication). I have found varying opinions online (from both firebase users and the google support team) so I am wondering what the current “best practice” is. 

For context, the application I am building could have hundreds of tenants, each with their own set of users, which don’t need to share data. The prospect of setting up a new firebase project for each one (even programmatically through the REST API seems complicated to manage and like a waste of resources — a tenant could just be a set of 5 users). 

I could see in the future, for a large tenant who has specific security or data regulation needs, setting up a separate project, but initially, the leanest approach seems to utilize the tenancy support provided by IDP to create a top-level collection of tenants in firestore and have all of their data live as sub-collections underneath.

What are the community's thoughts? Thanks in advance!

[Fezzab]

Hey Charlie,

how did you go with this? I'm going down the same path and seems to be the most effective way than managing a project per tenant.

I also set Rules for each of the document in the top level collection that the access is restricted to the user's tenant. So I effectively use the tenantid as the top level document for each document and have a simple rule like this
.

    match /tenants/{tenantId}/{document=**} {
      allow read,write: if request.auth != null && (request.auth.token.firebase.tenant == tenantId);
    }