Как можно передавать идентификацию пользователя и общее состояние между независимыми микрофронтендами?

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

Основные подходы

• Общий стор — host-приложение предоставляет Redux/Zustand/Context, а микрофронтенды подключаются к нему через контракт.
• Custom Events — микрофронтенды общаются через window.dispatchEvent и addEventListener, не зная друг о друге.
• URL и query-параметры — подходят для навигационного состояния, но не для чувствительных данных.
• Cookies и localStorage — удобны для токенов и профиля пользователя, доступны всем микрофронтендам на одном домене.
• Module Federation — позволяет шарить модули (в том числе стор и auth-сервис) между сборками.

Пример: общий auth-сервис через Custom Events

// shared/auth.js — публикуется host-приложением
const listeners = new Set();
let currentUser = null;

export const auth = {
  getUser: () => currentUser,
  setUser(user) {
    currentUser = user;
    window.dispatchEvent(new CustomEvent('auth:change', { detail: user }));
  },
  subscribe(cb) {
    listeners.add(cb);
    const handler = (e) => cb(e.detail);
    window.addEventListener('auth:change', handler);
    return () => {
      listeners.delete(cb);
      window.removeEventListener('auth:change', handler);
    };
  }
};

// microfrontend A
auth.subscribe(user => renderHeader(user));

// microfrontend B
auth.setUser({ id: 1, name: 'Ann' });

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

1. Определите единый контракт: какие поля и события шарятся между приложениями.
2. Не храните токены в localStorage, если есть риск XSS — предпочтительнее httpOnly cookies.
3. Используйте версионирование контракта, чтобы обновление одного микрофронтенда не ломало другие.
4. Для сложного состояния лучше выделить отдельный shared-пакет или Module Federation remote.

Итог: применять общий стор или Custom Events стоит, когда микрофронтенды должны реагировать на изменения пользователя и общее состояние; для простых случаев достаточно cookies и URL, а для крупных систем — выделенный shared-модуль с версионируемым контрактом.