Веб-разработка
Микрофронтенды
IKEA перешёл на микрофронтенды при запуске международных версий сайта: команды в разных странах независимо деплоят свои части. Отдел корзины обновляется 5 раз в день, каталог - раз в неделю. Без микрофронтендов одна команда блокирует другую. С Module Federation - полная независимость при единой UX.
- **Zalando** использует micro-frontends с Module Federation - 200+ команд деплоят независимо; fashion discovery, checkout и account компоненты от разных команд на одной странице
- **Spotify** имеет iframe-based microfrontends для своих 3rd-party widgets (музыкальные плееры на других сайтах) - максимальная изоляция без доступа к hosting page DOM
- **SAP** построил BTP (Business Technology Platform) на Web Components - enterprise клиенты встраивают SAP компоненты в свои Angular/React приложения
Module Federation
Module Federation (Webpack 5) позволяет одному приложению (host) загружать JavaScript модули из другого приложения (remote) в рантайме. Команда A деплоит свой remote bundle, команда B автоматически получает новую версию без пересборки. Это решает проблему монолитного frontend: независимые деплои при единой UX.
Module Federation shared dependencies: если host и remote оба используют React, можно указать React как shared singleton - загрузится только одна копия. Это критично для избежания multiple React instances (context не работает между экземплярами). Vite Module Federation через `@originjs/vite-plugin-federation` - та же концепция для Vite.
Почему shared: { react: { singleton: true } } критично в Module Federation?
single-spa
single-spa - JavaScript framework для микрофронтендов: каждое приложение (React, Vue, Angular, vanilla) регистрируется как отдельный lifecycle (bootstrap, mount, unmount). Root config управляет какое приложение активно в текущем URL. Поддерживает concurrent rendering нескольких фреймворков на одной странице.
single-spa architecture: root config (HTML + import map) + registered applications (routing) + parcels (компоненты монтируемые программно). Import maps - браузерный стандарт для mapping package names на URLs: `import 'react'` → `https://cdn.skypack.dev/react@18`. SystemJS для legacy браузеров без нативного import maps поддержки.
В чём архитектурная разница между Module Federation и single-spa?
iframe изоляция
iframe - максимальная изоляция между микрофронтендами: отдельный browsing context, отдельный JavaScript heap, CSS полностью изолирован, разные origins защищены Same Origin Policy. Цена: тяжёлый для браузера, сложная коммуникация, проблемы с z-index, routing, accessibility. Оправдан для: legacy приложений, security-critical виджетов (платёжные формы, OAuth).
Stripe использует iframe для платёжной формы - CVV поле физически в iframe другого origin. Это гарантирует что host сайт не может скриптом прочитать данные карты. postMessage API - единственный способ коммуникации между iframe разных origins: `iframe.contentWindow.postMessage({type: 'PAYMENT_READY'}, 'https://stripe.com')`. targetOrigin критично для безопасности.
Почему проверка `event.origin` критична при получении postMessage?
Web Components как Integration Layer
Web Components как integration layer для микрофронтендов: каждая команда экспортирует свой микрофронтенд как Custom Element. Shell регистрирует эти elements и монтирует по URL. Shadow DOM гарантирует CSS изоляцию без iframe overhead. Команда может использовать React внутри, Angular внутри - снаружи виден только HTML element.
Преимущества Web Components для микрофронтендов vs Module Federation: нет binding к webpack, работает с любым bundler, стандартный API. Недостатки: сложнее shared state между компонентами, SSR support ограничен. Реальная практика: большинство компаний комбинируют подходы - Module Federation для shared компонентов + Web Components для изоляции boundaries + iframe для security-critical частей.
Микрофронтенды - всегда правильный выбор для больших команд
Микрофронтенды значительно увеличивают операционную сложность: независимые deploy pipelines, shared dependencies versions, cross-team integration testing, сложный local development. Монорепо с хорошо разделёнными модулями решает большинство проблем командного масштаба проще. Микрофронтенды оправданы когда команды действительно независимы и технологически разнородны
Spotify, Netflix используют монорепо для frontend; они избегают overhead микрофронтендов. Настоящие микрофронтенды оправданы при M&A (разные компании), legacy migration или действительно раздельном деплое
Когда Web Components изоляция предпочтительнее iframe для микрофронтендов?
Ключевые идеи
- **Module Federation** - runtime sharing модулей между Webpack bundles; shared: {react: singleton} критично; командная изоляция при единой React версии
- **single-spa + iframe** - single-spa оркестрирует lifecycle приложений по URL; iframe максимальная изоляция для security-critical виджетов (postMessage с проверкой origin)
- **Web Components integration** - Shadow DOM CSS изоляция без iframe overhead; React/Vue внутри = Custom Element снаружи; composedEvent для коммуникации
Связанные темы
Микрофронтенды - часть широкой стратегии крупных веб-приложений:
- Web Components и Shadow DOM — Web Components - один из главных механизмов интеграции и изоляции микрофронтендов
- Архитектура крупных веб-приложений — Монорепо + Design System - альтернатива микрофронтендам; feature flags для независимых деплоев без полного разделения
Вопросы для размышления
- Компания из 10 команд по 5 человек, одно React приложение. Когда переходить на микрофронтенды и с какого подхода начать?
- Как организовать shared Design System между 5 микрофронтендами разных фреймворков (React, Vue, Angular)?
- При использовании Module Federation - как управлять shared dependencies версиями чтобы remote не сломал host при мажорном обновлении React?