How does Moqui framework handles multitenancy? Is Moqui's approach similar to Apache OFBiz? Ofbiz provides separate database for each tenant. Moqui is a powerful framework which inherits a lot of goodies from OFBiz and has many improvements also. Are there any improvements in handling multitenancy? Is there any sample multitenant application (HiveMind or Example app)
I am evaluating a framework for a webapp which has minor database interactions (only 10 to 20 tables) which is supposed to server 100 or more customer. Having separate database for separate tenant becomes hard to justify for such a smaller application. Any recommendation to handle this with Moqui? One option is to make a field name tenant_id in every entity within this application and every database query should have a check for this field whenever database operations are performed.
Moqui has various additional features in multi-tenant functionality versus OFBiz, but yes it does use the same approach of one app server (or cluster of app servers) and one database per tenant (or more than one database per tenant if databases are split).
To really support a large number of tenants in a single database requires a LOT of tooling. You basically have to build functionality into your multi-tenant layer to not only handle the application needs, but everything else normally done directly with a database (other applications, reporting, export/migration, segregated backups when needed, etc). When scaling really big you also need to build support for sharding tenants across multiple database servers. In other words, to do properly and completely it is not a simple thing.
100 tenants is not that bad, you could do that with one database per tenant. It is best to build automation to provision the tenants, and you can do that based on the tenant provisioning services already in Moqui. You could even add logic to it to "shard" the tenants across multiple database servers if you (for example) wanted to limit each database server to 50 or 100 or whatever tenants. You could scale to thousands of tenants this way, but you'd need to handle other scaling details along with it of course.
You can certainly use the approach of adding a tenantId to each entity, or have the Entity Facade do this automatically (perhaps for all entities except the ones in the tenant common group). If you want to report across tenants, and the amount of data per tenant isn't too large, then this might be a great way to go.
You could do this for just your custom entities, but depending on desired functionality you may need to add this to Moqui entities as well. For example, if you want the users to be segregated between different tenants you'd have to add a tenantId to UserAccount and most of the other security entities (for authorization, user groups, permissions, etc). You could also just add a tenantId as a non-PK field to UserAccount (using extend-entity to avoid modifying the original entity definition), and then look up the tenant based on the user authenticated (or in a separate join table if a user may have access to more than one tenant).
The complexities and possible variations are endless... all depends on what you want to do!
The closest concept to this is an Organization Party in the Mantle data model. Various things are designed to support multiple organizations in the same system, but with no strict segregation between them. This is really for multiple departments and other smaller organizations within an umbrella organization.