3

I am trying to build an Enterprise System that will evolve over time with features being added as time progresses.

I am planing to go with ASP.Net Core microservices architecture with Angular for the UI. I am unable to find a sample that shows how we can introduce new modules without changing any existing angular code.

I was able to do this in the traditional winforms applications using technology like MEF and dropping the dll in to a folder that shell watches and loads.

Looks like there is no such example using the Angular framework. So I was curious if its even possible to achieve an architecture as shown below?

enter image description here

Module are the asp.net core services that serve the angular files that the shell can render and Service are the logic services that are used by the applications themselves.

I did see this post, that is close to what I want to do, but I am not sure if this is even the right solution being discussed.

Any pointers appreciated.

Kiran
  • 2,997
  • 6
  • 31
  • 62

1 Answers1

0

I tried to implement a plugin architecture making use of ABP, Angular and ASP.NET Core: https://github.com/chanjunweimy/abp_plugin_with_ui

Basically, I developed angular plugins using different angular application, then I dynamically add them together.

More Information on how I achieve it:

I have 2 angular-cli application, 1 is the main angular cli application, and another is the plugin angular cli application. The problem we are facing in Angular-cli plugin architecture approach is how we integrate them.

Right now, what I did was, I run ng-build on both of the applications, and put them into a "wwwroot" folder, which then hosted in a ASP.NET core 2.0 server.

abp_plugin_with_ui is a repository which works on developing a plugin which contains both the backend and Angular cli. For the backend, I made use of the aspnetboilerplate framework, which the frontend is developed using multiple angular-cli application.

To have the main application integrated with the plugin application, we have to run "ng-build" on both of the application (note that we have to change to href of the plugin application as well), then we move the built contents of plugin angular cli application, to the main application "wwwroot" folder. After achieving all this, we can then run "dotnet run" to serve the ASP.NET Core 2.0 Web Application to host the static files generated by "ng build". In this approach, plugin Angular UI applications are independent from the main Angular UI application: they are connected using IFrame.

Recently, I realized that we could create components on the fly, which means that maybe it is better to download the "NgModule" and create that module dynamically instead. This option is better because plugins UI would directly integrated into the main application UI. I am still trying out this method.

Another option suggested by @bruno was to develop the UI in SOA instead. This means that, we could choose not to separate the UI into plugins, but separate them into modules as independent service instead. You need to have a so-called "IT/Ops Client" that could help you manage what view to show in the UI, and the main UI is just a frame/template that will show what "IT/Ops Client" want to show. Using this way, we could register these services, and chose what service to be used. This is the microservice architecture and might be closed to what you want. The microservice expert Udi Dahan has a post blogged about this (link: http://udidahan.com/2014/07/30/service-oriented-composition-with-video/)