Microfrontends should be a last resort

Micro frontends are mostly trying to solve organizational issues, from what I’ve seen. You have some teams or individuals who really want to use a different tech for their project, or get away from legacy code without rewriting it, etc.

I interviewed at a place a couple months ago that was looking for an front end architect, and all the assumptions and questioning were that their use of microfrontends (both angular and react) was a good thing and how would I make teams follow this approach.

They passed on me when I made it clear that I didn’t think it was a very good approach for their smallish team, and in general that the challenges they were experiencing were mostly because of this architecture, not solved by it.

I think it's less about the technology than the organizational structure. If you have more than one monolith (aka any company with an acquisition) you either have to have it in code in two places (gross) or as a library. If you have it as a library, then you have N version bumps to do an N pipelines to deploy. Not hard technically, but tons of overhead.

This means that you lose independence and doing A/B testing becomes very difficult when you can't really control what the user is seeing because the version is pinned.

A micro front end allows you to deploy independently, test independently, and truly own your code. Network hops are reasonably cheap for most consumer applications and collaboration on a shared component is very expensive.

I'm speaking from the perspective of a checkout flow, which my company is actively ripping out from the monolith in order to ensure people outside the monolith can use it AND to ensure we're able to do the price testing/conversion rate testing at a level that doesn't need a separate suite of tools for each business unit. This also has the benefit of reducing integration points with the billing system leading to better standardization and consolidated data in one billing system.

I have designed and built something that could be described as a microfrontend system (though it's much more restrictive than "do what you like within this part of the page") and though it's been pretty successful I agree totally with the article. It's a lot of complexity if it isn't definitely worth it. Our "microfrontends" are really dynamically-loaded JavaScript modules of a particular type. They conform to one of a small handful of well-defined extension points, including defining UI (in React components, as it happens, but clearly this isn't React-specific). In this way engineers stay more or less on the golden path, and we can do some runtime checks to try and give better error messages. I think if we'd built something more general it would have been a mistake.

I feel like buzzword bingo in conferences is unavoidable.

The three easiest ways to get someone's attention in a title are: being a well known speaker, talking about a giant project, or talking about a trend.

As much as there is value in "tricks to avoid false negatives during CI" it just isn't as catchy.

I’ve worked on two 100+ weekly committer monoliths and two similar sized MFE architectures. I think the article hits good points though I’d add some acutely painful ones it misses[1]. I’m someone who is by gut now squarely in the pro-monolith camp, but I think that in the comment thread of a similarity anti-MFE article it’s worth steel manning the pro-MFE arguments rather than characterize it simplistically as cargo-culting or resume-boosting.

First, MFEs solve organizational issues by cheaply offering release independence. An example is when teams that do not overlap in working hours. Triaging and resolving binary release blockers is hard to do correctly and onerous on oncall WLB. Another example is when new products want to move quickly without triggering global binary rollbacks or forcing too fast a release cadence for mature products with lower tolerance for outages or older test pyramids.

Second, MFEs are a pragmatic choice because they can proceed independently from the mono/microrepo decision and any modularization investment, both of which are more costly by several multiples in the cases I've seen. Most infra teams are not ivory towers and MFEs are high bang-for-buck.

Finally, MFEs are a tool to solve fundamental scaling issues with continuous development. At a certain level of commits, race conditions cause bugs or build breakages or test failures, and flaky tests cause inability to (cheaply) certify last known good commit at cut time. You can greatly push out both of these scaling limits with good feature flag/health-mediated releases and mature CI, but having an additional tool in the kit allows you to pick which to invest in based on ROI.

Advocating for modularity is nice but I've never met an MFE advocate who didn't also want a more tree-shakeable modular codebase. We should not jump to the conclusion the MFE as bad or a "last resort" because there exists another solution that better solves an partially overlapping set of problems, especially if the other solution doesn't solve many problems that MFEs do or requires significant more work to solve them.

[1] Runtime JS isolation (e.g. of globals set by third party libraries) is hard and existing methods are leaky abstractions like module federation or require significant infra work like iframing with DOM shims. CSS encapsulation is very hard on complex systems, and workarounds like shadow DOM have a11y and library/tooling interop issues. Runtime state sharing (so not every MFE makes its own fetch/subscriptions for common data) is hard and prone to binary skew bugs. Runtime dynamic linking of shared common code is hard to reason around and static linking of common code can result in the same transition of a lazy loaded module to go from taking 10kB to 1MB+ over the wire.