Итоги 2022: QA, Laravel, React и мобильное приложение на Битриксе

Как подключить мобильное приложение к Битриксу

Сайт на 1С-Битрикс уже хранит каталог, цены, остатки, пользователей и заказы. Мобильному клиенту нужен доступ к тем же данным, только не через HTML-страницы, а через API. Поэтому основная работа на стороне сервера — описать методы: список товаров, карточка, корзина, оформление заказа, профиль, история покупок.

Внутри Битрикса для этого есть контроллеры ядра D7: они принимают запрос и отдают JSON. Можно пойти другим путём и поднять рядом лёгкий фреймворк вроде Slim, который работает с теми же модулями — инфоблоками и интернет-магазином. Так делали наши разработчики после курса по Laravel: API для мобильных приложений и фронта собирали на Slim поверх Битрикса.

• авторизация по токену вместо сессии и cookies;
• версия API в адресе, чтобы старые сборки приложения не ломались после обновлений;
• кэширование каталога: мобильный клиент запрашивает его часто;
• пуши через Firebase Cloud Messaging по событиям заказа в модуле интернет-магазина.

Мобильное приложение для Битрикса: своё или готовое

В Маркетплейсе Битрикса есть готовые решения, которые собирают приложение по шаблону. Для типового магазина это быстрый старт. Как только нужен свой интерфейс, нестандартная корзина или интеграция с курьерами, шаблон начинает мешать, и выгоднее своё приложение на Flutter или React Native поверх собственного API.

React на Битриксе: разделить фронт и бэк

Классический Битрикс рендерит страницы на сервере через компоненты и шаблоны. Оформление заказа в нём обычно строится на стандартном компоненте sale.order.ajax, и его доработка под нестандартный сценарий — известная боль битрикс-разработчиков.

Альтернатива — отдать интерфейс React-приложению, а Битрикс оставить источником данных и админкой. Фронт ходит в API, бэкенд не знает, как выглядит страница. Для SEO такой фронт рендерят на сервере, например через Next.js.

Когда React поверх Битрикса оправдан

Для простого каталога с типовой корзиной разделение чаще добавляет работы, чем экономит. Появляются две кодовые базы, два деплоя и вопрос, кто отвечает за ошибку на стыке. Без отдельного фронтенд-разработчика в команде такой проект тяжело поддерживать.

• сложные интерактивные сценарии: конфигураторы, многошаговое оформление, личный кабинет B2B;
• один API нужен сразу сайту и мобильному приложению;
• команда фронтенда работает отдельно от бэкенда и выпускает релизы в своём ритме.

Laravel или Битрикс: что выбрать под проект

Спор между этими платформами обычно звучит как спор про качество кода, хотя на деле решают бизнес-задача и бюджет на поддержку.

Ошибки при запуске приложения поверх Битрикса

Большая часть проблем возникает не в самом приложении, а на стыке с сайтом. Их проще предупредить на этапе проектирования API, чем чинить после релиза в сторах.

• отдавать в API данные прямо из шаблонов сайта — любая правка вёрстки ломает приложение;
• не предусмотреть версии API и заставлять всех пользователей обновляться;
• считать цены и скидки в приложении отдельно от правил корзины Битрикса;
• забыть про нагрузку: каталог для приложения без кэша кладёт сервер в часы пик;
• не продумать вход: пользователи сайта должны попасть в приложение под тем же аккаунтом.

Что я бы повторил

Если собрать итоги года в короткий список, получится так. Тестирование, аналитика и проектное управление — отдельными строками в каждой смете. Обучение новому фреймворку не ради миграции, а ради того, чтобы на привычном стеке писали взрослее. Пресейлы для нового направления — как инвестиция, которая окупается не сразу. И мобильная разработка начиналась с одного клиента и API на Битриксе, а не с отдельного отдела.