These are the trade-offs Tobias is suggesting you to consider before deciding on an architecture.
We have a SaaS app, where the DB is shared across all tenants. We have added security measures on the DB server to ensure there are no data breaches, and carefully design all features and functionality to ensure no data gets shown to incorrect tenant.
We also have a white-labelled app, for which we decided to go with different app and DB server instance for each tenant as our choice of architectureā¦ knowing well that there will be challenges maintaining so many different DBs.
The concept of master and sub-apps is a Bubble thingy. I would scrap that as soon as possible from your mind to avoid confusion for you, the community and if you ever speak with programmers elsewhere.
You can more or less understand what you are trying to achieve from context but it could lead you to unexpected places if someone understands something else.
The term you are looking for, as already mentioned by others, is multi-tenancy. The master app you speak of is just the source code of the app which is shared by different tenants.
You just need to figure out what type of multi-tenancy you want to implement. In the database, at deployment level, bothā¦
I agree - however as my master app will hold the configuration settings for the other apps I refer to it as the āmaster appā. Also, all the changes I make on the āMaster Appā will then be published to the other apps with the same updates. So I guess itās just easier to refer to it as my Master App and the others as sub apps, although I know this is technically incorrect. Hope it doesnāt cause confusion for others in the community - just the way my brain operates
