micro-frontends.js·4 scenarios
Micro-frontends concept page demonstrating runtime composition via Module Federation. Shell host app loads independently-deployed remote MFEs (Search/Product/Checkout) from per-team CDN bundles, each with its own BFF backend and CI/CD pipeline. Shows shared design system as singleton via shared scope, cross-MFE communication through window CustomEvents bus, and React error boundaries for failure isolation. Four scenarios: initial load with Module Federation runtime, independent deploy by Checkout team without redeploying others, cross-MFE event from Search to Checkout via event bus, and failure isolation when one MFE bundle fails to load. Includes ADR on when MFE worth the complexity (Spotify/IKEA/Zalando scale: 100+ engineers, 5+ teams) vs anti-pattern for small teams.
Micro-frontends нужны не потому, что frontend тоже хочет "как microservices". Они нужны, когда организационный масштаб ломает монолитный UI: 100-200 инженеров меняют один SPA, build занимает десятки минут, релиз checkout блокируется багом в search, merge conflicts становятся ежедневной работой, а roadmap разных продуктовых команд привязан к одному deploy train. В такой ситуации проблема не в React, а в независимости команд.
Micro-frontend переносит идею автономных сервисов на пользовательский интерфейс: shell композирует independently deployed UI-фрагменты, каждая команда владеет своим bundle, backend/BFF и pipeline. Но это дорогой инструмент. Для небольшой команды MFE почти всегда замедлит delivery: появятся versioning shared dependencies, runtime loading, design-system governance, cross-MFE communication contracts, error boundaries и новый класс production-инцидентов.
Урок нужен, чтобы отличать реальный organizational scaling от architecture theater. Micro-frontends - это лекарство от bottleneck одного frontend-монолита в большой организации, а не способ сделать код "модным".
Shell - это host application: верхнеуровневый router, layout, auth shell, shared dependency scope, error boundaries и composition runtime. MFE - это feature/page-level UI, который команда может билдить и деплоить отдельно. CDN хранит remoteEntry.js и chunks по версиям. Shared design system и React должны быть singletons, иначе получите два React runtime, сломанные hooks и визуальную кашу.
Композиция бывает разной:
Ключевой unit - не кнопка и не карточка, а feature/page boundary: search, product, checkout, account.
Диаграмма показывает четыре группы. В Browser живут shell, mfe-search, mfe-product, mfe-checkout, event-bus и design-system. Shell монтирует remotes, shared design system поставляет Button/Card/Form как singleton, event bus реализован через window.CustomEvents. В CDN лежат independently deployed bundles: cdn-shell, cdn-search, cdn-product, cdn-checkout, cdn-ds. В Backends у каждого MFE есть свой API/BFF: search, catalog, payments. В CI/CD каждая команда имеет собственный pipeline.
Ребра показывают реальные зависимости: shell грузит remoteEntry с CDN, MFE монтируются в shell DOM, MFE используют design system, общаются через event bus и ходят в собственные backends. CI pipeline публикует новую версию bundle в CDN без redeploy shell и других MFE.
ADR-001 на shell задает главное ограничение: MFE оправданы при 100+ frontend engineers, 5+ teams и четких domain boundaries; маленьким командам лучше modular monolith.
initial-load показывает пользователя на /search?q=laptop. Shell уже загружен и содержит router + Module Federation runtime. Он инициализирует shared scope с React и design-system, затем параллельно грузит Search и Product remotes. Search MFE потребляет Button/Grid из design system и вызывает свой search API. Урок: одна страница составлена из вкладов нескольких команд без runtime coordination, но это работает только при строгом shared dependency contract.
independent-deploy показывает Team C, которая выкатывает checkout fix. Pipeline собирает mfe-checkout/v1.7.6/remoteEntry.js, загружает на CDN и инвалидирует cache. Следующий pageview shell получает новую версию checkout без redeploy search/product/shell. Урок: независимый deploy - главный выигрыш MFE. Но если Team C обновила React major, а shell еще на старом shared scope, релиз может сломаться.
cross-mfe-event показывает product:selected через window.dispatchEvent. Search не импортирует Checkout и не знает его API; Product и Checkout подписаны на event schema. Урок: loose coupling работает, если event contracts версионируются. Shared Redux store между MFE - анти-паттерн, потому что он снова связывает команды runtime-зависимостью.
failure-isolation показывает падение mfe-checkout/remoteEntry.js с 503. ErrorBoundary в shell ловит ошибку и показывает checkout fallback, а Search и Product продолжают работать. Урок: без per-MFE error boundary micro-frontends превращают один parse/load failure в white screen всего сайта.
ADR-001 предлагает pragmatичный decision tree. До 30 frontend engineers: не делайте MFE. Modular monolith, feature flags, Turborepo/Nx, code owners и нормальный release process дешевле. 30-100 engineers, 3-5 teams: начните с build-time composition и shared design system как npm package. Это дает структуру без runtime complexity. 100+ engineers, 5+ teams: Module Federation + single-spa path delegation становятся оправданными, особенно для checkout/account/search и похожих независимых областей.
Плюсы MFE: independent deploy, team autonomy, runtime failure isolation, возможность мигрировать legacy по частям, соответствие Conway's Law. Минусы: больше JS, сложнее shared dependencies, тяжелее observability, runtime loading failures, version skew, необходимость semver policy для design system и event schemas. Tech independence часто переоценена: React + Vue + Angular одновременно дают большой bundle и сложный shared state. Разные фреймворки оправданы при acquisition/legacy migration, но не как default.
Design system - это контракт, а не библиотека "для красоты". Без единого DS MFE начинают выглядеть как разные продукты. Без semver и migration policy команда design system становится bottleneck или ломает чужие bundles.
Zalando развивал Project Mosaic и Tailor для server-side composition. Spotify desktop historically использовал похожие идеи в Chorus. AWS Console естественно разделяет S3, EC2, IAM и другие domains под единым shell. IKEA, DAZN, HelloFresh и крупные e-commerce платформы применяют MFE там, где команды и поверхности достаточно независимы. Stripe Checkout и Intercom показывают iframe/embed сторону: сильная изоляция нужна, когда UI встраивается в чужой сайт. Module Federation стал популярным в крупных React/Webpack организациях, а Vite ecosystem догоняет через federation plugins.
product:selected меняет payload, чужие MFE ломаются молча.Не используйте micro-frontends, если основная боль - плохая структура папок, медленный локальный dev server или отсутствие code owners. Это решается монорепой, модульными boundaries, caching в CI и feature flags. Не используйте MFE, если нужен один согласованный UX и одна маленькая команда быстро меняет весь продукт. Не используйте MFE для SEO-критичного каталога без server-side composition или pre-render strategy. Не используйте MFE, если у вас нет platform team, которая владеет shell, shared deps policy, observability и rollback моделью.
Внешние ориентиры: Luca Mezzalira "Building Micro-Frontends", Cam Jackson article на martinfowler.com, Webpack Module Federation docs, single-spa docs, Zalando Tailor/Project Mosaic материалы, Podium by Finn.no и ThoughtWorks Technology Radar.