Create a Multi-Tenant Design.

[dominguez-aureax]

Once the initial database is set up through firebase, a data model needs to be created to support multi-tenancy. An example: https://blakebhowe.medium.com/multi-tenant-application-database-design-e4c2d161f3dd

[dominguez-aureax]

Firebase offers two databases: Cloud Firestore and Realtime Database.

Cloud Firestore is Firebase's newest database for mobile app development. It builds on the successes of the Realtime Database with a new, more intuitive data model. Cloud Firestore also features richer, faster queries and scales further than the Realtime Database.

Realtime Database is Firebase's original database. It's an efficient, low-latency solution for mobile apps that require synced states across clients in real time.

[jsstallings]

Still need to dig into both, but sounds like firestorm is the way to go. Either way, key is to design the aureax data model for multi-tenancy, basically org is not a table but an id across tables that support the storage of org-specific data as rows in tables, if that makes sense.

[dominguez-aureax]

I believe I understand what you're saying. I'm going to try and find an example/draw up my own today, so I get the full understanding and confirm this with you in tomorrow's meeting.

[dominguez-aureax]

Firestore multi-tenancy explanation: https://stackoverflow.com/questions/55074267/how-would-one-create-a-multitenant-datamodel-in-a-nosql-solution-like-firestore

[dominguez-aureax]

Based on the previous PR, the model will look as follows:

Firestore-root
|
--- users (collection)
|    |
|  --- userID (document)
|        |
|       company: companyID 
|       |
|      // Other fields
|
--- companies (collection)
     |
     --- companyID (document)
         |
        --- admins [ userIDs ] (array)
        |
        --- users [ userIDs ] (array)
        |
        --- name: companyName
        |
        --- colors [background, primary, accent] (array)
        |
        // Other fields

[dominguez-aureax]

I was going to proceed with having a unique companyID for the document, but assuming each company has a unique name this could be used instead.

[dominguez-aureax]

@jsstallings I added a plan proceeding from the Sign-Up in #4 if you can take a look at your earliest convenience.

[jsstallings]

Saw it, replied.

---- On Wed, 09 Jun 2021 15:26:42 -0400 dominguez-aureax @.***> wrote ----

https://github.com/jsstallings I added a plan proceeding from the Sign-Up in https://github.com/dominguez-aureax/aureax-app/issues/4 if you can take a look at your earliest convenience.

— You are receiving this because you were mentioned. Reply to this email directly, https://github.com/dominguez-aureax/aureax-app/issues/7#issuecomment-858031828, or https://github.com/notifications/unsubscribe-auth/AKGOOBKPDT5OV65JXFCXIR3TR657FANCNFSM46BEIZWQ.

[melchord]

This is the current model I am working with. Upon creating this, I saw a clear problem with logic for payment. Currently an admin creates the company and their membership would be the deciding factor for if the app is still up and running. However, this would be difficult with adding other admins/managers as they most likely won't have an active subscription and this would require parsing through multiple admins to find one currently paying. I have a couple counters:

Proposal 1: There is a higher 'owner' which can add multiple subscriptions to their account. This 'owner' still has admin privileges in the overall application through the Aureax website/application. However, to get the proper experience they would need to make a separate account associated with their unique URL/application. There can also be an option to 'transfer' their information from the Aureax account to their unique application account.

Proposal 2: The Aureax account is assumed to be the company. Similar to the owner, they have admin privileges for their unique application through Aureax website/application. They will NOT be able to have multiple subscriptions, only 1 active subscription as they are assumed to be marketing themselves/the company. This is a good option for companies that have primary company emails/accounts/etc that are easily transferable through employee/management changes.

I will upload a view of these proposals shortly.

[dominguez-aureax]

[dominguez-aureax]

[dominguez-aureax]

Some more detail was added along the way, but the references are the important note.

[dominguez-aureax]

Something to consider: I do not know how unique authentication between different applications would work as firebase authentication is based on the application id. A different authentication method may be chosen for the unique applications as this may be a hill not worth climbing.