Micro-frontends for large frontends

How micro-frontend platforms work, when they are worth it, and how to build and run one: architecture, teams, CI/CD and migration.

• What are micro-frontends? A plain guide for decision makersMicro-frontends split one large web application into parts that separate teams can build and release on their own. This guide explains the idea, the benefits and the bill, without code.
• When micro-frontends are worth it, and when they are notMicro-frontends pay off under specific conditions: several teams, coupled releases and clear business areas. Outside those conditions they add cost. Here is how to tell which side you are on.
• Module Federation vs Native Federation for AngularBoth load separately deployed Angular code at runtime and share dependencies between host and remotes. The difference is what does the loading: a bundler runtime or the browser itself.
• single-spa vs Module Federation: how to chooseThese two tools are often compared as if they did the same job. They overlap, but they start from different places: one manages application lifecycles, the other loads code and shares dependencies.
• Iframes, web components, packages or federation: integration techniques comparedThere are four common ways to put separately owned user interfaces on one page. Each trades isolation against performance and user experience in a different way. Most real platforms use more than one.
• The micro-frontend host: what it is responsible for and what it must not doThe host is the first application the browser loads and the one piece every team depends on. Keeping it small is the most important design decision in a micro-frontend platform.
• Routing across micro-frontends: route ownership, deep links and the navigation contractThe URL is the one thing every micro-frontend shares with every other. Clear rules about who owns which part of it prevent most integration problems before they appear.
• Sharing login and session across micro-frontendsUsers log in once and expect every part of the product to know who they are. That only works reliably when exactly one piece of the platform owns authentication.
• How micro-frontends communicate, and what to avoidWell-cut micro-frontends have little to say to each other. For what remains, there are a few simple mechanisms, ordered here from the loosest coupling to the tightest.
• Shared dependencies and versions in micro-frontendsSharing dependencies keeps a micro-frontend platform fast and consistent. It is also the tightest coupling between teams that the architecture leaves in place, so it needs explicit rules.
• Keeping one look across micro-frontends: tokens, components and style isolationUsers do not know your product is built by five teams, and they should never find out from the buttons. A shared design system is what keeps independent teams producing one product.
• CI/CD for micro-frontends: independent pipelines, discovery and rollbacksIndependent deployment is the reason to adopt micro-frontends. If a team cannot take its own change to production without building or releasing anything else, the architecture is not delivering what it costs.
• Error isolation and resilience in micro-frontendsA micro-frontend platform has more moving parts than a single app, so sooner or later something will fail to load. The goal is that one broken area never takes the whole product down.
• Micro-frontend performance: the costs and how to control themSplitting a frontend into independently deployed parts adds requests, bytes and startup work. None of it is fatal. It has to be measured and managed like any other budget.
• Testing micro-frontends: a practical strategyEach team can test its own remote well and the product can still break where the pieces meet. A testing strategy for micro-frontends puts most of its extra effort on those seams.
• Monorepo vs polyrepo for micro-frontendsMicro-frontends are about independent deployment. Where the code lives is a separate decision. A monorepo and one repository per team can both work, with different costs.
• From frontend monolith to micro-frontends, step by stepYou can move from one large frontend to micro-frontends without a freeze and without a big-bang release. The monolith keeps working while areas leave it one at a time.
• Running a legacy AngularJS app inside a micro-frontend hostA legacy AngularJS or jQuery application can live inside a modern host as one more micro-frontend. Users get a single product, and the old code is retired screen by screen.
• Team ownership, boundaries and Conway's lawMicro-frontends are an organizational tool first. The architecture works when the split between remotes matches the split between teams, and every piece has one clear owner.
• The real cost of micro-frontendsMicro-frontends buy team independence, and the price is paid in platform work, coordination and tooling. This is a breakdown of where the cost comes from and how it grows.
• Common micro-frontend mistakes and how to avoid themA small set of design and organizational mistakes shows up again and again in micro-frontend platforms. Each one is easy to recognize and has a known fix.
• Micro-frontend readiness checklistMicro-frontends succeed or fail on organizational conditions more than on tooling. Use this checklist to see whether your teams, pipelines and product are ready before you commit.
• Micro-frontend security: what changes and what to doA micro-frontend platform loads code from several places into one page. That changes the trust model, the Content Security Policy, the handling of tokens and the supply chain.
• Local development with micro-frontendsDevelopers should be able to work on one remote without running the whole platform. Good local development means one command, a fast start and a realistic environment.