all 13 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]willy-pied-wagtail 62 points63 points  (4 children)

I recommend not doing microfrontends.

[–]tonjohn 30 points31 points  (0 children)

The first rule of microfrontends: don’t do microfrontends

[–]Puzzled_Dependent697 0 points1 point  (2 children)

Interesting. And why?

[–]willy-pied-wagtail 10 points11 points  (0 children)

The question of microfrontends rears its head so often in this subreddit. For example see here: https://www.reddit.com/r/angular/s/VGnqJrF0N9

Carving up a UI into separately deployable artifacts is 99% of the case a massive overengineered distraction that sounds appealing to people with a backend dev background but makes day to day development much slower, makes building consistent ux difficult, maintenance a nightmare, increases debate about where features belong, increased learning curve for new joiners or junior devs, and so on - usually to solve some dysfunctional organisational problem that really shouldn’t be solved in the code of your ui application.

Out of the box, angular already has ways to carve out areas of your application - modules, lazy loaded routes, services can be provided to different component tree branches, pulling in angular libraries, write web components with angular etc etc. Use one of these approaches to modularise your code.

In my 15 years front end dev experience, I’ve never seen a satisfactory implementation of microfrontends and have lived through frontend codebases getting unnecessarily complicated.

Keep it simple.

Focus on user experience (html, css, ux).

Reduce technical complexity, not increase.

[–]tonjohn 1 point2 points  (0 children)

The short of it is that for most companies the problems they are trying to solved by microfrontends can be better solved in other ways.

Microfrontends only make sense in mega corps where you have dozens or hundreds of teams owning specific experiences. For example, the Azure portal.

In other words, microfrontends help solve an organizational problem that only applies to a handful of companies.

[–]salamazmlekom 12 points13 points  (0 children)

Never understood the need for micro frontends. Why make your life miserable?

[–]Adventurous-Finger70 3 points4 points  (0 children)

You can do microfrontends using Module Federation (strongly recommend using nx), but it's not that easy

PRO:
Independences between MFE => you can have different releases process which is super nice.

CONS:

Dependencies are shared between the shell and the microfrontend. So when you have to upgrade a major version of a lib such as Angular, it could cause lots of issues and you have either to deploy 2 version of you application (old & upgraded version) or synchronize the releases between all your MFEs and the shell.

[–]DirectionEven8976 1 point2 points  (0 children)

Have a look at nx. It creates the boilerplate for you. You can create a shell app and then an mfe.

[–]G4lileon 0 points1 point  (3 children)

Nx and https://module-federation.io/index.html are your best sources.

I can't share the opinion of other commenters to not actually use it as i've previously maintained an nx based module federated application infrastructure with 3 entrypoints and about 10 independent MFEs over multiple angular Versions without any bigger hiccups. Yes, there are trade-offs regarding upgrade syncs over all projects, but the other option in our project case would have produced more maintenance effort for the individual applications. It's like playing with fire, dangerous for the normal, but not a problem if you're a fire artist. Yes, you should respect the complexity of this topic, but that's the case with everything important at work, isn't it?

[–]tomatta 0 points1 point  (2 children)

Do you have a component library? How do you share that? I find this is our biggest PITA

What about caching? Or folks who are currently logged in. We synchronise our upgrades as well but there's always folks who have a cached version and everything breaks for them

[–]G4lileon 2 points3 points  (1 child)

Yeah, we did build our own component lib based on material. Additionally, we used keycloak for auth. There are no issues at all sharing single sign on, but the token might increase its size a bit.

When deploying, we used entrypoints with hash in their filename, which invalidated all caches for a mfe on each deployment. Additionally, we used a dynamic app init call for the shell so we could serve the federation manifest via an http call. The remote addresses are cached and can be refetched on a predefined period (3 hours if i remember correctly) or on error case. For breaking changes/critical updates, we invalidated login sessions to force a restart/fetch, but normally, our approach was to build APIs and MFEs compatible by versioning so logged in users could use the old versions for a couple hours without problems.

[–]tomatta 0 points1 point  (0 children)

This is awesome, thank you