Architecture Microservices Jhipster

Architecture Microservices Jhipster

I want to start an architecture with microservices of Jhipster but I have doubts.
I have 4 pieces.

“HR” <- front and backend application "SELECTION" <- front and backend application Validation <- Only one database for all front Customers <- is shared between "HR" and "SELECT" back in front in microservice and "HR" and "SELECT". Both applications must be validated against the same database (JWT). Both applications must share a microservicio "CUSTOMER" which will have the backend, but the front will be in each of the two applications. 1 - "HR" It would be a gateway? 2 - "SELECTION" It would be a gateway? 3 - How to implement security that is both against the same database (JWT) validated 4 - "CUSTOMER" It would be a microservicio? Sorry for my English.

Solutions/Answers:

Solution 1:

Your needs are fit good by using JHipster in conjunction with a JHipster UAA.

general design

Your first part is to model your bounded contextes, such as “HR”, “SELECTION” or “CUSTOMER”. But as microservice backend. Every single item in your model, as a “customer”, or a customers “address”, or a “HR” entity, are called resources. These resources have to be divided wise across your services.

using the gateway

The JHipster gateway does 2 things for you. As first, it takes ALL of your microservices and expose them via a single API gateway. As a secondary feature it also offers you a user interface (here: in bootstrap + Angular).
This does not force you to use this interface. You can use “jhipster:client” generator, to generate the 2 clients for “HR” and “SELECTION” with JS+HTML only, and serve them using plaig old nginx, and refer to your one JHipster Gateway.

Related:  Zuul Deployment in Kubernetes

security

this is where the UAA option comes into play. Using the default JWT implementation will force you to login as an user (which is stored in the gateway), even if your “CUSTOMER” microservice is calling “HR” microservice.

The UAA offers the option of using OAuth2 to enable all kinds of secure communication. So in this case you can make your “CUSTOMER” service ask “HR” more privileged data, then a user would be allowed to see, using FeignClients or general “client credentials grant”.

If your users are the “CUSTOMERS”, so your JHipster UAA becomes your “CUSTOMER” microservice.

if you have some time to wait this feature is beeing merged, implementing all this will become as easy as declare communication interfaces similar to jpa repositories, which handle all the securing for you.

wrap up

look how you design your architecture. Use one gateway for all services (maybe without the ui), generate your UI later with jhipster:client and serve them on nginx, and all other things of your logic have to be realized as REST APIs inside small microservices, and take a look of how to use UAA.

To learn how to use UAA the right way, I suggest take a look on my spring security article and my example application, which is already using the currently unmerged PR mentioned above. I had no time to write the official docs for this, yet. I also wrote a general article, how to use JHipster microservices, which you can read addtionally to the official documentation.

Beyond this, you are free to ask me for further information!

Related:  User docker-compose to pull images from private repository

good luck

References