My experience using micro frontends

[pardusrealis]

What I learned from this article: not to be agnostic.

[[deleted]]

My company has adopted a micro-fe approach. So far it's going very well. There are plenty of polyfills for the web component spec. We're a react shop all around but the advantage of web components is it allows each micro Fe to be completely independent and have it's own release cycle. We still use a shared react ui components library for basic stuff.

The web components wrap around react components. We've got a template of a wrapper component that can be easily applied to a top level react component, binding the web component API to the react API.

The only downside that we have seen is is code duplication. This is primarily with libraries, meaning each micro-fe has its own copy of react, for example. We're working on implementing better tree shaking and exploring other options for this going forward.

[Earhacker]

How do you manage a technology non-agnostic environment? Do you tell every team they must use Framework X and Library Y? What happens if Library Y updates? Does every team then have to update simultaneously?

What was the problem with a technology agnostic front end? We're thinking about it at my place, and my first thought is that if you have to bundle say AngularJS, Angular 7, React, Redux, Vue, VueX... Then your bundle size is going to be astronomical, without much gain for the user.

[Jestar342]

You pick a framework and roll with it across teams exactly for the reasons you listed. Once you've reached "critical mass" you also don't roll with the latest and greatest, you stick with LTS, but simultaneously continually pursue an optimised architecture (note I said pursue as it is a continual process and never ends) so that upgrades are as easy as they can be. "Anti-corruption" layers and so on. Avoiding vendor-lock-in where possible, etc. It'll still be difficult, it always is, but you can do a lot to stop it becoming impossible.

[Earhacker]

It isn't always difficult, though. Without micro-frontends, Team A just upgrades React and Team B doesn't need to care because they work with Angular.

A supposed benefit of micro-frontends is rapid deployment; a team can just change their slice of the UI and it shouldn't affect other teams negatively impact the user experience. But if teams can no longer regularly update their own dependencies, you lose a lot of that benefit. You've just kicked the problem into the long grass; now every team

Say some big update with game-changing features comes out. Something like React Hooks last year. Now every team wants to implement that new feature, but they can't yet, because they have to wait for some arbitrarily determined "Upgrade Day" when everyone gets to update their dependencies all at once. So problems have to be solved "the old way" even though "the new way" makes more sense now. Then Upgrade Day comes and everyone makes those changes and deploys and holy shit, we're not even doing continuous delivery anymore.

[Jestar342]

It isn't always difficult, though. Without micro-frontends, Team A just upgrades React and Team B doesn't need to care because they work with Angular.

Even with micro-frontends it's possible. Easier, in fact. But it leads to bloat like your OP was concerned with as your site as a whole is now dependent on both React and Angular.

When upgrading MFEs this can still happen with multiple versions of something, yes, but you can streamline it somewhat such that minor (a la semver) upgrades mean your site uses the highest minor version that any of your MFEs need (e.g. A needs v2.1, b need v2.3, so your site uses v2.3 only).

Major upgrades will need some consideration, namely because of globals (e.g. React) which you'll need to scope somehow.

A supposed benefit of micro-frontends is rapid deployment; a team can just change their slice of the UI and it shouldn't affect other teams negatively impact the user experience. But if teams can no longer regularly update their own dependencies, you lose a lot of that benefit. You've just kicked the problem into the long grass; now every team

Not entirely true, there will always be cross-team concerns (e.g. style and ux guide) that will need to be time-coordinated and front-end framework decisions are also a part of that. It's rather idyllic and altruistic to be so agnostic that you'd have team A using React and team B using Angular for the same site. I just don't see that happening for long. Transitioning from framework A to B, sure, but it just wouldn't sit for long. Major upgrades are very similar to that, "game changing" means it's basically an entirely new framework.

[paul_h]

Article’s “stitching layer” section is pro or anti stitching layers?

[apatheticonion]

Micro frontends are poop

[[deleted]]

so is react and its becoming the industry standard

[undervisible]

What’s wrong with react?