🫁 Микрофронтенды vs SPA: когда монолит перестаёт дышать
SPA (Single Page Application) — это классика. Один фронтенд-репозиторий, одна сборка, одна точка входа. Загрузился раз — и дальше роутинг живёт внутри браузера без перезагрузок. Всё просто и предсказуемо.
Microfrontends (Микрофронтенды) — это «микросервисы на клиенте». Большое приложение собирается из независимых модулей (виджетов/микро-приложений), каждый из которых может разрабатываться отдельной командой, на своей технологии и выкатываться по своему графику.
⚔️ SPA: плюсы и минусы
✅ Плюсы:
После загрузки — молниеносный роутинг
Один стек на всю команду — проще онбординг
Легко шарить утилиты, UI-кит, логику через общий код
Сборка и деплой — тривиальные (одна команда build)
❌ Минусы:
Первая загрузка может раздуваться до огромных размеров (бандл толстеет со временем)
Код превращается в монолит: страшно менять что-то в «старой» зоне, потому что непонятно, кто ещё это использует
Любое изменение — пересборка и перекат всего приложения целиком
Разные команды в одном репозитории начинают мешать друг другу (конфликты в package.json, разный стиль кода, очереди на деплой)
🧩 Микрофронтенды: плюсы и минусы
✅ Плюсы:
Команды полностью независимы: каждый сам решает, когда выкатывать фичу
Можно обновить один модуль без пересборки всего остального — деплой точечный
Технологическая свобода: команда А пишет на React, команда Б — на Vue, команда В — на Angular (и это реально работает через Module Federation или Single-SPA)
Масштабирование разработки: 10+ команд работают параллельно, не наступая друг другу на пятки
❌ Минусы:
Инфраструктура резко усложняется: нужна сборщица (оркестратор), которая склеивает части в рантайме
Дублирование кода — общая боль. Каждый модуль тащит свою копию React, свои стили, свои утилиты, если не настроить разделение зависимостей
Роутинг и общее состояние (например, корзина в маркетплейсе) требуют отдельной архитектуры, которую надо продумывать с нуля
Высокий порог входа: новому разработчику надо понять, как работают 5 модулей, а не один монолит
🎯 Когда что выбирать
SPA подходит, если:
➖ Команда до 10–15 человек
➖ Приложение не разбито на жёсткие доменные зоны
➖ Вы не переживаете, что не сможете обновить часть без переката всего
➖ Хотите быстро стартовать и минимизировать инфраструктурные затраты
Микрофронтенды оправданы, если:
➖ Команда более 20 разработчиков (или активно растёт)
➖ У приложения есть чёткие домены: каталог, корзина, личный кабинет, админка
➖ Разные команды хотят быть независимыми в выборе технологий и графиков релизов
➖ Это Enterprise, где части продукта могут развиваться разными темпами
Классический пример:
Веб-версия маркетплейса. Команда «Каталог» пишет на React, команда «Корзина» — на Vue, команда «Личный кабинет» — на Angular. Все три собираются в одну страницу через Webpack Module Federation или Single-SPA. Пользователь видит единый сайт, а внутри — модули от разных команд.
🎓 Моё резюме
Микрофронтенды — это не про «круто», а про «больно, но надо, когда выросли». Это те же микросервисы, только на фронте: та же независимость и та же головная боль с инфраструктурой.
Мой совет: не начинайте с микрофронтов. Начните с хорошего SPA-монолита. Используйте правильную архитектуру внутри (FSD, модули, чёткие слои). Когда монолит начнёт душить вас организационно — тогда и задумайтесь о разделении.
А у вас что за проект? SPA или уже микрофронтенды? Если делите — как именно? В рантайме или на сборке? 👇
#Термины #Архитектура
SPA (Single Page Application) — это классика. Один фронтенд-репозиторий, одна сборка, одна точка входа. Загрузился раз — и дальше роутинг живёт внутри браузера без перезагрузок. Всё просто и предсказуемо.
Microfrontends (Микрофронтенды) — это «микросервисы на клиенте». Большое приложение собирается из независимых модулей (виджетов/микро-приложений), каждый из которых может разрабатываться отдельной командой, на своей технологии и выкатываться по своему графику.
⚔️ SPA: плюсы и минусы
✅ Плюсы:
После загрузки — молниеносный роутинг
Один стек на всю команду — проще онбординг
Легко шарить утилиты, UI-кит, логику через общий код
Сборка и деплой — тривиальные (одна команда build)
❌ Минусы:
Первая загрузка может раздуваться до огромных размеров (бандл толстеет со временем)
Код превращается в монолит: страшно менять что-то в «старой» зоне, потому что непонятно, кто ещё это использует
Любое изменение — пересборка и перекат всего приложения целиком
Разные команды в одном репозитории начинают мешать друг другу (конфликты в package.json, разный стиль кода, очереди на деплой)
🧩 Микрофронтенды: плюсы и минусы
✅ Плюсы:
Команды полностью независимы: каждый сам решает, когда выкатывать фичу
Можно обновить один модуль без пересборки всего остального — деплой точечный
Технологическая свобода: команда А пишет на React, команда Б — на Vue, команда В — на Angular (и это реально работает через Module Federation или Single-SPA)
Масштабирование разработки: 10+ команд работают параллельно, не наступая друг другу на пятки
❌ Минусы:
Инфраструктура резко усложняется: нужна сборщица (оркестратор), которая склеивает части в рантайме
Дублирование кода — общая боль. Каждый модуль тащит свою копию React, свои стили, свои утилиты, если не настроить разделение зависимостей
Роутинг и общее состояние (например, корзина в маркетплейсе) требуют отдельной архитектуры, которую надо продумывать с нуля
Высокий порог входа: новому разработчику надо понять, как работают 5 модулей, а не один монолит
🎯 Когда что выбирать
SPA подходит, если:
➖ Команда до 10–15 человек
➖ Приложение не разбито на жёсткие доменные зоны
➖ Вы не переживаете, что не сможете обновить часть без переката всего
➖ Хотите быстро стартовать и минимизировать инфраструктурные затраты
Микрофронтенды оправданы, если:
➖ Команда более 20 разработчиков (или активно растёт)
➖ У приложения есть чёткие домены: каталог, корзина, личный кабинет, админка
➖ Разные команды хотят быть независимыми в выборе технологий и графиков релизов
➖ Это Enterprise, где части продукта могут развиваться разными темпами
Классический пример:
Веб-версия маркетплейса. Команда «Каталог» пишет на React, команда «Корзина» — на Vue, команда «Личный кабинет» — на Angular. Все три собираются в одну страницу через Webpack Module Federation или Single-SPA. Пользователь видит единый сайт, а внутри — модули от разных команд.
🎓 Моё резюме
Микрофронтенды — это не про «круто», а про «больно, но надо, когда выросли». Это те же микросервисы, только на фронте: та же независимость и та же головная боль с инфраструктурой.
Мой совет: не начинайте с микрофронтов. Начните с хорошего SPA-монолита. Используйте правильную архитектуру внутри (FSD, модули, чёткие слои). Когда монолит начнёт душить вас организационно — тогда и задумайтесь о разделении.
А у вас что за проект? SPA или уже микрофронтенды? Если делите — как именно? В рантайме или на сборке? 👇
#Термины #Архитектура