English for Micro-Frontend Developers

Micro-frontend architecture splits a large frontend application into independently deployable pieces owned by different teams, which means the vocabulary around it overlaps heavily with organizational and cross-team communication, not just technical structure. Being precise about terms like “shell,” “module federation,” and “contract” helps avoid the kind of ambiguity that causes integration bugs between teams that rarely touch each other’s code directly.

Key Vocabulary

Shell application (host) The top-level application responsible for loading, arranging, and providing shared context to the individual micro-frontends, typically handling routing and overall page layout. Example: “The shell application owns the top navigation and decides which micro-frontend to mount based on the current route.”

Module federation A technique (popularized by Webpack) that allows separately built and deployed JavaScript applications to dynamically load code from one another at runtime, without needing to be built together. Example: “We use module federation so the shell can load the checkout micro-frontend’s latest deployed build without rebuilding the shell itself.”

Micro-frontend (remote) An independently developed, built, and deployed piece of a larger frontend application, typically owned by a single team and responsible for a specific area of functionality. Example: “The search micro-frontend is owned entirely by the discovery team, and they can deploy it independently of the rest of the site.”

Contract (in micro-frontend context) An agreed-upon interface — such as shared props, events, or a versioned API — that defines how a micro-frontend communicates with the shell or with other micro-frontends. Example: “We broke the contract by renaming this shared event without a deprecation period, and two other teams’ micro-frontends silently stopped receiving it.”

Shared dependency A library (like a UI framework or design system) that multiple micro-frontends rely on and, ideally, load only once, to avoid duplicating bundle size and to keep behavior consistent across the page. Example: “We’re deduplicating the shared dependency on our design system library, since three micro-frontends were each shipping their own copy.”

Version skew A situation where different micro-frontends on the same page are running incompatible versions of a shared dependency or contract, often causing subtle runtime bugs. Example: “This bug only reproduces in production because of version skew — staging happened to have all micro-frontends on the same shared library version by coincidence.”

Composition (page composition) The process of assembling multiple independently built micro-frontends into a single coherent page, either on the server, at the edge, or in the browser. Example: “We moved page composition to the edge so users get a fully assembled page on first load instead of waiting for client-side composition to finish.”

Team topology (in this context) How team ownership boundaries are drawn across the micro-frontend architecture — ideally matching each team to a coherent, independently deployable slice of the product. Example: “Our current team topology has two teams both touching the checkout micro-frontend, which is exactly the kind of overlap that causes the deployment conflicts we’ve been seeing.”

Common Phrases

In code reviews:

• “This micro-frontend is reaching directly into another team’s internal DOM structure instead of going through the agreed contract — that will break the moment they refactor their markup.”
• “We’re bundling our own copy of the design system instead of using the shared dependency — that’s adding 200KB we don’t need to ship.”
• “This event name change isn’t backward compatible — we need a deprecation period before removing the old event entirely, since other teams may still be listening for it.”

In standups:

• “Yesterday I fixed a version skew bug between our micro-frontend and the shell’s shared React instance; today I’m adding a runtime check that fails loudly instead of silently breaking.”
• “I’m blocked on the checkout team’s contract change — they renamed a prop without updating the shared type definitions, so our integration tests are failing.”
• “I finished migrating our micro-frontend to module federation; it now loads independently from the shell without a full site rebuild.”

In cross-team architecture discussions:

• “If we don’t formalize this contract, every renamed prop or event risks silently breaking another team’s micro-frontend in production.”
• “We should version this shared contract explicitly, so consumers can opt into breaking changes on their own schedule instead of being surprised by them.”
• “This overlap in team topology is causing deployment conflicts — should we redraw ownership boundaries so each team owns a cleaner, more independent slice?”

Phrases to Avoid

Saying “it just broke” when a shared contract changed. Say instead: “the shared event contract changed without a deprecation period” or “there’s version skew between our shared dependency and theirs.” These point directly at the actual cause, which is almost always a coordination gap, not a mysterious failure.

Saying “we’ll just coordinate manually” as a long-term contract strategy. This doesn’t scale past a couple of teams. Say instead: “we need a versioned, documented contract with automated compatibility checks” — manual coordination should be a stopgap, not the plan.

Saying “micro-frontends” as if it automatically implies full team independence. Splitting code into micro-frontends doesn’t guarantee independent deployability if teams still share tightly coupled contracts or deployment pipelines. Be specific about what’s actually independent versus what still requires coordination.

Quick Reference

Term	How to use it
shell application	”The shell owns routing and mounts the right micro-frontend.”
module federation	”Module federation lets the shell load remotes built independently.”
contract	”We broke the contract by renaming a shared event without notice.”
shared dependency	”Deduplicating the shared dependency cut bundle size significantly.”
version skew	”This bug only shows up in production due to version skew.”
composition	”We moved page composition to the edge for faster first paint.”

Key Takeaways

• Frame integration bugs in terms of contract violations or version skew, not vague “it just broke” language — this points teams at the real, coordination-related cause.
• Formalize shared contracts (events, props, shared dependencies) with versioning and automated checks rather than relying on informal, manual coordination.
• Distinguish clearly between what’s truly independent (deployment) and what still requires cross-team coordination (shared contracts, dependencies) when describing your architecture.
• Team topology and code architecture should be discussed together — overlapping ownership is often the root cause of recurring integration friction.
• Module federation and composition strategy choices should be explained in terms of their tradeoffs (build-time coupling vs. runtime flexibility), not just as implementation details.