Товарная панель для магазина цветов

Задача

Ассортимент живёт в Bitrix24, но добраться до него в рабочих условиях почти невозможно. Главная боль — мобильное приложение: посмотреть в нём каталог целиком нельзя, а продавцу нужно именно это — быстро найти позицию, проверить цену и остаток, стоя у прилавка или собирая заказ.

Нужен был отдельный взгляд на те же данные: дерево разделов, розничные и закупочные цены, остатки по вариациям — без дублирования базы и ручной синхронизации.

Почему предыдущая попытка не взлетела

Похожую панель пробовали сделать до меня, и она упёрлась в скорость: каждый товар запрашивался у Bitrix24 отдельно, и открытие каталога занимало около 20 секунд. Инструментом, который думает двадцать секунд, никто не пользуется — проще открыть десктоп и потерпеть.

Причина не в Bitrix24, а в способе обращения к нему. Когда на каждую позицию идёт свой запрос, время складывается из сотен сетевых задержек, и каждая из них по отдельности выглядит незаметной.

Решение

Сервис на FastAPI подключается к Bitrix24 через входящий вебхук и читает торговый каталог методами catalog.*. Своей базы у него нет — это принципиально: источник правды остаётся один, расхождению взяться неоткуда.

• Дерево разделов и подразделов с хлебными крошками и порядком сортировки ровно таким, как в CRM.
• Карточки товаров с фото, розничными и закупочными ценами, остатками и вариациями.
• Поиск по названию и ID и постраничный вывод — каталог большой, без этого им не пользоваться.
• JSON-эндпоинты для внешних интеграций и синхронизации с каталогом сайта, плюс автодокументация OpenAPI.
• Кэш и лимит запросов — чтобы не упираться в ограничения Bitrix24 при активной работе.

Как получилось 2 секунды вместо 20

Ускорение дали не оптимизации по мелочи, а смена самого способа общения с Bitrix24 — keep-alive вместо нового соединения на каждый вызов и батчинг вместо поштучных запросов.

• Пакетные запросы вместо поштучных. Товары запрашиваются не по одному, а пачками: один вызов забирает сразу целый список позиций с ценами. Вместо сотен обращений получается несколько — и время перестаёт складываться из сетевых задержек.
• Постоянное соединение (keep-alive). Раньше на каждый запрос поднималось новое соединение — с установкой TCP и рукопожатием TLS. Теперь клиент к Bitrix24 создаётся один раз, держится в памяти и обслуживает всю серию вызовов по одному соединению. На сотнях запросов именно эти рукопожатия и съедали большую часть прежних двадцати секунд.
• Выдержка интервала между вызовами. Минимальная пауза между обращениями настраивается — так пакетная загрузка не упирается в лимиты Bitrix24 и не получает отказов, из-за которых пришлось бы всё повторять.
• Кэш с фоновым обновлением. Ответы складываются в кэш с временем жизни: повторное открытие каталога отдаётся мгновенно, а данные обновляются в фоне. Пока идёт обновление, пользователь видит прошлую версию, а не пустой экран.
• Запасной путь на случай сбоя. Если пакетный запрос по какой-то причине не проходит, код доезжает по одной позиции — медленнее, но каталог всё равно открывается, а не падает с ошибкой.

В сумме открытие каталога сократилось с двадцати секунд до примерно двух — то есть панелью стало можно пользоваться в реальной работе, а не «когда есть время подождать».

Как устроено внутри

Код разделён на слои: работа с REST Bitrix24 и разбор ответов, доменная логика каталога (сортировка, дерево разделов, форматирование цен и остатков) и HTTP-слой с шаблонами. Домен не знает про HTTP, а HTTP не знает про формат ответов Bitrix24 — благодаря этому изменения в API поставщика не расползаются по всему проекту.