Support for the Multitenancy

[VardhanGo]

Overview of the feature request

As a Platform developer it would be helpful to have multitenancy support in the JHipster generator.

Multitenancy is a crucial feature for many applications where multiple tenants (organizations, clients, etc.) share the same application instance but have their own isolated data and configurations.

Motivation for or Use Case

The primary motivation behind this feature request is to simplify the implementation of multitenancy in applications. Currently, developing multitenant systems using jhipster requires significant manual code changes and configuration modifications. By incorporating multitenancy support into the JHipster generator, developers can benefit from a pre-configured and streamlined approach, saving time and effort. In the platform that I am currently developing (created using jhipster), I have implemented schema-per-tenant model and also added corresponding changes to the liquibase configurations. But I had to repeat this in all micro-services that we use which seemed repetitive.

Related issues or PR

https://github.com/jhipster/generator-jhipster/issues/12013 There's a related feature request for multitenancy support. However, that request was closed in favor of an existing blueprint that focuses on one multitenancy pattern. This blueprint is no longer maintained.

Given the importance of multitenancy in SaaS applications, I propose revisiting the feature request and expanding the capabilities beyond a single pattern. This enhancement would address the needs of developers who require flexibility in choosing between separate database, shared database, or hybrid database multitenancy patterns.

• [x] Checking this box is mandatory (this is just to show you read everything)

[MarkusBernhardt]

+1 by me. This feature is very much needed by us.

[mraible]

There is a multitenancy blueprint:

https://github.com/sonalake/generator-jhipster-multitenancy

It looks like it was last updated for JHipster 6. Maybe it can be updated or used as inspiration for a new one?

[wenbin9]

+1 by me. This feature is very much needed and very important for us! Can you help with it?

[VardhanGo]

@mraible ,

We use schema per tenant model in our applications and modified the core jhipster generator to support the same.

we have tested for non reactive application using sql database.

workflow for jhipster application generation

workflow for entity generation

We are open to contribute and happy to get feedback for the same.

[hide212131]

I have been following this topic with some interest. For the approach, I suggest creating a project using a familiar JDL, such as https://github.com/jhipster/jdl-samples/blob/v8/blog-oauth2.jdl, and then adapting it for multitenancy. We could then examine the code and its differences, discussing it together. If it turns out to be too complex, we might consider implementing it as a Blueprint (if our approach aligns closely with https://github.com/sonalake/generator-jhipster-multitenancy, we could modify it ) , but either way, it seems like a good direction to proceed.

[mshima]

The multitenancy blueprint https://github.com/sonalake/generator-jhipster-multitenancy implementation was based on custom services/repository. I've implemented a multi-tenancy blueprint based on aop filters to filter entities for jhipster v6 https://github.com/mshima/generator-jhipster-tenantview patching the generated code but haven't touched since it. I've been thinking in updating it for some time. A admin entity like the authority management merged a couple of weeks ago makes the blueprint much easier to maintain. So it will be based on the next release. Adding multi-tenancy to generator-jhipster is too complex to maintain, it should a blueprint.

Would be nice a schema based approach. @VardhanGo if you could share a diff, I could convert to a blueprint.

[MarkusBernhardt]

Having a full multi tenancy solution would be really great. As the different setups have different pros and cons I would love a solution that supports configurable a table, schema and database based multi tenancy setup. Additionally some hybrid modes would be very handy. Have most small tenants in a single database, but your big ones in separate databases.

I would love to help building that blueprint, but am currently fighting to get my first small blueprint running. Not sure how much I could help.

[VardhanGo]

The multitenancy blueprint https://github.com/sonalake/generator-jhipster-multitenancy implementation was based on custom services/repository. I've implemented a multi-tenancy blueprint based on aop filters to filter entities for jhipster v6 https://github.com/mshima/generator-jhipster-tenantview patching the generated code but haven't touched since it. I've been thinking in updating it for some time. A admin entity like the authority management merged a couple of weeks ago makes the blueprint much easier to maintain. So it will be based on the next release. Adding multi-tenancy to generator-jhipster is too complex to maintain, it should a blueprint.

Would be nice a schema based approach. @VardhanGo if you could share a diff, I could convert to a blueprint.

Hi @mshima , I am working from my org laptop, so have to follow a set of checks before pushing to public repo. Will share the diff in a few days.

[wenbin9]

@mshima Since hibernate 6.0, hibernate provide muti-tenancy support, does that useful for jHipster build muti-tenancy feature? https://docs.jboss.org/hibernate/orm/6.4/introduction/html_single/Hibernate_Introduction.html#multitenancy

[github-actions[bot]]

This issue is stale because it has been open for too long without any activity. Due to the moving nature of jhipster generated application, bugs can become invalid. If this issue still applies please comment otherwise it will be closed in 7 days

[drumcircle]

Request to re-open.

[github-actions[bot]]

JHipster has completed the sample check .yo-rc.json: blank Entities JDL: blank Application: successfully generated Frontend check: skipped Backend check: skipped E2E check: skipped

This check uses jhipster info output from the issue description to generate the sample. Bug report that does not contain this information will be marked as invalid.