Когда лучше использовать монолит вместо микросервисов
Что проверяют
Понимаете ли вы, что микросервисы и микрофронтенды решают прежде всего организационную задачу, и умеете ли назвать их цену. Фронтендеру следом обычно задают вопрос, стали бы вы делить приложение на микрофронтенды и что взяли бы вместо этого.
Как отвечать
Монолит, то есть одно приложение с одним репозиторием и одним деплоем, лучше, когда:
- команда небольшая: одна-две команды на одном домене не мешают друг другу, независимые релизы им не нужны;
- продукт на ранней стадии: границы модулей ещё не устоялись, а переносить код внутри одного репозитория дешевле, чем менять контракты между приложениями;
- важна производительность клиента: один бандл с общим React и дизайн-системой легче нескольких приложений, где зависимости легко задублировать;
- нужен единый опыт: общий роутинг, состояние, авторизация и стили без согласования версий между командами.
Цена микрофронтендов на Module Federation или single-spa вполне конкретная: конфликты версий общих библиотек, настройка shared синглтонов, сквозная авторизация и роутинг, отдельные CI и мониторинг на каждое приложение. Окупается это, когда несколько команд реально блокируют друг друга релизами.
Сильный ответ называет промежуточный вариант: модульный монолит. Монорепозиторий на Nx или Turborepo, слои по Feature-Sliced Design, границы между модулями, закреплённые правилами ESLint. Со стороны бэкенда похоже: фронтенду часто хватает одного BFF, даже если за ним десяток сервисов.
Где спотыкаются
Берут микрофронтенды для команды из четырёх человек «на вырост». Сложность приходит сразу, а польза только при масштабе, которого может и не случиться.
Считают монолит синонимом лапши. Плохая модульность после распила никуда не девается и превращается в распределённую лапшу с сетевыми вызовами.
Путают масштабирование нагрузки с масштабированием команды. Статику фронтенда и так раздаёт CDN, а монолитный бэкенд масштабируется горизонтально копиями за балансировщиком.