Архитектура микрофронтендов: как избежать конфликтов версий и зависимости от единого инжектора

Суть: единый инжектор как бомба замедленного действия

Подход был прямолинейный: Angular во всех командах, платформа делится на `platform.js` (ядро) и `vendor.js` (фреймворк и зависимости). В рантайме через SystemJS всё это компилировалось, роуты мержились, инжектор собирался в единый объект. Команды получали «независимость» — свои релизы, свои сроки. Клиент — расширяемый дашборд с виджетами. На словах — микрофронтенд. На деле — жёсткая связка через общую версию фреймворка.

Проблема вскрылась сразу, как только одна из команд попёрла вперёд и обновилась. Всё развалилось. Платформа требовала Angular X, а модуль — Angular Y. Начались «синхронные релизы», где команда платформы ходила к продуктам с просьбой обновиться — и получала отказ. У каждого свои спринты, свой прод, свой дедлайн. Классика: чтобы починить чужой модуль, тебе надо сначала договориться с чужой командой, потом с их бизнесом, а потом ещё и в тестинг не сломать ничего. Идеальный рецепт для конфликтов и простоев.

Практика: что делать, если вы уже в ловушке

Первый шаг — признать, что «разрезанный монолит» — это не микрофронтенд. Это просто модульный монолит. Если у вас единый `node_modules`, общие сервисы и общий билд-пайплайн — вы всё ещё в связке. Вывод из истории прост: изоляция должна быть на уровне процесса и контракта, а не на уровне папки в репозитории.

Для старта проверьте:

1. Версии ключевых зависимостей (React, Angular, Vue) у всех команд. Если не совпадают — у вас уже есть точка отказа.

2. Как происходит сборка. Если один командный `webpack.config.js` — вы в группе риска.

3. Каналы связи между приложениями. Общий store или глобальные event bus’ы — это не интеграция, это свидание с катастрофой.

# Быстрая проверка здоровья вашего «микрофронтенда»
grep -r "angular" /apps/*/package.json | grep version
grep -r "react" /apps/*/package.json | grep version
grep -r "vue" /apps/*/package.json | grep version

Если вывод показывает разброс — поздравляю, у вас ровно та проблема, с которой столкнулись в InfoWatch. Бэкапы делаете? Нет? А зря.

Контекст: почему это важно для ниши

Микрофронтенды — не серебряная пуля, а архитектурный trade-off. Тот пост на Хабре — отличный кейс, как не надо. Начинать интеграцию нескольких SPA стоит не с выбора фреймворка, а с протокола взаимодействия. Идеально — через Custom Elements и Web Components. Иначе получаете то, что описано: скорость релизов одного продукта блокируется скоростью релизов другого.

Для lawebbox-а вывод один: если вы проектируете архитектуру для нескольких команд, изоляция через iframe или Shadow DOM — не костыль, а спасательный круг. Да, overhead на общение между приложениями есть, но вы платите его на этапе интеграции, а не в 3 часа ночи, когда падает прод.

В следующей части, видимо, будут разбирать решение. Но пока — вывод: если ваша «независимая» команда не может обновить библиотеку, не спрашивая разрешения у остальных, у вас нет микрофронтенда. У вас есть бюрократия на уровне зависимостей. Делайте бэкапы.