Меня зовут Максим, я веб-разработчик. В 2024 году ко мне пришла крупная сеть мебельных салонов с проблемой: их сайт на Битриксе не справлялся. Загрузка каталога из 8 000 товаров — 6 секунд. Добавить новую функцию (калькулятор кухни) — 3 месяца работы разработчиков, потому что Битрикс цеплялся за каждое изменение. Обновить дизайн — значит переверстать всё, потому что шаблон «вшит» в CMS. Миграция на новую версию — рискованная операция на неделю. Мы перестроили сайт на composable-архитектуре: Next.js на фронтенде, Strapi как headless CMS, отдельный сервис каталога, отдельный сервис поиска. Результат: загрузка — 1,4 секунды, новая функция — 2–3 недели, обновление дизайна — без затрагивания бэкенда. Расскажу, что такое MACH-архитектура и когда она оправдана.

Что такое MACH и composable

MACH — это аббревиатура:

  • Microservices — микросервисная архитектура
  • API-first — все компоненты общаются через API
  • Cloud-native — облачная инфраструктура
  • Headless — фронтенд отделён от бэкенда

Composable-архитектура — это подход, при котором вы собираете сайт из отдельных, независимых компонентов (сервисов), как из кубиков Лего. Вместо одной монолитной CMS, которая «умеет всё» (но каждое «всё» — посредственно), вы выбираете лучший инструмент для каждой задачи:

  • CMS — для управления контентом (Strapi, Directus, Sanity)
  • Поиск — отдельный сервис (Algolia, Meilisearch, Elasticsearch)
  • E-commerce — отдельный движок (Medusa, Saleor)
  • Авторизация — отдельный сервис (Keycloak, Auth0)
  • Email — отдельный сервис (Resend, Unisender)
  • Аналитика — отдельный сервис (Яндекс Метрика, собственный трекинг)

Каждый компонент делает одну вещь — но делает её хорошо. Все общаются через API. Фронтенд (Next.js, Nuxt, Astro) собирает данные из всех сервисов и рендерит единую страницу.

Монолит vs Composable: в чём разница

Монолитная CMS (Битрикс, WordPress, MODX)

Одна система содержит всё: контент, каталог, корзину, поиск, авторизацию, шаблоны, админку. Плюсы: всё в одном месте, легко начать, много готовых решений. Минусы:

Связанность. Изменение одного компонента может сломать другой. Обновление CMS может потребовать переделки шаблонов.

Производительность. Монолит генерирует HTML на сервере при каждом запросе, часто — медленно. Кэширование помогает, но добавляет сложность.

Масштабирование. Под нагрузкой нужно масштабировать весь монолит, а не только «узкое место» (обычно это каталог или поиск).

Vendor lock-in. Решили перейти с Битрикса на что-то другое? Удачи — контент, логика, шаблоны, интеграции — всё привязано к конкретной CMS.

Composable-архитектура

Каждый компонент — независимый сервис. Плюсы:

Независимость. Можно заменить CMS, не трогая каталог. Обновить поисковый движок, не затрагивая контент. Изменить фронтенд, не меняя бэкенд.

Производительность. Каждый сервис оптимизирован под свою задачу. Поиск — на Elasticsearch (миллисекунды). Контент — статически генерируется (мгновенно). Каталог — кэшируется на edge.

Масштабирование. Нагрузка на поиск выросла? Масштабируем только поисковый сервис. Остальные — не трогаем.

Свобода выбора. Для каждой задачи — лучший инструмент. Не «лучший из того, что умеет наша CMS», а лучший на рынке.

Минусы composable:

Сложность. Больше компонентов = больше точек отказа, больше интеграций, больше DevOps.

Стоимость. Начальная разработка дороже, чем настройка монолитной CMS. Нужна квалификация.

Overhead для маленьких проектов. Для сайта-визитки из 5 страниц — composable это из пушки по воробьям.

Когда переходить на composable

Стоит перейти, если:

  • Ваш сайт «вырос» из монолитной CMS (тормозит, невозможно добавлять функции)
  • Каталог >1 000 товаров с фильтрами и поиском
  • Нужна гибкая персонализация, A/B-тесты, мультиканальность
  • Планируете быстро развивать сайт (новые функции каждый месяц)
  • Команда разработки >2 человек (параллельная работа над разными сервисами)

Не стоит, если:

  • Сайт-визитка или простой корпоративный сайт (5–20 страниц)
  • Нет команды разработки для поддержки
  • Бюджет ограничен (до 300 тысяч рублей)
  • Функциональность стандартная (блог + каталог без сложной логики)

Как я строю composable-сайты

Типичный стек

Фронтенд: Next.js. SSR/SSG, React-компоненты, TypeScript. Общается со всеми бэкенд-сервисами через API.

CMS: Strapi или Directus. Headless CMS — контент-менеджер создаёт страницы, статьи, баннеры через удобную админку. Отдаёт данные через REST или GraphQL API.

Каталог: собственный сервис или Medusa. Для e-commerce — отдельный сервис с товарами, ценами, остатками. Интеграция с 1С. Для несложных каталогов — данные в Strapi.

Поиск: Meilisearch или Elasticsearch. Автодополнение, фасетные фильтры, тайповые подсказки — за миллисекунды. Индекс обновляется автоматически при изменении товаров в каталоге.

Авторизация: встроенная в Next.js (NextAuth) или Keycloak. Для простых случаев — NextAuth с провайдерами (email, телефон, Яндекс ID). Для корпоративных порталов — Keycloak с SSO.

Хостинг: Vercel или Яндекс Cloud. Vercel — идеален для Next.js (автоматический деплой, edge-функции, CDN). Яндекс Cloud — для проектов с требованием локализации данных в РФ.

Пример архитектуры: мебельная сеть

[Посетитель] → [CDN/Edge] → [Next.js фронтенд]
                                    ↓
                    ┌───────────────┼───────────────┐
                    ↓               ↓               ↓
              [Strapi CMS]   [Каталог API]   [Meilisearch]
              (страницы,      (товары,        (поиск,
               блог,          цены,           фильтры)
               баннеры)       остатки)
                                    ↓
                              [1С (склад,
                               бухгалтерия)]

Каждый блок — независимый сервис. Strapi упал? Каталог продолжает работать. Meilisearch перегружен? Страницы и товары отображаются нормально, просто поиск временно медленнее.

Миграция с монолита на composable

Не нужно переписывать всё сразу. Я использую стратегию «Strangler Fig Pattern» — постепенное замещение:

Этап 1. Новый фронтенд (Next.js) рядом со старым сайтом. Часть страниц обслуживается новым фронтом, часть — старым. Переключение через reverse proxy (nginx).

Этап 2. Перенос контента в headless CMS. Старая CMS остаётся как источник данных для тех страниц, которые ещё не мигрировали.

Этап 3. Перенос каталога в отдельный сервис. Интеграция с 1С — через новый API.

Этап 4. Перенос поиска на Meilisearch. Выключение старой CMS.

Каждый этап — самостоятельный релиз. Никакого «Большого Перезапуска» — постепенная замена компонентов.

Стоимость

Composable-сайт с нуля (Next.js + Strapi + поиск + каталог). Для среднего e-commerce (1 000–10 000 товаров). Срок: 3–5 месяцев. Бюджет: 1,5–3,5 миллиона рублей.

Миграция с монолита (поэтапная). Срок: 4–8 месяцев. Бюджет: 1–3 миллиона рублей.

Поддержка composable-сайта. 60–150 тысяч рублей в месяц. Дороже, чем монолит — но и возможностей больше.

Для сравнения: поддержка монолитного Битрикс-сайта из 8 000 товаров стоила клиенту 120 тысяч в месяц (при постоянных проблемах с производительностью). Composable-версия — 90 тысяч в месяц, при этом работает в 4 раза быстрее и позволяет добавлять функции в разы оперативнее.

Если ваш сайт перерос монолитную CMS — обращайтесь.