When you visit some websites, they will show you 3 options - Normal, premium and enterprise. Features will vary based on which option you choose and what you pay.
Now is it possible to design with Cuba Multitenancy add-on? So here people signing on will be Organizations having one or multiple users. So based on which option the org selects, users see those modules. Also what will be the best practice to design modules which can be plug and play. How do we define few common modules which may be needed for all modules.
Also inside an org will the admin be able to hide a few modules from certain users?
Any other thoughts on Pros and cons of doing this.
PS: It will still be using the 7.2 framework and not Jmix. Will doing this on Jmix provide any additional benefits?
this is possible to build with CUBA, but multitenancy only plays a small part in it.
Normally what you need is some representation of Customers, Subscriptions, Plans, and Options as first-class citizens in the application. Based on that you can come up with dynamic roles to show particular parts of the application.
I did a PoC a while back where I integrated a CUBA app with Chargebee, which is a SaaS Subscription Management solution. Information about subscriptions are mirrored from Chargebee to CUBA and then persisted.
Note: it is not a fully working solution, it was just a PoC. It is not even a complete add-on that you can use as-is. But you can take a look at the sources to get an idea.
You can use it with Chargebee but it will also work standalone. Based on the Limits that you associate to product plans, the application will only allow the user to do the corresponding actions or have capability limits like max. amount of entities.
Regarding the modules:
This depends highly on how you want to deploy your application. It can either be that you deploy different applications based on the tier that you offer. In this case, regular CUBA addons would work. If you have it in one running application, then you probably need something more dynamic that is based on permissions & roles. The above example is going more in this direction.
For Jmix, Iām not aware that there are any particular benefits coming from Jmix itself. Surely there is a better ecosystem factor to it with Spring Boot. This will ease your deployment story probably. So yes, there are certain benefits, but there are also downsides when it comes to the majority of the overall ecosystem. Most likely it depends on your time-to-market, required add-ons, developer knowledge, etc. if you should use Jmix directly, or start with CUBA and migrate to Jmix at a later stage.
