Битрикс API, чтобы фронт работал без бэкендера
Основная часть нашей разработки — на 1С-Битрикс, и раздельный фронтенд и бэкенд увеличивают смету. Я рассказываю, как мы делаем модуль с готовым REST API для Битрикса: фронтенд-разработчик сам создаёт инфоблоки и пишет фронт на React или Vue, а с Next.js или Nuxt сайт готов к SEO.
И мы уже давно привыкли к раздельному фронтенду и бэкенду. Что увеличивает смету для клиента.
Вдохновившись одной из команд, где фронты собирают без бэкендеров сайты на Strapi, решили разработать модуль, который позволит фронтам без бэкенда разрабатывать проекты на 1С-Битрикс.
REST API для Битрикса без бэкендера
Готовое и настраиваемое REST API, со всеми необходимыми методами. Фронту останется создать структуру инфоблоков и сделать фронтенд на React / Vue.
В итоге смета для клиента получается меньше, так как бекендер не участвует. Сайт полностью готов для SEO, если делать на Next.js / Nuxt. Фронты занимаются интересными технологиями, бэкендер не тратит время на написание 10-ый раз очередного API.
Знаю, что готовых решений для API битрикса — несколько, мы все изучаем, чтобы не изобрести велосипед.
Открытый модуль Битрикс API
Решение собираемся сделать opensource и бесплатным, чтобы нормальная и современная разработка на Битриксе была повсеместной.
Сейчас набираем рабочую группу тех, кто пишет на Битрикс API или фронтовые команды, которым хочется, чтобы API были удобными. Уже есть 3 участника. Участников отметим в соавторах. Кто хочет поучаствовать — пишите @altoivan.
Кто не хочет, но одобряет — поддержите лайком.
Как устроен headless-подход на 1С-Битрикс
Headless — это когда CMS хранит данные и отдаёт их по API, а интерфейс живёт отдельно. Битрикс в такой схеме остаётся админкой для контент-менеджеров: каталог, инфоблоки, заказы, пользователи. Сайт рендерит фронтенд на Next.js или Nuxt и обращается к Битриксу за данными.
Так устроены Strapi, Directus и другие headless CMS. Разница в том, что Битрикс уже стоит у тысяч компаний и привычен их сотрудникам.
Инфоблоки как модель данных
Инфоблок в Битриксе — универсальная таблица с разделами, элементами и свойствами. Через него описывают каталог, новости, баннеры, отзывы, магазины. Для API это удобно: структура данных задаётся в админке, без миграций и кода. Фронтендер создаёт инфоблок, заводит свойства, и они сразу доступны в ответе.
Что отдаёт API
Обычно это JSON с полями элемента, свойствами, ссылками на изображения и SEO-метаданными. Для списков — пагинация, сортировка и фильтры по свойствам. Чтобы не нагружать базу, ответы кешируют: в Битриксе для этого есть управляемый и тегированный кеш, который сбрасывается при изменении элемента.
Классические шаблоны или headless: сравнение
Оба подхода живые. Выбор зависит от команды и задач проекта. Если у компании уже есть React-разработчики или планируется мобильное приложение, headless окупается быстрее. Для небольшого сайта без приложения классические шаблоны проще и дешевле.
| Критерий | Шаблоны Битрикса | Headless с REST API |
|---|---|---|
| Кто нужен в команде | PHP-разработчик и верстальщик | Фронтендер на React или Vue, бэкендер только на старте |
| Скорость интерфейса | Зависит от шаблона и кеша | SPA или SSR, быстрые переходы между страницами |
| SEO | Из коробки | Нужен SSR на Next.js или Nuxt |
| Мобильное приложение | Отдельное API всё равно понадобится | То же API обслуживает сайт и приложение |
| Готовые компоненты | Много модулей из Marketplace | Часть модулей придётся подключать через API |
Какие методы нужны API для сайта
Набор зависит от проекта, но для большинства сайтов на Битриксе повторяется.
REST API Битрикса для интернет-магазина
Магазину нужен самый широкий набор методов. Каталог на Битриксе часто держит десятки тысяч товаров с торговыми предложениями, и от того, как устроены фильтры и выборки, зависит скорость всего сайта. Я бы закладывал такой минимум.
- Каталог: разделы, список товаров с фильтрами, карточка товара с торговыми предложениями.
- Цены и остатки с учётом типа цены и склада.
- Поиск по названию и артикулу.
- Корзина, оформление заказа, доставка и оплата.
- Регистрация, авторизация по токену, личный кабинет и история заказов.
- Контентные страницы, баннеры, формы обратной связи.
- SEO-поля: title, description, канонический URL для каждой страницы.
Методы для корпоративного сайта
Здесь всё проще: страницы, новости, услуги, вакансии, формы. Обычно хватает пяти-семи методов, и основная работа уходит на фронтенд. Контент-менеджер при этом работает в привычной админке Битрикса и не замечает, что сайт снаружи собран на другой технологии. Для заказчика это важный довод: обучать сотрудников заново не нужно.
Как выбрать готовый модуль API
Готовых решений несколько, и перед тем как писать своё, их стоит сравнить. Я смотрю на пять вещей.
- Документация в формате OpenAPI или Swagger, по которой фронтендер может работать без вопросов к бэкендеру.
- Авторизация: токены, срок их жизни, обновление.
- Кеширование ответов и его сброс при изменении данных.
- Права доступа: какие инфоблоки и поля видны снаружи.
- Лицензия и активность разработчиков: открытый код, свежие обновления, ответы на вопросы.
Типичные ошибки
Отдавать наружу все поля инфоблока подряд. В ответ попадают служебные данные, а объём JSON растёт в разы.
Не думать о кеше. Без него каждый запрос к каталогу идёт в базу, и на распродаже сайт падает первым.
Делать API без версий. Когда фронтенд и мобильное приложение используют одни методы, любое изменение формата ответа ломает кого-то из них. Префикс вроде /api/v1/ и правило не менять старые версии без предупреждения решают проблему за час работы.
Забывать про SEO на фронтенде. Если сайт на React рендерится только в браузере, поисковые роботы видят пустую страницу. Next.js и Nuxt решают это серверным рендерингом, но title, description, микроразметку и sitemap всё равно нужно отдавать из API и выводить на каждой странице.
Сколько можно сэкономить на смете
Экономия появляется из-за того, что из проекта уходит работа, которая повторяется от сайта к сайту. Бэкендер больше не пишет в десятый раз методы каталога, корзины и авторизации. Он подключается только там, где нужна нестандартная логика: интеграция с 1С, сложные скидки, расчёт доставки.
Точный процент зависит от проекта. На простом корпоративном сайте бэкенд может почти полностью исчезнуть из сметы. На интернет-магазине с обменом с 1С и личным кабинетом оптовика экономия меньше, потому что интеграции всё равно пишутся вручную.
Вторая выгода — скорость. Фронтенд и контент начинают делать параллельно, не дожидаясь, пока бэкендер подготовит каждый метод.
Третья — проще найти людей. React- и Vue-разработчиков на рынке заметно больше, чем PHP-разработчиков, которые хорошо знают Битрикс. Когда фронтенд отделён, команду под проект собрать легче, а замена одного человека не останавливает работу. Для клиента это ещё и меньше зависимости от конкретного подрядчика: код фронтенда на популярном фреймворке понятен любой другой команде.
Вопросы и ответы
Можно ли сделать сайт на Битриксе без бэкенд-разработчика?
Да, если есть готовое настраиваемое REST API. Фронту остаётся создать структуру инфоблоков и сделать фронтенд на React или Vue.
Зачем Битриксу отдельное REST API?
Смета для клиента меньше, потому что бэкендер не участвует, а бэкендеру не надо в десятый раз писать очередное API.