Headless-Битрикс: зачем превращать CMS в бэкенд для Next.js

Что такое headless на самом деле

Обычная CMS — это «голова и тело в одном флаконе»: тело хранит данные (товары, статьи, пользователей) и логику, голова — рисует из них HTML-страницы. Запросил URL — Битрикс сходил в базу, прогнал данные через компоненты и шаблоны, вернул готовую страницу. Публичная отрисовка и бэкенд намертво сцеплены.

Headless буквально значит «без головы» — без встроенной публичной части, которая рисует страницы. Тело остаётся: данные, админка, бизнес-логика. Наружу система отдаёт не HTML, а чистые данные — обычно JSON через API. А голову — то, как это показать пользователю — строит уже другой клиент: SPA, мобильное приложение, телевизор, или, как у меня, фронтенд на Next.js.

Как Битрикс становится headless

В «Дорогом друге» схема такая:

• Битрикс хранит данные (питомцы, объявления, города как highload-справочник) и даёт контент-редактору привычную админку. Это его сильная сторона — нет смысла переписывать её на коленке.
• Поверх него живёт свой модуль app.api с контроллерами на Bitrix\Main\Engine\Controller, которые отдают JSON по версионированному адресу /api/v1/... в едином конверте { data, meta, errors }.
• Next.js ходит в этот API, рендерит страницы на сервере (SSR/ISR) и отдаёт их браузеру и поисковику. То есть Битрикс работает «головой вниз»: вся его мощь — в данных и управлении, а лицо проекту делает фронтенд.

        Браузер  ──>  Next.js (SSR/ISR)  ──>  /api/v1/*  ──>  Битрикс (данные + админка)

    

Что на этом выигрываешь

Свобода фронтенда. Это главное. Современный UX, анимации, мгновенные переходы, переиспользование одного API для сайта и будущего мобильного приложения — всё это в мире штатных компонентов и шаблонов Битрикса даётся болью.

Чёткая граница ответственности. Бэкенд отвечает за данные и бизнес-логику, фронтенд — за отображение. Их можно разрабатывать, тестировать и катить относительно независимо. Контракт между ними — это API, а не клубок компонентного кода.

Производительность и масштабирование по отдельности. Тяжёлую отрисовку и кэш держит фронтенд (ISR — отдаёт статику и тихо обновляет её в фоне), а Битрикс занимается своим делом — данными. Нагрузку на каждый слой можно лечить отдельно.

Битрикс остаётся знакомым редактору. Контент-менеджер работает в той же админке, что и всегда. Для бизнеса это огромный плюс: не надо переучивать людей и строить свою CMS с нуля.

Что теряешь

Ты добровольно отказываешься от половины того, за что платишь. Готовые публичные компоненты, штатные шаблоны, urlrewrite-магия, композитный кэш «из коробки» — всё это в headless ты не используешь и строишь публичную часть сам. Отсюда первый вопрос скептиков, и он честный: оправдан ли Битрикс, если берёшь от него только данные и админку. Моё мнение — да, ради сильной админки и привычного стека.

Сложность переезжает в стык. Появляется целый слой, которого в монолите нет: API-контракт, версии, CORS, аутентификация между фронтом и бэком, согласование форматов ошибок. Это не сложнее монолита, но это другая сложность, и про неё легко забыть на старте.

SEO становится твоей заботой. В монолите Битрикс отдаёт готовый HTML, и поисковику хорошо. Уводя рендер на фронт, ты обязан рендерить на сервере (SSR/ISR), а не лепить чистый SPA — иначе поисковик увидит пустую страницу. Для контентного портала это вопрос жизни и смерти.

Двойная инфраструктура. Теперь у тебя два приложения, два деплоя, два места, где что-то падает. Соло-разработчику — это ощутимый налог.

Кому headless НЕ нужен

Прямо скажу, чтобы никого не утащить за собой зря. Если это визитка, лендинг или классический корпоративный сайт на пару десятков страниц — берите обычный Битрикс и не выдумывайте. Штатные компоненты соберут такое за вечер, а headless только добавит вам два приложения и слой API на ровном месте.

Headless начинает окупаться, когда: фронтенд реально сложный и интерактивный; один и тот же контент нужен нескольким клиентам (веб + мобайл); команда фронта хочет работать на своём стеке независимо; или, как в моём случае, это осознанная архитектурная ставка на годы вперёд, а не на «запуститься к пятнице».