0

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

Ivgi
  • 541
  • 1
  • 6
  • 21
  • 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). –  Oct 03 '19 at 12:59
  • 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 Oct 03 '19 at 13:10
  • So you're migrating from a micro-service architecture (like an API), to a monolithic one, not the opposite ? –  Oct 03 '19 at 13:18
  • 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. –  Oct 03 '19 at 13:20
  • 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 Oct 03 '19 at 13:27
  • But again, smaller components/units/etc. is already done in Angular. I'm really trying to explain it to you, it works & behaves differently. I you follow your micro-service approach, you stack applications onto each other (which means they're displayed one after the other in your page !). That messes up your routing, that messes up your global scope, that messes up your state management in the browser, you cache ... Really, those are two different worlds ! –  Oct 03 '19 at 13:32
  • hi @Maryannah, are you saying that modularizing in frontend is not a good idea? – anjnkmr Oct 03 '19 at 13:40
  • @rak No I'm not. I'm saying that splitting one Angular application into severals (as opposed to separating modules, the way Angular intended to) is not a good idea. –  Oct 03 '19 at 13:41
  • OK, actually, I'm also working on a large project with different modules Is there any better way to make different teams work on such a project? can you suggest – anjnkmr Oct 03 '19 at 13:45
  • @rak if they work separately on each module, then no, I can not think of a better approach. That's how Angualr is intended to be used ! –  Oct 03 '19 at 13:47
  • But what if for example you want a complete separation between two domains - users and reports. Each domain is technically a standalone "product" - different services, client and server side with a different team working on each. Yet in the end on production you do want to deploy/host them on the same "main" website on your machine. – Ivgi Oct 03 '19 at 13:54

2 Answers2

0

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

anjnkmr
  • 838
  • 15
  • 37
  • But it is still a single project? I am trying to test an approach of actually separating those 'modules' into their own projects which can run standalone without the container. Each team can work on its own module without having to worry about conflicts or affecting anything which is outside their project context – Ivgi Oct 03 '19 at 13:14
  • yes it is a single project, To make separate projects with modules, first we need to prepare the common/ shared modules then import them in all projects – anjnkmr Oct 03 '19 at 13:25
  • We actually used a similar approach but I am now eager to have a full separation in the future on new projects – Ivgi Oct 03 '19 at 13:30
0

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.

Oriol_IL
  • 120
  • 1
  • 14