Что мы оставили на Bitrix, когда перешли на headless: честный список с reasoning

Когда клиент говорит «переходим на headless», первый вопрос не «какой фреймворк». Первый вопрос: что вообще остаётся на Bitrix?

На проекте с 28 000 SKU мы три месяца принимали эти решения. Часть оказалась очевидной. Checkout не переписывали, хотя могли. Авторизация осталась на Bitrix-шаблонах. Ценообразование тоже. Каталог ушёл на Elasticsearch в первую неделю.

Попробую разложить то, что мы сделали и почему. Без маркетинга про «современную архитектуру».

Почему граница важнее, чем выбор фреймворка

Большинство разговоров про headless Bitrix застревают на уровне «Next.js vs Nuxt» или «стоит ли вообще». Я видел проекты, где выбрали правильный фреймворк и неправильно разрезали систему. Итог — два года интеграционного ада.

Граница — ответ на вопрос: за что отвечает Bitrix, за что Next.js, где они пересекаются и как минимизировать эти пересечения.

На нашем проекте мы пришли к простому правилу: Bitrix держит данные и деньги. Next.js — рендеринг и UX. Elasticsearch — поиск и фильтрацию. Разобрать, почему именно такое распределение ответственности — в статье php-earns-money-nextjs-shows-it.

Звучит как трюизм. Но из него вышли нетривиальные решения.

Что всегда остаётся на Bitrix

Ценообразование и скидки — там. Bitrix хранит цены, персональные скидки, акции, купоны. Выносить это в отдельный сервис на раннем этапе — значит дублировать логику расчёта скидок, которую Bitrix уже умеет считать. Мы оставили ценообразование там, где оно было.

Синхронизация с 1C — там. Bitrix Exchange — черный ящик с хорошей историей. Товары, остатки, цены приходят в Bitrix, и уже оттуда вы забираете их через REST API. Не трогайте этот слой без причины.

Заказы, корзина, авторизация — там. Функционал написан и протестирован на тысячах магазинов. На нашем проекте личный кабинет живёт на старых Bitrix-шаблонах. LCP там 2.8 секунды, зато он работает и никто его не трогает год.

Если это делает деньги или хранит деньги — оставляйте на Bitrix.

Что уходит первым: каталог и поиск

На странице категории с 28 000 SKU Bitrix генерировал 40 SQL-запросов. Это были живые фасеты — каждый рендер пересчитывал доступные фильтры для текущей выборки. При 50 одновременных пользователях сервер начинал дышать тяжело.

Каталог уехал на Elasticsearch в первые две недели.

Почему именно он? Потому что это та часть, где скорость напрямую влияет на конверсию. LCP на страницах категорий: 4.2 секунды до, 1.4 секунды после. Конверсия на мобайле выросла на 23%.

Фасеты стали результатами агрегаций Elasticsearch. Один запрос вместо 40 SQL. Индексер обновляет данные каждые 15 минут через Bitrix REST API.

Каталог, поиск, фасетная фильтрация — первые кандидаты на переезд в любом headless Bitrix-проекте.

Серая зона: checkout и личный кабинет

Здесь мы приняли решение, которое кажется непоследовательным.

Checkout работает на старых Bitrix-шаблонах. Не на Next.js.

Почему? Потому что checkout конвертировал. 3.8% визитов в заказ. Он не тормозил — там нет тяжёлых запросов, только форма. И он уже был интегрирован с платёжными системами, СМС-подтверждением, 1C.

Переписывать рабочий checkout ради архитектурной чистоты — 2-3 месяца работы за ноль прироста конверсии. Мы потратили их на каталог.

Прежде чем включать что-то в headless-периметр, спросите: за чем туда приходят пользователи и насколько часто. Если редко и не для SEO, оставьте на Bitrix.

Как выглядит REST API, когда он единственный канал данных

В нашей архитектуре Next.js не ходит напрямую в базу. Только через Bitrix REST API.

Это означает: всё, что нужно получить на фронтенде — продукты, цены, остатки, пользователя — должно быть доступно через API. Если endpoint не настроен, данных нет.

На старте у нас было 12 основных endpoint'ов: список товаров с фасетами, карточка товара, поиск, категории, корзина (read-only), пользователь, заказы, промо-баннеры, меню, контент страниц, остатки по складам, перекрёстные продажи.

Каждый endpoint мы описывали в контракте до написания фронтового кода. Сэкономило несколько итераций переработки. Конкретные сюрпризы Bitrix REST API на реальном проекте — в статье bitrix-rest-api-headless-surprises.

Если endpoint возвращает 1.8 секунды — это проблема бэкенда, не фронтенда. Не оптимизируйте следствие.

Три решения, которые сделал бы иначе

Начал бы с аудита endpoint'ов, а не с настройки Next.js. Мы потеряли две недели, потому что фронтенд был готов раньше, чем API.

Ввёл бы feature-flags с первого дня. Мы переключались между старым фронтом и новым вручную через nginx-конфиг. При откате — больно.

Определил бы формат ошибок API заранее. Bitrix REST возвращает ошибки в нестандартном формате. Мы унифицировали это на третьем месяце, когда у фронта уже было 40 разных способов обрабатывать ошибки. Сорок.

Ни одна из этих проблем не была критической. Но каждая стоила времени.

Итог

Headless Bitrix работает. Но «работает» — это не «перенесли всё на Next.js». Это «правильно разрезали систему».

Bitrix держит деньги и данные. Next.js рендерит. Elasticsearch ищет. Всё, что не вписывается в эту схему, — повод задать вопрос, а не повод писать код.

Граница важнее фреймворка.