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

Как организовать общение между микрофронтами?

Микрофронты обычно живут в разных бандлах (иногда разных командах/репозиториях) и монтируются в один shell (layout). Обмен данными зависит от того, same-origin они или нет.

Подход	Когда использовать	Комментарий
window.postMessage	Разные origin, iframe / web component из другого домена	Явная проверка origin; контракт сообщений (версионирование схемы)
CustomEvent на window / DOM	Shell и микрофронты на одном origin, UMD / script-тег	Простой event-bus без зависимостей
Общий event-bus (модуль)	Monorepo, shared npm-пакет	Типизированная шина подписок
Поднять состояние в shell	Нужны общие user, theme, permissions	Shell передаёт пропсы / контекст в дочерние приложения (если единый React/Vue runtime — осторожно с версиями)
BroadcastChannel / localStorage events	Синхронизация между вкладками или изолированными контекстами одного сайта	Не замена внутреннему state сложного UI
BFF / API	Источник правды на сервере	Микрофронты не обязаны знать друг о друге — только о домене данных
Module Federation (Webpack) / import remote	Динамическая загрузка remote с экспортом модулей	Общие зависимости и контракты версий нужно согласовывать

Практические рекомендации:

1. Минимизировать жёсткие связи — договориться о событиях/полях payload, а не о внутренних сторах друг друга.
2. Для iframe-микрофронтов — почти всегда только postMessage + политики безопасности (sandbox, CSP).
3. Авторизация: токены обычно в shell или cookie; микрофронт получает только то, что shell передаёт или что доступно через API.
4. Избегать двух копий React в одном DOM без изоляции — конфликты хуков и контекста; MF настраивают shared singleton.

Кратко для собеса: на одном origin — shared bus / события / контекст shell; на разных — postMessage; общие данные часто тянут через API или глобальный layout, а не через прямое чтение чужого state.