Микрофронты в банке: архитектура, за которую платят дорого

Это было большое банковское приложение, которое в итоге грузило 15 микрофронтов.
Несколько команд, разные домены, независимые релизы классика для MFE.

На старте всё выглядело красиво на схеме.
А в реальности сложности начались почти сразу.

Первое — общие зависимости.
UI Kit должен быть единым, но обновляться безопасно.

shared: {
  react: { singleton: true },
  '@bank/ui-kit': { singleton: true }
}

Второе — общение между микрофронтами.
Прямые импорты запрещены, global state — риск.

Мы сделали отдельный пакет в Nexus npm, который выступал контрактом:

// @bank/mf-bridge
export const events = createEventBus();

events.emit('user:logout');
events.on('user:updated', handler);

Этот пакет обновлялся отдельно и жёстко контролировался.

Главное открытие — микрофронты ломаются не из-за кода,
а из-за отсутствия правил и границ ответственности.

Именно такой реальный опыт я разбираю на интенсиве по микрофронтам:
архитектура, контракты, ошибки и решения из продакшена.

Если хочешь понять, как это делают в больших продуктах:
Смотри
👉ПРОБНЫЙ УРОК

👉 Узнать детальнее в лс

ПОЛУЧИТЬ ДОСТУП