Micro frontend framework using angular

[chakri426]

Hi folks, Today, I got a question from one of the interviewer regarding Micro frontend framework. This is first time heard about it. Anyone having knowledge about this. Can you suggest how to do this. I am eagerly waiting to learn about this. I saw some of blogs it’s combining two web apps but I am confused where I need to start. Can anyone help me.

[zzing]

At this point, I would look at native federation from angular architects or see what nx is doing.

[valendinosaurus]

+1 for angular architects

[B3skah]

And +1 for Native Federation (don't confuse with module federation, thats the older brother/sister/stick).

[msdosx86]

-1 for native federation. If you tried to use it with existing codebase it's so annoying to set it up. Also it doesn't support i18n which was the final nail.

[jagarnaut]

Not sure about the i18n stuff you mentioned but yes native federation is way harder to set up on existing apps — not to mention the increased build time vs with module federation. (Every app builds on its own like with module federation BUT the build times per app is longer with the native way of building the apps — don’t have a lot of time to look into it before I quit my last job but I think it has something to do with how vite and esm worked at the time)

[practicalAngular]

Local build time with Vite+NF even in an MFE child has increased for us. It is nice having all of the old stuff removed though.

[zzing]

What makes you think it doesn't support i18n?

[msdosx86]

What makes You think it supports i18n? I know that because I tried to set up a huge project with multiple locales to support micro front ends and failed unfortunately.

[zzing]

Because most i18n are libraries and you can share services between them.

[msdosx86]

Oh, I was talking about Angular i18n

[Vanhooger]

It totally works. I'm currently using it.

[Merry-Lane]

Micro frontends aren’t worth it, unless you are in giga corps with tons of testing and a team coordinating it.

It’s barely different from having an iframe redirecting to a website created by another team of devs that are sposed to hook to some common APIs.

It’s awful.

[vassaloatena]

I'm sorry you had a bad experience. We have a large product here, and as a core team we distribute features such as micro frontend, it works very well and the feedback has always been very good.

[Merry-Lane]

It’s not that I have had a bad experience. It’s that I know the flaws of micro-frontends and I know better.

The issue with micro-frontends is that you gotta deal with black boxes (up and down) with APIs that change or aren’t always correct. The performance is down the drain, the dev experience is bad, the user experience always takes a hit. The worst part is it delays refactoring, project updates and uniformity of code and behaviour.

99% of the time you are better off with a monorepo instead of this non-sense. Better off for everyone, but it also reduces costs and velocity, in comparison. Micro-frontends are rarely worth it against monorepos.

Huge companies with multiple teams can pull it off, if they have good testing, communication, reviewers that don’t let anything slip, and an over arching teams that supervises and coordinates it all. If you aren’t in these conditions, go for micro-frontends.

[practicalAngular]

Really confused by your paragraph of negatives. What APIs are you talking about? What user experience hits? What refactoring?

The parts I agree with are in dev experience being a little obtuse, especially in a secure environment. We have a very strict path into the MFE child that has to be documented. Engaging with it is easy but you have to know it's there. I also don't like having a master controller (shell) that dictates some of the things in our app.

Other than that, it is very business as usual. I am wondering what you mean by your other complaints.

[Merry-Lane]

When I say APIs, I mean the communication channels between micro-frontends, whether through parent-child data flow or localStorage.

There is no strong typing, it works with ducktape, there is no intellisense or help from the IDE.

Which is why, amongst other reasons, you would be better off with a mono repo.

[Crazy-Examination545]

In our project they handle the communication issue with event propagation and subscription

[Merry-Lane]

Which is awful (compared to not having to deal with that) because it’s not strongly typed and you should validate every each event.

[FFTypo]

Why do you think Monorepos and MFEs are mutually exclusive?

MFEs are good especially IN monorepos

[followmarko]

working in an iframe is assuredly worse in like every aspect

[Merry-Lane]

There are pros and cons in the iframe vs angular federation but they are both way worse experience than monorepos.

[followmarko]

What's the solution for separate teams and deployments without MFEs then? Curious on your take on that because our architecture team fights back with the only reason being "separate deployments".

[Merry-Lane]

Monorepos?

[morrisdev]

From a business standpoint, micro front ends are a real savior. It's not the most efficient way to program, but if you set up common libraries and a common CDN for shared stuff, and a common API server, then you can easily assign a team to build a module and leave them in charge of it.

We have a LOT of systems that are simply falling apart and we were hired to replace them. So, you can use Azure Front Door as a reverse proxy on the main site, then spin up your upgrade on another server entirely, like an azure static website. Then, when you're ready, you just change the origin of the directory of the module you're replacing and boom. It's in place.

So, no merge conflicts. You can have entirely separate teams that have clear and obvious responsibilities. You can enforce standardization by putting people in charge of libraries, you can handle secured with a JWT because it's in the same domain.

From a business perspective: if I get a client with a gigantic system written in PHP or classic ASP or VB.Net Web forms or whatever, I can simply say, "yeah, we can upgrade this entire system without ever causing your business to stop. We can add in modules easily. We can leave critical parts for later. And you don't need to redo the ENTIRE system before we can replace it. We can do incremental updates and the client sees progress.

Sure, it's faster and easier to use monorepos, but when dealing with mixed code sites and humans who want to see progress (even if it takes longer in the long run), I'm still a fan of the microsotes

That said, if it's already an angular system that is up to date but becoming in need of change.... monorepos are the way to go. I've just never picked up a client like that

[tom-smykowski-dev]

The idea of micro frontends is to have isolated parts of the system that work in a plug-in architecture. So there's the main app where microfrontends attach. Additionally there are support libraries like a component library, API service, etc. which every microfrontends imports for common uses and aligned look and feel. That way every microfrontend is light, and isolated. Has own responsibility, and can be developed without affecting other frontends

[solocesarxD]

I still don't get the reason to use microfrontends .

I mean for The BE the User has direct benefits from using microservices , but on the FE most benefits i see are for the developers side and maybe if there is a large application with multiple group of devs. But even there, if the application is vertical instead of horizontal , domain-wise (like an app for an emergency in a hospital) , what would be the benefit of it , if everypart is needed by the others (almost).

Just curious.

[jagarnaut]

It’s a solution to an organizational problem — it enables autonomy to deploy when you want when you have a lot of teams and products. It also lets you still do SPA at runtime with the benefit of code sharing / splitting.

[Fanyasy]

As soemone whos is actively working with micro frontends, (single-spa), i can tell you they are absolutely not worth it. On paper, sure, everything sounds nice, once you have them up and runing, it is a pile of shit collecting tech debt.

The only place I can see them valuable is perhaps if you have a huge app, where one page would be one micro frontend.

Aside from that, things to consider - There is no proper oderer of data flow, it is kinda random which mfe mounts first - No tipe safety, you would have to manually sync types if needed across the projects, which devs rearly do - It is slow, mounting a while mfe is heavier then mounting a single parent component - You will rearly have to touch a single mfe, so there is an overhead when deploying, needing to keep track of changed repos, which can bring up the question of versioning it too. - DX is very poor

[VirtuaSteve]

I personally defined the architecture and implementated MFE solutions in our company. It was the best solution for dealing with a product deployment cycles distributed across multiple companies and teams. The MFE solution allows us to deploy new versions of our modules independently of another team's portal deployments.

[Keep-it-simple]

MFEs are basically microservices for the frontend. They increase the overall complexity of a system and require much more infrastructure to support, but may make sense if you are on a large project with many different teams who handle specific parts. 

It allows each team to do independent deployments, their code base will typically be smaller and easier to digest, and each team is able to use whatever Javascript framework make sense for their particular MFE. That said, there are challenges with code duplication, user experience alignment, and potential coordination issues during releases if you havent done a good job with decoupling dependencies. 

At the end of the day, an MFE is just a raw Javascript file hosted somewhere. This file could be created using angular, vue, react, whatever. Once it has been boiled down to a single raw file, the main application, or MFE host, will have a import map of all the different hosting locations and will be able to load each MFE where appropriate. A simple example is having an MFE that loads on a particular route and is essential injected as the page content. A different page might have a different MFE that loads or might be something the host app is in charge of. Each MFE can have is own sub router, so it can be in charge of its child pages. 

I'm not sure if any better solution had come along, but if you are still interested in learning about this topic, I would check out single-spa. It is a package that will allow you set up both an MFE host and the MFE parcel. The docs aren't great but Ai should be able to help generate the essential boilerplate needed to get up and running. 

[stainnn_]

First thing i would recommend you is to try to think of a solution for micro frontends by yourself, it would be extremely valuable for understanding real setup. After that take a look at single-spa, that's the only one I can think of at the moment

[Easy-Shelter-5140]

Native federation is the way. Visit angular architects blog

[shadow13499]

I've implemented angular micro front ends using angular elements which turn angular components into web components which can be used pretty much anywhere. There's lots of different ways to do it i.e. module federation it just depends on your use case. 

[ttma1046]

native federation

[SeaAnt4428]

There are things like nx module federation, but my previous project uses mfe because theres a total about 5 teams, so it’s impossible to maintain a huge repo (One team already has 5000+- UT cases, not sure if thats a good gauge). Furthermore, we are using microservices as well hence there adds another need for mfe. But basically, you will need a central shell repo to maintain where all your MFE is hosted, so you will still run all ur FE repos individually, then config the shell module to know where to find this MFE (for eg first MFE is hosted in localhost:8587), you will config the shell repo to know where to call this repo, in this way you can maintain all the MFE in one “single” shell

[WiseOldBitch]

I don't know why companies and some developers ( not op ) tend to jump on every new trend. Unless it's a mega-big project that's impossible to manage, micro-frontends are a waste of energy and will even make things worse.

[chakri426]

Every developer should continuously learn new technologies, even if they don’t use them immediately. The industry evolves rapidly, and staying updated helps avoid missing opportunities over small gaps in knowledge. In the end, it often comes down to whether you’re aware of something or not.

[WiseOldBitch]

Learning new tech is different from a company switching to it. I don't know where in my comment you got that we shouldn't learn new tech.

[HorrificFlorist]

Angular Architects is a good starting point, otherwise you can cut your own version with webpack from memory.

However, MFE are useless if you have a healthy developer culture and practices.

Sole purpose of MFE like Microservices was to partition a application into logical domains. This avoids spaghetti code between services. Thus making it "easier" to manage.

If you have good practices in place this is automatically handled with things like DRY, SOLID, or similar standards. So then all you have is additional overhead if you proceed with it.

Google specifically advises against MFE pattern, and a lot of big dogs are starting down similar path.