Jhipster Modules.
Hello I would like to share my Idea with you. Maybe somebody will be interested in helping me with development.
Module - is a microservice with frontend logic and it can be imported by gateway application special way.
As we know angular is constructed around modules. that can be imported into one another.
If we have have frontend logic generated in microservice we can later import whole module into gateway application by referencing it in gateway module.
Like this.
angular.module('gatewayModule', [microservice1Module,microservice2Module])
What is more module can be executed as independent application but without user maintenance logic.
Features:
Hot plug. It will be possible to plug modules into running application.
Idea behind that is Module will provide generic module descriptor as json end point
It will provide information like the name of the module structure of domain classes in jdl.
description and also uri of api and provided views.
After microservice is registered by gateway application can query this endpoint and auto generate manu, routes, and even form views, detail views.
There are many benefits of this architecture.
Both backend and frontend can be maintained by the same team and this is main advantage of microservices.
Backend and frontend is packed in one app and can be tested and deployed independently.
Because module is complete it can be easily redistributed.
It will be possible to create redistributable modules. For example one can create Module that act as gallery, or email gateway and this module can be easily plugged into existing gateway aplication.
One can use views provided by microservice or just reuse services.
Because views are partials they can be easily loaded into main application.
It will be possible to add extensions to jhipster not only by generating a code but also by docker containers that can be well tested.
all
New Feature.
Microservice with frontend application logic and additional metadata endpoints in json format.
Our initial beta for microservices were like this but then we changed to
our current architecture. I agree that there would definitely be use case
and demand for this approach as well but we might not have time to maintain
both architecture. Lets see what others think.
On 31 May 2016 04:08, "Filip" [email protected] wrote:
Jhipster Modules.
Hello I would like to share my Idea with you. Maybe somebody will be
interested in helping me with development.
Module - is a microservice with frontend logic and it can be imported by
gateway application special way.
As we know angular is constructed around modules. that can be imported
into one another.
If we have have frontend logic generated in microservice we can later
import whole module into gateway application by referencing it in gateway
module.
Like this.
angular.module('gatewayModule', [microservice1Module,microservice2Module])
What is more module can be executed as independent application but without
user maintenance logic.Features:
Hot plug. It will be possible to plug modules into running application.
Idea behind that is Module will provide generic module descriptor as json
end point
It will provide information like the name of the module structure of
domain classes in jdl.
description and also uri of api and provided views.
After microservice is registered by gateway application can query this
endpoint and auto generate manu, routes, and even form views, detail views.
- _Motivation for or Use Case_
There are many benefits of this architecture.
Both backend and frontend can be maintained by the same team and this is
main advantage of microservices.
Backend and frontend is packed in one app and can be tested and deployed
independently.
Because module is complete it can be easily redistributed.
It will be possible to create redistributable modules. For example one can
create Module that act as gallery, or email gateway and this module can be
easily plugged into existing gateway aplication.
One can use views provided by microservice or just reuse services.
Because views are partials they can be easily loaded into main application.
It will be possible to add extensions to jhipster not only by generating a
code but also by docker containers that can be well tested.
- _Browsers and Operating System_
all
- _Related issues_
New Feature.
- _Suggest a Fix_
Microservice with frontend application logic and additional metadata
endpoints in json format.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/3667, or mute the
thread
https://github.com/notifications/unsubscribe/ABDlFzbkYeI1s2l4mi-62AudgHJLgsyFks5qG0OzgaJpZM4IqAo5
.
Thanks to jhipster modularization it may be possible to maintain changes in a single code base by providing conditional generation.
Implementation can be divided into smaller steps and each of this step can have business value.
Yes, that was the original idea, but in the end nobody had a use case for it, so we didn't do it.
As we are in the process of migrating to AngularJS 2, I don't think we could do this now -> we should do a code freeze on the AngularJS code
Hi @fmatuszewski,
I think I understand what you are suggesting. It goes further than just "microservices with frontend". You are proposing of define a new "module" application type that would provide a UI component that could be loaded on the fly in the gateway.
An Idea similar to this one was discussed previously on the mailing list, (email by @mraible: jhipster-dev/8VfS2ma_lX0/NySAdWJhEgAJ).
Also @gmarziou linked to this interesting implementation of the concept using Zuul: https://github.com/acesinc/convergent-ui
OK, so I think we all agree that would be a good option.
However we are currently going to start the AngularJS 2 migration:
So we just can't do this right now, it's not the right time. We should schedule this after the AngularJS 2 migration is finished and stable.
As the move to Angular 2 is prioritized over this, I'm closing this issue. Thanks @fmatuszewski for your participation. I encourage you to do a POC of your idea, using angular 2 and a Zuul gateway and come back to us if you have made progress...
Most helpful comment
OK, so I think we all agree that would be a good option.
However we are currently going to start the AngularJS 2 migration:
So we just can't do this right now, it's not the right time. We should schedule this after the AngularJS 2 migration is finished and stable.