0
votes

As far as I can tell there are two popular cases when using micro front ends -

1) Single page with components ( each on its own service ) 2) Multiple pages accessible from a dashboard / navbar ( each part on its own service )

I have been digging for a while now and from what I can tell case 1 is pretty straightforward when using Angular custom elements.

The problem is that I need to solve case 2. By design I got a dashboard (navbar on the side of the page) with a list of routes for different components entry points ( reports, users etc...).

I want this part to be the container and each route on the navabar of the container to lead to a separated micro front end which can live by itself and as part of the container. So I will have for example a reportService, userService etc... and a main/container service for when I build the full site.

I am having trouble with figuring out what is the best approach for achieving that goal, I seen all sort of articles but I still cant see a clear path ( prod ready etc... )

Are there any popular and prod ready approaches for that?

EDIT: The idea is for example - to be able to have two teams each working on a separate part of the site (a separated context) without having any affect on each other. Both got a standalone part of the site and on deployment the changes can be added to the main containing site. There is minimal (if any) connection between those two sub sites, they can be run alone or inside the container.

I added link to an article which explains my problem and much more and does it far better than I could ever do https://martinfowler.com/articles/micro-frontends.html

2
I don't want to sound mean, but it seems like you're using words you don't really know, and it results to very blurry sentences ... In Angular, each page of the SPA has its own components, they are usually routed, and the services are just classes that hold all of your business logic. I am not aware of "two popular cases when using micro front-ends", and extending the micro aspect to the front-end might not be a good idea (since Angular already does that internally). - user4676340
I understand that, I do have separation on the project itself..separated modules and the other standard approaches for separating components and logic inside an angular project. But I am testing an option to move it out into its own project. There are some very nice benefits for doing this on the client side as well. - Ivgi
So you're migrating from a micro-service architecture (like an API), to a monolithic one, not the opposite ? - user4676340
I've seen your other comment (on the answer) : you don't have to worry about conflicts in Angular, every module is separated from its sibling. As I said, it's all done under the hood, unlike an API. If I could give you one advice tough, it would be not to apply back-end principles to the front-end side of your project. They're separated for a reason, and you will get more headaches than results when trying such things. - user4676340
There is indeed more complexity when choosing such an approach, server or client side. But this is where everything seem to move to, smaller components, smaller units, more separation etc... I am wanting to test this on a fresh project. Because I seen many negative effects for having a client monolith no matter how well the angular framework handles it. - Ivgi

2 Answers

0
votes

I followed this approach for my projects, hope it helps you

Multiple pages accessible from a dashboard/navbar ( each part on its own service )

We created multiple modules based on the functionality like - UserModule, ReportsModule, InitialModule, etc., so that we can lazily load different modules based on the route.

Each module will have its own services, components, classes and assets that are required for the module. For example, InitialModule will have the components related to Login and Dashboard only, and we set it as bootstrap module in main.ts so that the page will load fastly by downloading the js, CSS, and HTML that are required for those two components only instead of all the assets

0
votes

Right now I'm developing a project which is similar to what you are asking. My current approach is using the library single-spa to organize and import the diferent micro-frontends. I currently have a navigation bar which is an angular app that is always displayed and uses angular routing to change between other applications that are loaded below the nav. You could start here.