← Назад в блог

Headless — это не про скорость. Это про то, чтобы Bitrix не ронял фронт.

Три года назад клиент написал: нам нужно обновить Bitrix — нашли критическую уязвимость в модуле оплаты. Когда сможем?

С монолитом ответ был бы: «Надо заморозить фронт, поднять тестовую среду, прогнать регрессию — недели две». С headless мы ответили: «Обновляем бэкенд сегодня. Фронт не трогаем».

Это и есть главный аргумент за headless. Не LCP. Не «современный стек». Независимость деплоя.

Deploy coupling: что это и почему это больно

В монолите фронт и CMS — одна живая система. HTML генерируется на сервере Bitrix. Шаблоны — PHP-файлы в том же репозитории, что и бизнес-логика. Обновили ядро Bitrix — могли сломать шаблон. Добавили PHP-зависимость — могли затронуть верстку. Стянули хотфикс в продакшн ночью — разбудили фронт-разработчика, потому что «что-то поехало».

Это называется deploy coupling. Фронт и бэкенд деплоятся вместе, рискуют вместе, падают вместе.

Для небольших команд это часто незаметно: один разработчик, одна среда, одна ответственность. Но как только появляется специализация — фронт, бэкенд, CMS-администратор, — deploy coupling начинает создавать накладные расходы. Обновление безопасности ждёт, пока освободится фронт-разработчик. Новый UI-компонент стоит, пока бэкенд-разработчик не протестирует «как это всё сработает вместе».

Самое неприятное: эта зависимость не видна в задачах, она живёт в риске. «Обновим после спринта» — это не тимлид тянет, это боязнь задеть работающий фронт.

Как headless разрывает coupling

В headless-архитектуре фронт и бэкенд деплоятся независимо. Next.js-приложение живёт отдельно — на Vercel, PM2, собственном сервере — и читает данные из Bitrix через REST API. Bitrix по-прежнему держит каталог, заказы, пользователей, правила цен, интеграции с 1С. Next.js рендерит страницы, управляет SEO, обрабатывает UX.

Ключевое: между ними — контракт. Bitrix отдаёт JSON через /api/ivanpin/catalog/items/, /api/ivanpin/orders/, и так далее. Пока этот контракт не меняется — бэкенд и фронт могут обновляться независимо.

Обновление Bitrix? Фронт не знает. Редизайн каталога на Next.js? Bitrix не знает. Патч безопасности в PHP-ядре? Фронт продолжает работать, пока бэкенд уходит на перезагрузку.

Это не теория. Я развернул такую схему на реальном магазине с 28 000 SKU — тот же проект, где 40 SQL-запросов на страницу превратились в один запрос к Elasticsearch. Там же мы обновляли Bitrix трижды без единого фронтового регресса. Каждый раз: бэкенд обновляем, кэш сбрасываем, фронт продолжает работать.

Как это выглядит на практике

Конкретный сценарий — Bitrix выпускает обновление безопасности. В монолите последовательность такая: заморозить деплои на фронте, поднять копию продакшна для тестирования, запустить обновление, прогнать регрессию на вёрстке, задеплоить. Минимум неделя, если нет автотестов.

В headless-схеме: разворачиваем обновление на бэкенде через скрипт deploy_ivanpin_api.py, который деплоит только PHP-эндпоинты и перезапускает PHP-FPM. Next.js-приложение не трогаем. Пользователи ничего не видят. Весь процесс — 20 минут.

Или обратный сценарий: нужно срочно изменить логику фильтрации в каталоге. Фронт-разработчик пушит изменения в Next.js, Vercel деплоит за 2 минуты. Bitrix не трогаем. Бэкенд-разработчик не нужен.

Это операционная независимость. Каждый деплоит в своём ритме. Не ждёт другого. Не рискует чужим кодом.

Где независимость деплоя не работает

Есть ситуации, где decoupling создаёт больше проблем, чем решает.

Первое — API-контракт. Это и преимущество, и риск. Если Bitrix поменял структуру ответа — Next.js упадёт при следующем запросе. Нужно версионирование API или заморозка контракта. В монолите этой проблемы нет: всё в одном репозитории, компилятор (или CodeSniffer) поймает сразу.

Второе — локальная разработка. Раньше поднял один Docker-контейнер — готово. Теперь нужно поднять Bitrix, запустить Next.js, убедиться, что они говорят друг с другом. Решаемо через docker-compose и правильно прописанные переменные окружения, но это дополнительная сложность.

Третье — команда из одного человека. Если один разработчик поддерживает и фронт, и бэкенд, deploy coupling не его проблема. Проблема появляется, когда команда растёт или когда фронт и бэкенд обновляются с разной частотой.

Стоит ли это headless?

Четыре вопроса, которые я задаю перед тем как рекомендовать headless:

  1. Как часто обновляется бэкенд? Если раз в год — deploy coupling не боль. Если каждые 2–3 недели патчи — боль настоящая.
  2. Есть ли специализация в команде? Если фронт и бэкенд — разные люди, они уже молча ждут друг друга при каждом деплое.
  3. Насколько стабилен API-контракт? Если Bitrix-структура постоянно меняется — версионирование API добавит сложности, которая съест выигрыш.
  4. Есть ли локальная среда для обеих частей? Без нормального docker-compose разработчики будут отлаживать в продакшне.

Если на первые два вопроса ответ «да» — headless, скорее всего, оправдан. Не ради LCP. Ради того, что Bitrix и Next.js больше не ждут разрешения друг друга на деплой.

Итог

Headless не решает всё. Но deploy coupling он решает лучше монолита — это конкретная, измеримая проблема с конкретным решением. Скорость, SEO, DX — это следствие. Причина другая.

Если вам когда-нибудь приходилось замораживать фронт ради патча в Bitrix — вы уже знаете, что это такое. Headless убирает это ожидание.

*Если интересно, как выглядит граница между Bitrix API и Next.js в реальном проекте — написал подробнее в статье про рефакторинг вместо переписывания.*