Свой дашборд по CRM на Вайбкоде: как не положить портал Битрикс24

Дашборд, который ходит в портал при каждом открытии, рано или поздно получит ошибку переполненной очереди - и это не признак слабого сервера, а намеренное ограничение Битрикс24. Разбираем, как правильно выстроить архитектуру на Вайбкоде: кэш, фоновая выгрузка, агрегация через Vibe API и BI-коннектор для тяжёлых случаев.

Что умеет встроенный конструктор отчётов и какие срезы нужны отделу продаж - в отдельной статье «Отчёты и дашборды в Битрикс24». Здесь только про архитектуру нагрузки и сборку на Вайбкоде.

Как портал ограничивает нагрузку и что видит разработчик

Битрикс24 обслуживает лишь небольшое число тяжёлых одновременных запросов. Остальные встают в очередь и отваливаются по таймауту. Симптом - ошибка о переполненной очереди портала, причём она приходит даже на запрос списка задач или воронки сделок. Это не баг и не признак того, что портал медленный.

Ограничение сделано намеренно: приложения должны кэшировать данные у себя, а не дёргать CRM в реальном времени. Разработчик, который строит дашборд по принципу «открыл страницу - пошёл запрос», нарушает эту модель с первого же рефреша.

Vibe API в Вайбкоде снимает часть проблемы самостоятельно: он выстраивает запросы в очередь, соблюдает лимиты портала, делает пакетные запросы и постраничную выборку. Это значит, что случайная параллельная загрузка не сразу роняет портал - но архитектуру приложения Vibe API не заменяет.

Что нужно принять как данность:

• один тяжёлый дашборд с живыми запросами способен занять все слоты очереди и замедлить работу в CRM для всей команды;
• ошибка очереди возникает не только у вас - она приходит к любому, кто обращается к порталу в этот момент;
• ключ только для чтения не спасает от перегрузки - он защищает данные, но не снижает количество запросов.

Понять устройство самой платформы лучше помогает обзорная статья «Что такое Битрикс24 Вайбкод».

Правило первое: не ходить в портал при каждом открытии

Это главное архитектурное правило дашборда на Вайбкоде. Приложение должно отвечать из собственного хранилища, а не из портала.

Как это устроено:

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

Сервер Вайбкода умеет засыпать - это нормально для небольших приложений в галактике (хост на несколько десятков приложений). Для ночного пересчёта у спящего сервера настраивают пробуждение по расписанию: сервер просыпается, выгружает данные, снова засыпает. Это дешевле, чем держать сервер горячим круглосуточно, и не создаёт нагрузку на портал в рабочее время.

Что выдавать пользователю:

• при открытии дашборда - данные из кэша, с отметкой времени последнего обновления;
• кнопку «Обновить сейчас» - только для принудительного запроса, не по умолчанию;
• индикатор «данные обновляются» - если фоновая задача запущена, но ещё не завершена.

Ключ для дашборда почти всегда выдают в режиме только для чтения: запись блокируется на стороне Вайбкода ещё до обращения к Битрикс24. Это дешёвая страховка от случайной порчи данных через аналитическое приложение.

Данные приложения живут на диске сервера, исходники сохраняются при каждом деплое. После инцидента 29 июня 2026 года для всех серверов Вайбкода включили авто-резервное копирование.

Правило второе: считать на стороне API, а не тащить всё к себе

Типичная ошибка новичка: запросить все сделки за квартал, положить их в массив и посчитать сумму на стороне приложения. При нескольких сотнях сделок это работает. При нескольких тысячах - начинается постраничная выборка, десятки запросов, нагрузка на портал и долгое ожидание.

У Vibe API есть агрегация: вместо того чтобы вытащить все документы и посчитать самому, API считает и отдаёт готовый итог.

Оговорка: агрегация работает не со всеми типами полей. Пользовательские поля с нестандартными типами, составные поля и поля смарт-процессов могут не поддерживаться - это нужно проверять под конкретную задачу.

Для нестандартных срезов, которые агрегация не покрывает, выгружают только нужные поля - не всю карточку сделки. Vibe API позволяет указать список полей явно, что снижает объём передаваемых данных.

Подробнее о том, какие методы доступны через Vibe API и как работают модели платформы, - в статье «Vibe API и бесплатные ИИ-модели BitrixGPT в Вайбкоде».

Правило третье: когда пора уходить на BI-коннектор

Для по-настоящему больших выгрузок - сотни тысяч строк, история за несколько лет, мультипортальная аналитика - есть отдельный путь. BI-коннектор работает без постраничной выборки и без ограничения частоты запросов, с упрощённым синтаксисом фильтрации. Ключ берётся в разделе аналитики портала.

Когда стоит выбрать BI-коннектор вместо Vibe API:

• объём данных измеряется в сотнях тысяч записей;
• нужна выгрузка в промежуточное хранилище для последующей работы в Power BI, Yandex DataLens или аналогичных инструментах;
• требуется агрегация данных с нескольких порталов одновременно;
• нужна выгрузка полной структуры CRM (лиды, сделки, контакты, компании, связи между ними, пользовательские поля).

BI-коннектор выгружает данные в промежуточное облачное хранилище и обновляет их с заданной периодичностью. Это правильный выбор, когда дашборд на Вайбкоде уже не справляется с объёмом, и задача перерастает в полноценную BI-систему.

Для среднего портала с разумным объёмом данных Вайбкод с правильной архитектурой кэша полностью решает задачу без перехода на внешний BI.

Как приложение живёт и обновляет данные

После деплоя на Вайбкоде приложение автоматически появляется в каталоге приложений внутри портала. Оно доступно в веб-интерфейсе и в мобильном приложении Битрикс24. Для показа внутри карточки сделки или контакта используется встройка через плейсмент.

Жизненный цикл данных в типовом дашборде выглядит так:

Приложение получает данные из портала через Vibe API, кладёт их в собственное хранилище, отдаёт пользователю из кэша, а фоновая задача по расписанию обновляет хранилище.

flowchart TD
    B24[Битрикс24 CRM] -->|Vibe API - фоновый запрос| CACHE[Хранилище приложения]
    SCHED[Пробуждение по расписанию] -->|инициирует обновление| CACHE
    CACHE -->|отдаёт данные| UI[Дашборд - пользователь]
    UI -->|принудительное обновление| CACHE

Обновление по уровням:

• Агрегаты (сумма воронки, конверсия по менеджерам) - обновляются по расписанию, раз в несколько часов;
• Оперативные показатели (новые сделки за сегодня, просроченные задачи) - отдельный лёгкий запрос, чаще;
• Исторические срезы (закрытые периоды, прошлые кварталы) - обновляются реже, данные стабильны.

Исходники сохраняются при каждом деплое, откат - в один клик из реестра версий. Это важно для дашборда: при случайном «ломающем» изменении логики кэширования можно вернуться к рабочей версии без потери данных.

О безопасности ключей и разграничении доступа подробнее - в статье «Безопасность вайбкодинга в Битрикс24».

Что ломается на практике

Честный раздел о граблях, которые встречаются при сборке аналитических приложений на Вайбкоде.

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

Кэш нельзя перезаписывать пустым ответом. При сбое запроса (таймаут, ошибка очереди) приложение не должно писать пустой результат в хранилище. Иначе дашборд покажет нули - и никто не поймёт, это реальные данные или артефакт сбоя. Правило: при ошибке оставляем предыдущий кэш, выставляем статус «данные устарели».

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

Массовые операции - маленькими пачками. Если логика дашборда когда-либо пишет данные обратно (например, проставляет тег или обновляет поле), это нужно делать небольшими пачками с задержкой, а не одним массовым запросом.

Стыки окон при разбиении по датам. При разбиении выборки на временные окна часть записей теряется на стыках - если сделка изменилась ровно в момент границы окна. Для закрытых периодов надёжнее один запрос с фильтром по дате закрытия, а не несколько с перекрытием.

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

Cursor несовместим с Вайбкодом - при сборке используйте Claude или Codex, а также скилл Superpowers (/brainstorm). Для аналитических приложений с ключом только для чтения это особенно важно: ИИ-агент должен точно понимать схему API, иначе он может сгенерировать запросы, которые обходят ограничение.

С чего начать

Практический порядок для интегратора или технического руководителя, который хочет собрать дашборд на Вайбкоде.

1. Определить тип ключа. Дашборд почти всегда только читает. Создайте ключ в режиме только для чтения в разделе API-ключей Вайбкода. Для дашборда под конкретного пользователя (с его правами на сделки) - ключ авторизации (OAuth-приложение), создаётся администратором портала.

2. Выбрать место размещения. Небольшой дашборд для одного портала кладут в галактику - хост на несколько десятков приложений, тарифицируется сам хост. Для продакшн-решения на несколько команд или с тяжёлой фоновой выгрузкой - отдельный сервер.

3. Спроектировать схему кэша до написания кода. Какие показатели обновляются как часто? Какой размер хранилища нужен? Что показываем при сбое обновления? Это проще решить на бумаге, чем переделывать в коде.

4. Начать с агрегатов, не с выгрузки. Первый запрос к порталу - агрегация через Vibe API, а не постраничная выборка всех сделок. Убедитесь, что нужные поля поддерживают агрегацию.

5. Настроить пробуждение по расписанию. Сервер в галактике засыпает при отсутствии активности. Для ночного и утреннего обновления данных пробуждение по расписанию настраивается в параметрах сервера.

6. Задеплоить и проверить встройку. После деплоя приложение появляется в каталоге портала. Если нужен виджет в карточке сделки - плейсмент настраивается отдельно.

Больше о том, что реально можно собрать на платформе за разумное время, - в статье «Что можно собрать на Битрикс24 Вайбкод».

Если нужна помощь с проектированием архитектуры дашборда или оценкой объёма работ - напишите на sales@acp-24.ru или позвоните по номеру +7 495 414-48-49. АС Проект - платиновый партнёр Битрикс24.

Нужна помощь по вайбкод-приложению? АС Проект - платиновый партнёр Битрикс24: собираем приложения на Вайбкоде, проверяем чужие перед боевым запуском и берём на сопровождение. Состав работ и цены - на странице приложения на вайбкодинге.

Частые вопросы