теория

Монолит в браузере

Терминал прошёл путь ядра «Ярмарки», только быстрее: год назад — три экрана, сегодня — продукт трёх команд, и четвёртая уже выходит из отпусков перед стартом. И у него те же болезни роста, что были у бэкенда в первом акте, потому что болезни эти не про язык программирования, а про знание без границ.

Фронтенд-монолит — это одно приложение, которое собирают все и деплоят разом. Сам по себе он не проблема — как не был проблемой монолит Гены: для одной-двух команд это самая дешёвая и быстрая форма жизни. Проблемы начинаются, когда за одним рулём оказывается несколько экипажей:

  • Релизный поезд: все едут по расписанию самого медленного. Красный тест одной команды держит вагоны всех.
  • Общее состояние без хозяев: стор, в который два года складывали все, — общая таблица из первого акта. Кто читает моё поле? Неизвестно. Что сломает моё переименование? Узнаем в проде.
  • Очередь на общие места: роутинг, шапка, дизайн-токены — меняются всеми, принадлежат никому.

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

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

← назад