Как устроена навигация между отдельными приложениями в микрофронтендной архитектуре и кто управляет роутингом?

В микрофронтендной архитектуре приложение разбивается на несколько независимо разрабатываемых и деплоимых частей. Навигация между ними — одна из ключевых задач, потому что пользователь должен воспринимать всё как единое приложение, хотя под капотом это разные бандлы и команды.

Кто управляет роутингом

Обычно выделяют два уровня маршрутизации:

• Shell (host) приложение — управляет верхнеуровневыми маршрутами и решает, какой микрофронтенд загрузить на текущем URL.
• Микрофронтенд (remote) — управляет своими внутренними маршрутами, которые находятся «под» его базовым путём.

Shell не должен знать детали внутренних маршрутов микрофронтендов — только их базовые префиксы. Это сохраняет слабую связанность.

Как это работает на практике

Чаще всего используется History API браузера. Shell слушает изменения URL и по префиксу пути определяет, какой микрофронтенд активировать. Внутри микрофронтенда уже работает свой роутер (React Router, Vue Router и т.п.), который читает тот же URL.

// Shell: верхнеуровневый роутинг
const routes = [
  { path: '/catalog/*', load: () => import('catalog/App') },
  { path: '/cart/*',    load: () => import('cart/App') },
  { path: '/profile/*', load: () => import('profile/App') },
];

function Shell() {
  const { pathname } = useLocation();
  const route = routes.find(r => matchPath(r.path, pathname));
  const Remote = useRemoteModule(route.load);
  return ;
}

Варианты реализации

1. Единый роутер в shell — все маршруты описаны в host, микрофронтенды получают basename. Просто, но host знает о всех путях.
2. Децентрализованный роутинг — каждый микрофронтенд сам регистрирует свои маршруты в общем реестре. Гибче, но сложнее синхронизировать.
3. Событийная навигация — shell публикует события навигации, микрофронтенды подписываются. Полезно при интеграции legacy-приложений.

Подводные камни

• Конфликты версий роутеров между микрофронтендами.
• Синхронизация состояния URL при переходах между remote-приложениями.
• Обработка 404 и «глубоких» ссылок, когда микрофронтенд ещё не загружен.

Итог: применять такой подход стоит, когда несколько команд разрабатывают крупное SPA и нужна независимость деплоя. Shell управляет верхним уровнем, микрофронтенды — своими внутренними маршрутами, а связующим звеном выступает History API и общий контракт по путям.