Multi-instance or multi-tenant in Moqui?

Hi guys,
I’m building the application for a lot of clients, so I want to apply Saas Solution to avoid performance issues. Each instance or tenant has a separate database and serve a group of clients (from 10 to 15 clients in groups), the administrator can access data on all instances/tenant, and the managers can access the data of the groups they manage (the manager can manage one or more groups). Which model (multi-instance or multi-tenant) in Moquiis is suitable to apply to my case?

2 Likes

Honestly it really depends on your business needs. Moqui should be able to handle both configurations without data leakage assuming that your application uses the Principal of least privledge although any lapses in that could be a security / privacy concern if going with mult-tenant architecture.

1 Like

When it comes to multi-tenant there are countless variations.

One approach that might be helpful is multi-instance, and here is the main doc on the multi-instance management functionality:

https://moqui.org/m/docs/framework/Multi-instance+with+Docker

Another possibly relevant approach is to use a single instance with multiple organizations using entity filters as part of your authorization configuration to handle who has access to which data (record level authorization mechanism):

https://moqui.org/m/docs/framework/Security#entity-filter-sets-and-authorization

Note that this low-level framework mechanism for record-level authorization configuration can be used for many things, but there is OOTB data in mantle-usl for the user org and active org filter sets that implement the multi-organization data segregation in Mantle and SimpleScreens:

There is a data prep side of this to create the filterOrgIds and activeOrgId variables used in these filter sets, and this is done with a service call like this in Marble ERP and other applications where these filters should be applied:

Both of these approaches have their uses, but neither are great for massively multi-tenant systems… unless it is a fairly simple application that is massively multi-tenant and the more complex bits are used internally in the operating organization and then the multi-org approach may work well.

Massively multi-tenant usually involves a tenant ID of some sort as a column on every table. This could be done in Moqui but adding a little code to the Entity Facade classes (EntityDefinition and related) to automatically add a tenantId field as a primary key field to EVERY entity for full data segregation in a single database, or potentially exclude some entities. That is the simple part of it, the more complex parts are determining which tenant should be active for record level filtering (perhaps using the same mechanism as the multi-org shown above), and also making VERY sure that users for different organizations never get code level access because then all tenant segregation is out the window… and that includes access to certain entity fields that are interpreted as Groovy expressions (these are generally internal config things, not exposed to users, only available in the Tools app, and some others like the Resource Finder in the System app).

Massively multi-tenant is possible with Moqui, IMO, but after some initial fairly easy things it could end up being a very large and expensive effort to get working well, depending on the functionality that needs to be exposed to each tenant vs those with global admin access, and who knows probably many other factors as well.

1 Like