I am using Jhipster and really like it.
Instead of generating my microservice frontend integrated inside the gateway, I would like to generate a separate frontend microservice.
Instead of having gateway -> µservice-backend
, I would have gateway -> µservice-frontend -> µservice-backend
My use case :
- userA has a physical device devicev1. userA logs in on the gateway. He can see the application for the devicev1.
- userB has a physical device devicev2 (different features than v1). userB logs in on the gateway. He can see the application for the devicev2. (the backend is a different µservice for v1 and v2)
- userC is using a virtual device. He will see and use again another frontend + backend
Some researches :
I understand this is a hard to maintain feature because we would have to inject the "µservice-frontend" module inside the gateway. (And now there is Angular + React).
The question was asked in 2016 :
- https://groups.google.com/forum/#!msg/jhipster-dev/8VfS2ma_lX0/NySAdWJhEgAJ
- https://github.com/jhipster/generator-jhipster/issues/3667
I suppose I can still do it by generating a "client only" application and link it separately (rewrite the url), but I loose all the monitoring/registry/security jhipster stack. Sooo, I won't do it and keep everything in my gateway.
I could also have multiple gateways, but I was more willing to have load-on-demand modules, in the same application.
To keep it clean, I can create different angular modules for my load-on-demand part. I can use git mono-repo to separate each version in separated repository and compose before compiling. They are a lot of solutions, but I would like to use a more µservice way.
Any solution or architectural good practice?
Thank you