Корзина в headless Bitrix: пять проблем, которые нас удивили
Каталог мы отдали в Next.js за девять дней. Корзину интегрировали за месяц. Оформление заказа — ещё семь недель.
Как выносить витрину интернет-магазина на Next.js и оставлять каталог, корзину и обмен с 1С на Битриксе. Здесь разборы rewrite против поэтапной миграции, redirects, авторизации, синхронизации остатков и деплоя двух независимых частей.
35 статей
Каталог мы отдали в Next.js за девять дней. Корзину интегрировали за месяц. Оформление заказа — ещё семь недель.
Перед большим rewrite лучше проверить узкое место на малом участке: каталог, поиск, API, Core Web Vitals, SEO и интеграции.
Практичный разбор для founders и CTO: когда полный rewrite Bitrix/Laravel опасен, как staged modernization снижает риск и с чего начать discovery.
Rewrite редко начинается с архитектуры. Обычно он начинается с фразы: "текущий сайт уже невозможно развивать".
Фраза «нам нужен rewrite» почти никогда не описывает работу.
Когда мне показывают старый Bitrix, Laravel или самописный PHP-проект, первый импульс у бизнеса часто понятен: переписать на нормальный стек и забыть.
Когда ко мне приходят с вопросом «сколько стоит переписать Bitrix на нормальный стек», я почти никогда не отвечаю цифрой в первом сообщении.
Если проект уже болит, почти всегда хочется попросить у команды «оценку на весь rewrite». В таблице появляется 4–6 месяцев, список рисков, большой бюджет и ощущение контроля.
У founder или CTO обычно есть понятное желание: старый Bitrix/PHP-фронт мешает, команда устала от легаси, маркетинг хочет быстрые страницы, разработчики хотят Next.js. В этот момент легко назвать проект "rewrite" и сразу открыть новый репозиторий.
Я много пишу про Bitrix + Next.js, headless, Elasticsearch и аккуратную модернизацию старых e-commerce систем.
Когда ко мне приходят с фразой «хотим переписать 1С-Битрикс на Next.js», я не начинаю с цены.
Rewrite звучит приятно, когда legacy уже всем надоел.
Когда мы переводили каталог на 28 000 позиций в headless-архитектуру, первые две недели прошли в одном режиме. Открываешь метод Bitrix REST, смотришь на документацию — документация отстаёт от текущей версии месяца на три. Открываешь дебаггер, вызываешь метод, смотришь на реальный ответ. Делаешь вывод о форме. Пишешь интерфейс вручную. На следующий день коллега делает то же самое с другим методом — чуть иначе, чуть другие предположения.
У нас один PHP-бэкенд. Два Next.js-фронтенда. Два домена. Два бренда.
Клиент спрашивает: «Зачем нам headless, если Bitrix и так работает?»
Мы переехали на headless в феврале. В апреле SEO-специалист прислал выгрузку: 340 битых ссылок. Три года работавших редиректов. Ноль ошибок в логах — потому что Next.js не знал, что они вообще должны были существовать.
Мы запустили headless Bitrix + Next.js. LCP вырос — но не так, как ожидали.
Недавно мне написал клиент. Интернет-магазин, 30 тысяч SKU, Bitrix, «всё тормозит». Хотят уйти на headless. Я спросил: какой процент запросов превышает 2 секунды? Включён ли composite-режим? Смотрели slow_query_log за последние три месяца?
Когда мы перенесли каталог 28 000 товаров на Next.js, первые два дня после деплоя были про CSS и перфоманс. На третий день пришёл тикет: «Авторизованные пользователи видят форму входа вместо личного кабинета».
У нас было три склада, 28K SKU и обещание клиенту: остатки в реальном времени.
Планирование обновления Bitrix — это не то, о чём думают при запуске проекта. Думают об этом, когда в пятницу вечером приходит уведомление об окончании поддержки версии.
Я зашёл в проект с предубеждением.
Когда клиент говорит «переходим на headless», первый вопрос не «какой фреймворк». Первый вопрос: что вообще остаётся на Bitrix?
Первый вопрос, который мне задают про headless Bitrix, всегда про архитектуру. Второй — про деплой. Третий никто не задаёт вслух, но все спотыкаются об него на первой неделе: как вообще разрабатывать, если у тебя нет Bitrix на машине?
Когда клиент говорит «хотим headless», первое, что я спрашиваю — а что именно мы переносим?
Я провёл с Bitrix REST API больше времени, чем планировал. Не потому что API плохой. А потому что документация описывает синтаксис, но молчит про поведение.
Первая жалоба пришла на третий день после запуска headless. Менеджер обновил цену в Bitrix в 10:47. Покупатель положил товар в корзину в 11:20 — по старой цене. В Next.js была страница, закэшированная на один час.
Мы перешли на headless. Фронт стал деплоиться за 3 минуты. Бэк — нет.
Первый вопрос, который я задаю до любого КП: «Кто будет редактировать контент после нас — и на чём?»
За последние два года я трижды отговорил клиента от headless-миграции. Не потому что headless плохой — я люблю его строить и видел, что он даёт. А потому что ответы на пять вопросов делали результат очевидным ещё до того, как мы открывали Figma. В четвёртый раз ответы были другими, и проект получил полноценный Next.js + Bitrix на бэкенде. Сейчас это один из лучших ecom-проектов, с которыми я работал.
Один мой клиент пришёл с запросом: «Нам нужно переписать бэкенд. Он старый». Я спросил: «Что конкретно сломано?» Пауза. «Ну... он старый».
Три года назад клиент написал: нам нужно обновить Bitrix — нашли критическую уязвимость в модуле оплаты. Когда сможем?
Каждый третий разговор про Bitrix начинается с «он медленный». Я перестал спорить. Вместо этого прошу показать profiler.
Зимой мне позвонили с предложением, от которого не отказываются.
Rewrite — не всегда решение. Я модернизировал high-load e-commerce на 1С-Битрикс через Headless-подход: быстрее, безопаснее, без SEO-потерь. В статье — архитектура, риски, результаты и технический deep dive.