skip to content

Microfrontends

10 roadmaps34 questions

Splitting a frontend into independently deployable pieces owned by different teams. You will cover how the pieces are composed, how they share dependencies, who owns which route, and the contracts that keep them from breaking each other.

part ofSoftware design & architectureoverview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

Given that sharing a dependency as a singleton across microfrontends avoids duplicate downloads and duplicate-instance bugs, under what circumstances would an architect deliberately choose NOT to share a dependency and accept the duplication instead?

level: principalimportance: should knowfreq 30%

basics

~20 s

When the cost of duplication (a bit more download size) is smaller than the cost of forcing every team to agree on one version. If teams need to move independently, the library is small, or one team is on an incompatible version on purpose, it's often better to just let it duplicate.

open as a page

You're responsible for governance across eight teams sharing a microfrontend platform, including a shared design-tokens package and a set of custom event contracts. What governance mechanisms would you put in place to stop a shared contract or token change from silently breaking someone else's microfrontend, and what does that governance cost you in return?

level: principalimportance: should knowfreq 25%

basics

~20 s

Write down who owns what, require an approval process and automated checks before any shared piece can change, and track who's actually using what so nobody breaks a team they didn't know depended on them. The cost is slower changes and real ongoing maintenance work for the governance itself.

open as a page

Some organizations move page composition from an origin application server to the CDN edge, using platforms like Cloudflare Workers or Fastly Compute, instead of a traditional origin-based composition service. What does moving composition to the edge actually change about latency and failure behavior, and what new constraints does the edge runtime environment impose that don't exist on an origin server?

level: principalimportance: nice to knowfreq 25%

basics

~20 s

Doing the page assembly on servers physically closer to the visitor, at the CDN edge, instead of far away at a central data center, cuts the network travel time, so pages come together faster. But those edge servers are much more limited in memory, CPU time, and what code they can run than a normal origin server.

open as a page

How does Vite's module federation approach, such as the @originjs/vite-plugin-federation or the @module-federation/vite plugin, differ mechanically from Webpack Module Federation, and in what situations would you avoid runtime module federation altogether in favor of build-time integration?

level: principalimportance: nice to knowfreq 20%

basics

~20 s

Vite-based federation tools connect apps using native browser ES modules instead of Webpack's own custom loading system, so it's lighter and faster in dev but has a shorter production track record. Sometimes the better answer is to skip runtime federation entirely and just build everything together in one monorepo.

open as a page

showing 31–34 of 34