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?
3 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.
4 Likes
Hello,
I want to implement multi-tenancy in Moqui. My approach is having one database per tenant but common code base and segregation based on tenant Id. I am looking forward to applying changes from moqui-framework 1.6.2, a commit before multi-tenancy was removed.
I am trying to find out why it was removed (apart from maintenance overhead) and what factors should I consider when implementing it ? Are there any major concerns ?
I have gone through this thread as well as the issue on Github (How to cluster deploy with multi-tenant? · Issue #245 · moqui/moqui-framework · GitHub), also joined the Moqui Ecosystem LinkedIn Forum but couldn’t find anything on the forum.
1 Like
I’m not sure why the multi-tenant code was removed, but what I’m planning on doing with my SaaS product is to use active organization stuff here:
There’s a pretty good example of this here, but searching filterOrgIds in the codebase will give you more examples.
The idea, to my understanding, is that with lots of users each user can have organization (a different modality could be chosen, but that’s what’s already built) that they have selected. Then for a query, filter by the organization that is active. This gives a semblance of using different databases, but they aren’t actually. I’m not sure what is standard procedure for seperating user data in a SaaS setting, but this is what, when I was talking with @jonesde , he recommended (although feel free to correct me).
2 Likes
(This comes from my conversation with David)
The previous comment assumes you are developing an application on top of Moqui that doesn’t use most of the system and tools apps at all and not much use for Marble / HiveMind.
If you plan to take the whole of Moqui and make it multi-tenant with admin access for multiple different people who should never have access for you, unless you have a large team of developers and lots of resources to figure out security concerns, this is a bad idea. The internal security model, shared data, code execution, file editing, etc. of Moqui just doesn’t work under those circumstances.
If you must sell all of Moqui’s features (specifically tools and system apps) to multiple different people, just use different databases and application instances and pay the higher cost for it as it will be cheaper than having multi-tenant Moqui.
1 Like