Тендеры и лиды
Информация
В разработке есть момент, который наступает почти неизбежно: бизнес хочет больше скорости и больше возможностей, а платформа на это не рассчитана. Тогда приходится искать элегантные решения, принимать компромиссы и иногда приручать черного лебедя. На одном из таких поворотов мы и оказались с проектом на монолите.
Меня зовут Евгений Шарыпов, я руковожу направлением веб‑разработки программных систем в ИТ‑компании ARTW.
Мы много лет делаем e‑commerce‑проекты на Битриксе. Для большинства компаний это надежная, понятная и экономически эффективная платформа, на которой удобно быстро стартовать и собрать первые версии продукта. Но проект растет, требования меняются, и в какой-то момент типовые решения начинают тормозить бизнес.
В этой статье разберу на примере одного из наших проектов, как мы ушли от монолита и пришли к API‑First архитектуре и что это дало бизнесу.
В типовом e‑commerce проекте на Битрикс все живет внутри одного монолита — CMS: витрина, каталог, корзина, интеграции, платежи. Такой подход долго был стандартом. Он быстро запускается, предсказуем в поддержке и нормально работает, пока бизнес развивается в одном канале и меняется умеренно.
Но связность монолита быстро становится ограничением. Любое изменение — от баннера до новой карточки товара требует релиза всей системы. В итоге скорость бизнеса начинает зависеть не от маркетинга, а от скорости разработки и от того, насколько рискован очередной релиз.
Примерно такая инфраструктура была у одного из наших проектов- интернет-магазинов Concept Group.
Отправная точка — несколько интернет‑магазинов на «Битрикс: Управление сайтом» + CRM в режиме многосайтовости. За это время были сформированы устоявшиеся процессы, понятные сценарии. Проект развивался несколько лет и накопил приличный груз кодовой базы. Новые функции делались все медленнее. Главная причина — связность кода в шаблонах и компонентах. Современные требования к фронтенду мы закрывали не полностью: монолит и серверный рендеринг не давали раскрыть потенциал Vue / React.
Параллельно назрела задача полного редизайна. Типовой путь понятен: сверстать макеты и внедрить их в шаблоны и компоненты. Но мы решили пойти дальше и использовать редизайн как точку для архитектурной развилки.
Мы разделили слои. Ядро (backend) оставили стабильным на Битрикс: оно отвечает за данные, цены, остатки, бизнес‑процессы и интеграции. Витрина (frontend) стала самостоятельной: получает данные по API и меняется столько раз, сколько нужно бизнесу, без правок в бэкенде «по мелочам». Фронтенд мы реализовали на стеке Vue3 + Nuxt3.
Смысл простой: фронт развивается в своем темпе и не задевает критичные процессы на стороне backend. При этом backend может представлять собой, как монолитное решение, на и распределенную сервисную архитектуру - снижая зависимость от технологий и стэка. Эта независимость и делает такой подход, который не замедляет рост, а подстраивается под него.
Чтобы backend и frontend говорили на одном языке, мы начали с контракта. Описали его в Swagger: какие данные отдаем и по каким REST API‑эндпоинтам. Это и был первый шаг к API‑First. После этого команды смогли работать параллельно и не тратить время на «давайте потом уточним формат».
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13360 тендеров
проведено за восемь лет работы нашего сайта.
Затем мы зафиксировали структуру ответов на бэкенде. Для этого описали DTO‑модели — простой слой между контроллерами и ответами REST API.
Отдельно расскажу про контроллеры REST API. В Битриксе многие вещи уже реализованы через компоненты, и часть компонентов написана как классы. Их можно наследовать и использовать повторно в наших API‑методах. Мы так и сделали. Например, фасетный фильтр построили на базе bitrix:catalog.smart.filter. То есть мы не переписывали проверенный функционал, а аккуратно переиспользовали его.
Битрикс поддерживает виртуальные сессии. Поэтому мы смогли использовать возможности ядра Bitrix Framework без дополнительных обходных решений. Это снижает стоимость перехода и уменьшает количество самописного кода.
Для управления контентом страниц мы взяли бесплатный модуль из маркетплейса — sprint.editor. Он расширяемый, а набор контентных блоков не ограничен. Структуру данных блоков мы тоже зафиксировали в контракте. В итоге каждый блок в админке стал соответствовать Vue‑компоненту на фронте: контент‑менеджер работает в привычном интерфейсе, а витрина получает предсказуемые данные.
С точки зрения админки сайта и CRM ничего не поменялось. Контент‑менеджеры и администраторы работают так же, как работали раньше, без смены привычных сценариев.
Вся бизнес‑логика осталась в Bitrix Framework. Поэтому платформу можно обновлять спокойно. Мы не вмешиваемся в ядро и не превращаем каждый апдейт в отдельный проект.
В итоге мы получили устойчивое решение, которое не затрагивает ядро Bitrix Framework и при этом поддерживает API‑First подход. Для бизнеса это означает продукт на современных рельсах, но без ломки привычных процессов в админке и CRM.
Для разработчиков Bitrix Framework закрывает все базовые потребности для REST API: можно развивать сервисный слой, фиксировать контракт и спокойно масштабировать точки входа. Веб‑витрина, личный кабинет, мобильное e‑commerce‑приложение — все это можно строить на одном ядре, не дублируя бизнес‑логику. При этом фронт живет своей жизнью: меняется быстро и часто, а критичные процессы в бэкенде остаются стабильными.
Для сотрудников бизнеса плюс в том, что рабочие инструменты не меняются. Контент‑менеджеры и администраторы остаются в знакомой панели, но получают более гибкую витрину и предсказуемые блоки. Маркетинг и продукт меньше зависят от «больших релизов»: часть задач решается на фронте быстрее и безопаснее.
И главный эффект для компании — скорость без потери надежности. Вместо релиза «всего сайта» ради одного изменения на витрине появляется управляемая схема, где каждый слой развивается в своем темпе, а бизнес получает больше изменений за то же время и с меньшими рисками.
