Module Federation 2.0
I led architecture and adoption work on Module Federation 2.0 at ByteDance, connecting the open-source foundation with a complete engineering system for large web applications: development frameworks, debugging tools, module management, and deployment infrastructure.
This architecture supports products including Doubao Work, TikTok Web, Lark Docs, and Volcengine. It applies the principles of microservices to the web: teams own modules with explicit interfaces, develop and release them independently, and compose them into a coherent product.
The work grew out of my focus on micro-frontends and application modularization from 2020 to 2024. We released Module Federation 2.0 with Zack Jackson and the community in April 2024.
Making teams and releases independent
In a large application, unrelated features often share a build, a deployment, and a rollback. Moving shared code into npm packages still requires every consumer to upgrade and rebuild. A micro-frontend shell can become another bottleneck if it also owns business modules and distributes all shared dependencies.
The architectural change was to make a business module an independently delivered unit. Teams could validate a feature in the assembled product, choose its release audience, and roll it back without reverting unrelated features. The application shell could focus on composition while module ownership and release cadence stayed with the teams building them.
A system from development to delivery
The architecture connects five areas: runtime, build tools, development frameworks, debugging, and deployment. A module platform ties together discovery, versions, documentation, and dependency information.
A shared contract across tools
The manifest gives build tools, runtime, DevTools, and deployment integrations a common description of a module’s exports, assets, types, and dependencies. Decoupling the Federation Runtime from the bundler allows Webpack and Rspack projects to participate in the same composition model. These are part of the open-source 2.0 foundation.
At ByteDance, we connected that foundation to application frameworks and engineering platforms. Framework integrations handle application development; the module platform manages discoverability and versions; deployment integrations turn a versioned module into a controlled release.
Local development inside the real product
A developer should be able to work on one module while using published versions of the rest of the application. Dynamic TypeScript declarations preserve feedback across repository boundaries. Hot updates and local module overrides shorten the edit–validate cycle without requiring every participating application to run locally.
I worked on Chrome DevTools that expose module dependencies and configuration, and replace a remote module with a local implementation for debugging. This lets developers validate a change in its actual product context. The DevTools documentation covers module inspection and proxying.
Deployment as part of the architecture
The delivery system manages module versions, release audiences, and rollback through the existing deployment pipeline. It resolves the module information needed by a page and delivers a snapshot alongside it. The runtime can use that information for composition and resource preloading, avoiding a separate module-catalog lookup on the critical loading path.
This also changes shared-module upgrades: where the integration permits, a consumer can adopt a new module version through deployment configuration without rebuilding its application bundle. Compatibility validation and staged rollout remain part of that release.
Reuse that teams can maintain
A reusable module needs a discoverable owner, version history, API documentation, and a place to try it. The module platform brings search, dependency analysis, versioned documentation, and playgrounds into the same workflow. Dual npm and federated outputs support gradual migration; low-code blocks can also join the composition through the same module contract.
Applied to complex products
In Lark Docs, decomposition and deployment integration allow features such as comments to have their own development, rollout, and rollback lifecycle. In Doubao Work, document, spreadsheet, slide, and canvas applications can be maintained independently and assembled into a shared workspace.
TikTok Web and Volcengine bring the same architectural requirement: many teams must deliver parts of a large product without turning every change into an application-wide release. The infrastructure supports that model through shared contracts, tooling, and delivery controls.
Architecture decisions I focused on
- Choose boundaries around ownership and change. A module becomes useful as a release unit when a team can develop, validate, and operate it independently.
- Connect development and production through the same contract. Types, debugging, dependency analysis, and deployment all need to understand the same module relationships.
- Keep release decisions explicit. Version selection and rollout belong in delivery infrastructure; the runtime composes the modules selected for that page.
- Preserve product performance. Dependency sharing and preloading address the extra downloads and request waterfalls introduced by decomposition.
- Make migration incremental. Build-tool interoperability and npm-compatible outputs let teams adopt the architecture without replacing every application at once.
My contribution
I led the architecture and adoption work connecting these layers, and helped bring the reusable foundation to the open-source community as Module Federation 2.0. My scope covered runtime and protocol design, dynamic types, developer tools, and integration with development and delivery workflows. The engineering goal was to make independent ownership work throughout a module’s lifecycle—from the first local edit to a production rollback.
