Micro-frontends: independent delivery with explicit runtime contracts

Micro-frontends разделяют frontend по business/ownership boundaries и позволяют отдельным builds выпускаться независимо. Эта независимость условна: shell, route contract, shared dependencies, design tokens, telemetry и browser security policy остаются общими интеграционными поверхностями.

Module Federation загружает remote module асинхронно и затем выполняет его в общем JavaScript realm. Это композиция, не security sandbox: скомпрометированный remote обычно получает те же DOM и origin privileges, что host.

Проверяемые утверждения

• Независимый deploy требует versioned compatibility contract и rollback target; runtime loading без pinning превращает каждый refresh в неявный release.
• Shared dependency negotiation уменьшает duplication, но не доказывает semantic compatibility. Singleton может скрыть несовместимый API до runtime.
• CSP, trusted origins, immutable artifacts и SRI/integrity metadata уменьшают supply-chain risk, но динамический loader обязан действительно enforce выбранную политику.
• Iframe даёт более сильную isolation boundary, но добавляет cross-context messaging, focus, responsive layout и accessibility trade-offs.

Границы и компоненты

Сценарии

Compose pinned compatible remotes

The shell reads an environment-specific release manifest, verifies allowed origin/integrity metadata and loads exact checkout and account versions compatible with its contract range.

Проверяемый исход: A user session is reproducible from shell and remote release IDs; refresh does not silently select an unreviewed latest build.

Contain a remote load failure

Checkout fails integrity, timeout or initialization checks. The shell records the release context and mounts a tested route fallback without corrupting account navigation.

Проверяемый исход: Failure stays inside an explicit boundary, the user receives an accessible recovery action, and rollback remains selectable.

Evolve a shared contract compatibly

A design-system or routing contract adds an optional capability. Consumers pass contract tests before the shell raises its minimum supported version and later removes the old path.

Проверяемый исход: Producer and consumer deploy order is safe, and shared-library deduplication is separate from API compatibility.

Secure the remote delivery path

The shell accepts modules only from an allowlisted origin and immutable path with enforced integrity/CSP policy. A mutable or unexpected artifact is rejected before evaluation.

Проверяемый исход: Supply-chain controls fail closed and telemetry identifies the manifest, URL and policy result without executing untrusted code.

Failure, concurrency и evolution checklist

• Put error, loading and timeout boundaries around each independently loaded route; test failure before and after module evaluation.
• Keep a last-known-compatible release set and make rollback change the manifest atomically. Rolling back only the host can preserve an incompatible remote.
• Avoid distributed global mutable state and undocumented DOM events. Version cross-build messages and ownership explicitly.
• Test navigation, focus restoration, analytics correlation and CSS isolation across mixed-version canaries.

Security и privacy

• Treat an in-process remote as same-authority code, not tenant isolation. Use a stronger boundary such as sandboxed cross-origin iframe when the trust model requires it.
• Allowlist artifact origins, use TLS, immutable version paths, CSP and enforced integrity where the loader/browser path supports it.
• Do not place authorization decisions in remote UI. APIs authorize subject, tenant and object regardless of which frontend bundle issued the call.
• Minimize shared credentials and globals; a compromised remote can otherwise exfiltrate any data readable in the common realm.

Метрики, формулы и допущения

• initial_transfer = host_bytes + Σ critical_remote_bytes + shared_bytes_not_deduplicated; compare compressed transfer and parse/execute CPU separately.
• release_combinations = Π supported_versions_i is an upper bound if every remote can vary independently; pinning tested sets deliberately collapses this state space.
• remote_error_rate = failed_mounts / attempted_mounts must be segmented by host version, remote version, route and browser.
• A route performance budget should include added requests, critical-path depth and main-thread work; independent deployment does not make these costs independent.

Числа и bounds выше действуют только при названных units, population и assumptions. Ни паттерн, ни browser API сами по себе не задают SLA, capacity или correctness.

Решения для production review

• Split by durable product/team boundary, not by arbitrary visual component size.
• Choose build-time, server-side, runtime module or iframe composition from release and trust requirements; none is universally superior.
• Define host ownership of routing, authentication context, design-system baseline, accessibility shell and observability before allowing independent releases.

Первичные и официальные источники

• https://webpack.js.org/concepts/module-federation/
• https://html.spec.whatwg.org/multipage/webappapis.html#import-maps
• https://www.w3.org/TR/CSP3/
• https://www.w3.org/TR/SRI/

Scope note

Диаграмма использует Module Federation как один runtime example. Она не утверждает, что micro-frontends требуют webpack, что shared singleton безопасен или что независимый repository автоматически даёт независимый deploy.