Большинство REST API для 1С-Битрикс строятся по одному сценарию — разработчик переписывает уже существующую бизнес-логику платформы, создавая собственные контроллеры, корзину, каталог и оформление заказа. Мы тоже когда-то так делали, пока не посмотрели на проблему под другим углом. В этой заметке рассказываем, почему отказались от «велосипедов» и построили API поверх нативных компонентов Битрикса, сохранив штатное кеширование, композитный режим и всю бизнес-логику платформы.
За последние несколько лет мы реализовали достаточно много проектов, где сайт на 1С-Битрикс: Управление сайтом выступал исключительно backend'ом для мобильного приложения или фронтенда на Nuxt/Next. И практически каждый раз первым этапом становилась разработка REST API. Со временем мы пришли к выводу, что классический подход, которым пользуется большинство разработчиков, создает огромное количество лишней работы. В этой заметке расскажем, почему мы полностью отказались от написания собственного API и что используем сегодня.
Классический путь — написать собственное API
Если открыть большинство проектов на Битриксе, схема будет примерно одинаковой. Разработчик создает собственные контроллеры, подключает модули ядра, начинает получать товары через CIBlockElement, самостоятельно собирает корзину, рассчитывает цены, пишет оформление заказа и постепенно строит вокруг этого собственное REST API.
На первый взгляд всё выглядит логично. Кажется, что такой подход дает полный контроль над проектом. На практике же почти сразу начинают всплывать проблемы.
Во-первых, приходится заново реализовывать огромное количество бизнес-логики, которая уже существует внутри самого Битрикса. Причем это далеко не только получение списка товаров.
- правила скидок;
- торговые предложения;
- типы цен;
- остатки;
- правила работы корзины;
- купоны;
- доставка;
- оформление заказа;
- права доступа;
- SEO-настройки;
- работа композитного режима;
- механизмы кеширования.
Большинство этих вещей выглядят достаточно простыми ровно до того момента, пока не появляется первый нетипичный кейс. Потом выясняется, что где-то не применились скидки, где-то корзина считает цену иначе, чем сайт, а оформление заказа неожиданно перестает учитывать внутренние правила магазина.
Еще одна проблема проявляется после обновления ядра Битрикса. Компания 1С-Битрикс постоянно дорабатывает внутреннюю бизнес-логику. Если API написано вручную, часть этих изменений приходится переносить самостоятельно. В результате собственное API постепенно начинает жить отдельной жизнью и всё сильнее расходится с поведением самого сайта.
Готовые модули из Marketplace проблему тоже не решают
Разумеется, мы посмотрели и на готовые решения из Marketplace. Таких модулей существует достаточно много. Практически каждый обещает "REST API для Битрикса за пять минут".
Да, они действительно позволяют быстрее начать разработку мобильного приложения или SPA. Но если посмотреть внутрь большинства подобных решений, становится понятно, что они используют тот же самый подход — просто кто-то уже написал велосипеды за вас.
Это означает, что фундаментальные проблемы никуда не исчезают.
- дублирование бизнес-логики Битрикса;
- собственная реализация корзины и каталога;
- необходимость ждать обновлений модуля;
- зависимость от стороннего разработчика;
- отсутствие гарантий совместимости с будущими версиями платформы.
Фактически разработчик просто покупает чужой велосипед вместо написания собственного. Да, это экономит время на старте, но принципиально архитектура не меняется.
Мы посмотрели на проблему под другим углом
В какой-то момент возник вполне логичный вопрос.
Зачем вообще переписывать бизнес-логику Битрикса?
Ведь именно за нее мы и покупаем лицензию платформы.
Если отбросить CMS-функции вроде управления страницами или редактора контента, основная ценность Битрикса заключается именно в готовой бизнес-логике интернет-магазина. Каталог, торговые предложения, скидки, оформление заказов, корзина, кеширование, права доступа — всё это уже написано, протестировано и развивается разработчиками платформы многие годы.
Получается странная ситуация. Мы платим за готовую бизнес-логику, а потом самостоятельно переписываем половину этой логики только ради того, чтобы получить JSON вместо HTML.
Именно тогда появилась идея вообще отказаться от собственного API как такового.
Компоненты Битрикса уже умеют всё, что нам нужно
Практически вся работа интернет-магазина в Битриксе построена вокруг компонентов. Именно они получают данные, применяют всю внутреннюю бизнес-логику платформы и формируют итоговый $arResult, который затем отображается шаблоном.
По сути, именно $arResult уже содержит всё, что требуется мобильному приложению или современному frontend'у.
Поэтому вместо написания собственных запросов к базе данных мы решили научиться получать данные непосредственно после выполнения компонента.
Мы написали собственную надстройку над компонентной системой Битрикса, которая позволяет получать $arResult и $arParams практически без изменений, но вместо HTML отдавать готовый JSON.
При этом сохраняются абсолютно все преимущества штатной архитектуры платформы.
- нативная бизнес-логика Битрикса;
- штатное компонентное кеширование;
- корректная работа композитного режима;
- полная совместимость с обновлениями компонентов;
- отсутствие дублирования логики.
Особенно приятно оказалось то, что нам вообще не пришлось писать собственую систему кеширования. Любой, кто хоть раз пытался реализовать корректный кеш поверх REST API, знает, сколько нюансов приходится учитывать. Здесь же всё уже существует внутри самой платформы.
Более того, продолжает корректно работать и композитный режим Битрикса. Если компонент уже закеширован, API фактически отдает готовый результат практически мгновенно. В большинстве случаев речь идет буквально о десятках микросекунд выполнения серверной части.
Что получилось в итоге
Изначально решение создавалось исключительно для внутренних проектов. Но после нескольких внедрений стало понятно, что оно радикально сокращает время разработки практически любого Headless-проекта на Битриксе.
Сегодня именно эта архитектура используется практически во всех наших проектах, где Битрикс работает как backend для Nuxt, Next.js или мобильных приложений на React Native.
Вместо нескольких недель проектирования REST API мы практически сразу начинаем заниматься пользовательским интерфейсом и бизнес-задачами клиента. При этом приложение использует ту же бизнес-логику, что и сам интернет-магазин, а обновления платформы перестают быть источником постоянной головной боли.
Наверное, именно это и стало главным выводом всей истории. Иногда лучший способ написать сложную систему — вовсе не писать ее, а научиться правильно использовать уже существующую архитектуру.