CodeParkMicro-frontends split a frontend into pieces that are built and deployed separately. Each piece is owned by one team. The pieces are combined into one product.
Composition can happen in three places:
- At build time, as packages.
- On the server, with edge or server-side includes.
- At runtime in the browser, with Module Federation, or by loading apps per route inside a shell.
They are worth the cost when the organisation is the bottleneck. Signs of this:
- Many teams work on one product.
- Deployments block each other.
- Teams need different release cadences (how often they release).
- A gradual migration from a legacy framework, where old and new code must run side by side.
The costs are real:
- duplicated dependencies and larger bundles, if shared libraries are not coordinated
- inconsistent UX without a strong design system
- harder end-to-end testing
- harder state and routing across apps
- version skew at runtime, where pieces use different versions of a shared library
- more infrastructure
For a single team or a few teams, a well-structured monorepo is usually better. A monorepo is one repository that holds all the code. With clear module boundaries, it gives most of the benefits with far less complexity.
- Micro-frontends are parts deployed separately, each owned by a team.
- They can be combined at build time, on the server, or at runtime.
- They are worth it at large organisation scale or for a legacy migration.
- Costs include duplicated bundles, UX drift, harder testing and version skew.
- A monorepo is often the better default.
Read more
- patterns.dev (https://www.patterns.dev/)patterns.dev