Generator-jhipster: Modules - Microservice with frontend

Created on 30 May 2016  Â·  6Comments  Â·  Source: jhipster/generator-jhipster

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.

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:

  • We can't do everything at once, and for the next few weeks/months we should focus on AngularJS2
  • This should be coded directly for AngularJS 2 anyway

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.

All 6 comments

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.

  1. First utilization of angular modules can be implemented. User management logic and other domain objects logic (frontend) can be split into separate modules and imported into main app this can be default behaviour for monolithic and gateway application.
  2. jspm can be used to load js modules on the fly.


    Wouldn't it be nice if there is gateway application that works in production permanently and changes its menus based on microservices that are registered in netflix registry.
  3. Make it possible to run yo jhipster:client --with-entities --skip-user-management to generate client code on existing microservice application.
  4. Add metadata end point. This is simple but powerful step. it can just collect some informations during application creation and then provide it as json endpoint.
    Information like Module Name, Purpose, domain objects structure in jdl format. It can be just separeate controller installed by Jhipster Module

    It will be possible to created module with peace of user interface that provides some api for the whole application. First use case would be for example email service that have some peace of user interface to create email templates and provides api to parametrize and send this templates.
    It then can be deployed as docker container and added to jhipster gateway application when needed.
  5. Push user management logic into separate Module microservice.

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:

  • We can't do everything at once, and for the next few weeks/months we should focus on AngularJS2
  • This should be coded directly for AngularJS 2 anyway

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...

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sdoxsee picture sdoxsee  Â·  4Comments

trajakovic picture trajakovic  Â·  4Comments

lsadehaan picture lsadehaan  Â·  3Comments

dronavallisaikrishna picture dronavallisaikrishna  Â·  3Comments

DanielFran picture DanielFran  Â·  3Comments