Как обновить интернет-магазин на Битриксе и не переписывать весь проект
Мы довольно плотно работаем с e-commerce, а там любят скорость. Быстрый интерфейс, плавные переходы, мгновенную реакцию на действия пользователя. Для бизнеса это не только красиво: чем проще и быстрее клиенту работать с сайтом, тем меньше трения на пути к покупке.
Современный фронтенд позволяет это реализовать достаточно привычно. Vue, React, Angular и другие реактивные технологии хорошо подходят для интернет-магазинов, личных кабинетов и B2B-порталов.
Если проект работает на Laravel или другом современном фреймворке, задача обычно выглядит просто: проектируем API под нужды фронтенда и работаем.
А вот с 1С-Битрикс всё становится интереснее. Да, у БУС есть штатные и околоштатные решения. Есть готовые модули, есть разные подходы к созданию API. Мы их смотрели и пробовали. Но где-то решение оказалось слишком объёмным, где-то не закрывало нужные сценарии, где-то приходилось слишком сильно подстраивать проект под модуль.
Поэтому пошли другим путём.
В несколько итераций и на нескольких проектах мы постепенно развивали собственное API-решение для 1С-Битрикс. В основе — микрофреймворк SLIM: маршрутизация, MVC и всё необходимое для построения отдельного API-слоя. Сам API обложен Swagger. Документация здесь не появляется когда-нибудь потом, а является частью решения.
Сейчас это уже рабочий модуль для Битрикса. Пока сырой в части упаковки, но вполне боевой в реальных проектах. В админку вынесены базовые настройки: где лежат товары, торговые предложения, баннеры, новости и другие сущности, которые обычно нужны в B2C- и B2B-проектах.
Поддерживается стандартный каталог с торговыми предложениями, типами цен, складами и свойствами. Стандартные каталоги и фильтры. Корзина, оформление и подтверждение заказа, штатные методы оплаты и доставки, включая сторонние модули вроде СДЭКа. Профили заказов, личный кабинет пользователя — всё доступно через API.
Зачем это бизнесу?
Потому что одна и та же бизнес-логика может жить в разных интерфейсах. Сегодня у вас интернет-магазин на Битриксе. Завтра нужен новый современный фронтенд. Послезавтра — мобильное приложение. Или отдельный B2B-кабинет для клиентов.
Не обязательно каждый раз начинать проект с переноса всей логики и переписывания интеграций. Меняется фронтенд, а каталог, цены, остатки, заказы, пользователи и бизнес-процессы продолжают работать на привычной системе.
На мой взгляд, самая интересная особенность этого подхода в другом.
Такое решение можно адаптировать и поставить на уже существующий проект. Не нужно обязательно начинать миграцию с чистого листа. Можно подключить API-слой, адаптировать его под конкретный проект и постепенно запускать новый интерфейс, мобильное приложение или другие каналы.
Получается вполне практичная архитектура: один источник бизнес-логики и несколько способов работать с ней. В итоге вопрос «Битрикс или современный фронтенд?» вообще перестаёт быть вопросом.
Платформа, которая мешает вашему бизнесу развиваться, — не обязательно плохая платформа. Иногда бизнесу не нужно менять платформу. Ему нужно перестать использовать её так, как будто других вариантов не существует.
Пока решение используем только на своих проектах. Возможно, когда-нибудь оно появится на маркетплейсе или в открытом виде на сайте.
Мы довольно плотно работаем с e-commerce, а там любят скорость. Быстрый интерфейс, плавные переходы, мгновенную реакцию на действия пользователя. Для бизнеса это не только красиво: чем проще и быстрее клиенту работать с сайтом, тем меньше трения на пути к покупке.
Современный фронтенд позволяет это реализовать достаточно привычно. Vue, React, Angular и другие реактивные технологии хорошо подходят для интернет-магазинов, личных кабинетов и B2B-порталов.
Если проект работает на Laravel или другом современном фреймворке, задача обычно выглядит просто: проектируем API под нужды фронтенда и работаем.
А вот с 1С-Битрикс всё становится интереснее. Да, у БУС есть штатные и околоштатные решения. Есть готовые модули, есть разные подходы к созданию API. Мы их смотрели и пробовали. Но где-то решение оказалось слишком объёмным, где-то не закрывало нужные сценарии, где-то приходилось слишком сильно подстраивать проект под модуль.
Поэтому пошли другим путём.
В несколько итераций и на нескольких проектах мы постепенно развивали собственное API-решение для 1С-Битрикс. В основе — микрофреймворк SLIM: маршрутизация, MVC и всё необходимое для построения отдельного API-слоя. Сам API обложен Swagger. Документация здесь не появляется когда-нибудь потом, а является частью решения.
Сейчас это уже рабочий модуль для Битрикса. Пока сырой в части упаковки, но вполне боевой в реальных проектах. В админку вынесены базовые настройки: где лежат товары, торговые предложения, баннеры, новости и другие сущности, которые обычно нужны в B2C- и B2B-проектах.
Поддерживается стандартный каталог с торговыми предложениями, типами цен, складами и свойствами. Стандартные каталоги и фильтры. Корзина, оформление и подтверждение заказа, штатные методы оплаты и доставки, включая сторонние модули вроде СДЭКа. Профили заказов, личный кабинет пользователя — всё доступно через API.
Зачем это бизнесу?
Потому что одна и та же бизнес-логика может жить в разных интерфейсах. Сегодня у вас интернет-магазин на Битриксе. Завтра нужен новый современный фронтенд. Послезавтра — мобильное приложение. Или отдельный B2B-кабинет для клиентов.
Не обязательно каждый раз начинать проект с переноса всей логики и переписывания интеграций. Меняется фронтенд, а каталог, цены, остатки, заказы, пользователи и бизнес-процессы продолжают работать на привычной системе.
На мой взгляд, самая интересная особенность этого подхода в другом.
Такое решение можно адаптировать и поставить на уже существующий проект. Не нужно обязательно начинать миграцию с чистого листа. Можно подключить API-слой, адаптировать его под конкретный проект и постепенно запускать новый интерфейс, мобильное приложение или другие каналы.
Получается вполне практичная архитектура: один источник бизнес-логики и несколько способов работать с ней. В итоге вопрос «Битрикс или современный фронтенд?» вообще перестаёт быть вопросом.
Платформа, которая мешает вашему бизнесу развиваться, — не обязательно плохая платформа. Иногда бизнесу не нужно менять платформу. Ему нужно перестать использовать её так, как будто других вариантов не существует.
Пока решение используем только на своих проектах. Возможно, когда-нибудь оно появится на маркетплейсе или в открытом виде на сайте.