Рубрика: база. Часть 2. Микрофронты.

Есть много способов реализовать то, что называется общим словом - микрофронт. При исследовании темы я нашёл даже такие способы, которые в целом то никто и не использует. К счастью, их мы обсуждать не будем. Я подготовил только то, что встречается в проектах и что делал я сам. Поэтому пост должен получиться содержательным.

1. 🧩 Module Federation с Nx Monorepo
Что это: динамическая загрузка удалённых модулей на runtime, с шарингом зависимостей между ними.
Почему важно: при использовании Nx можно легко организовать хост и модули внутри одного репозитория c CLI, кешом и девсервером.

🔧 Пример на Nx:

nx-project/
├─ apps/
│   ├─ shell/             # Host-приложение
│   │   └─ module-federation.config.ts  # содержит remotes
│   ├─ shop/              # Remote micro‑frontend
│   └─ cart/              # Remote micro‑frontend
└─ libs/                  # общие библиотеки (UI, utils)

Подключается примерно так: (очень упрощённо)

export const config = {
  name: 'shell',
  remotes: ['shop', 'cart'],
};

Плюсы:
- Независимый деплой – каждое приложение может деплоиться отдельно. Команды разработчиков не зависят друг от друга.

Минусы:
- Возможны ошибки при несовместимых версиях зависимостей.
- Для коммуникации между микрофронтами придётся изучить несколько интересных подходов 🙂

Когда использовать:
Если у вас монорепо + несколько команд, но хотите разделить деплой. Каждый микрофронт проще рассматривать как отдельную страницу.

2. 🧷 Iframe
Что это: каждый микрофронт — отдельное приложение в <iframe>.

Пример коммуникации:

// Родитель
iframe.contentWindow.postMessage({ type: 'init', data }, origin)
window.addEventListener('message', e => {
  if (e.origin !== origin) return;
  console.log(e.data);
});

Плюсы:
- Полная изоляция (JS, CSS).
- Прост в реализации.

Минусы:
- Медленнее UX: два документа, переходы.
- Коммуникация через postMessage — громоздкая.
- Ограниченное взаимодействие с окружением родителя.

Когда использовать:
Когда нужен строгий барьер безопасности, например для админки или внешних виджетов.

3. 🛠 Custom import()
Что это: вы создаёте оболочку, которая динамически подгружает модули через import(), без использования Module Federation.

🔧 Простой пример:

async function loadRemote(name, url, container) {
  const mod = await import(/* @vite-ignore */ url);
  await mod.init(channel);
  mod.render(container);
}


// Где-то в UI
loadRemote('chat', '/mfe/chat/remote.js', document.getElementById('chat'));

Коммуникация между модулями:

const channel = new Channel();

channel.subscribe('user', fn);
channel.set('user', { id: 1 });

Плюсы:
- Полный контроль загрузки.
- Гибкая интеграция prefetch, loader-style, lifecycle API.
- Не привязан к сборщику.

Минусы:
- Нужно самому реализовать lifecycle и shared dependencies.
- SSR потребует ручного подхода.
- Больше boilerplate.

Когда использовать:
Если вам нужен максимальный контроль, легковесность и неважна поддержка SSR из коробки.