Бэкенд мобильного приложения: почему 1С зависла при 15 менеджерах

Бэкенд — это серверная часть приложения: код и база данных, которые хранят информацию, проверяют права доступа и отвечают на запросы от экрана телефона. Пользователь нажимает «оформить заказ», а саму сделку проводит бэкенд: синхронизирует её с 1С, списывает остаток на складе и возвращает ответ на экран.

как приложение работало на демо и легло, когда подключились 15 менеджеров

В марте отдел продаж московской торговой компании заказал разработку мобильного приложения для оформления заказов на выезде. На демонстрации всё работало гладко: один менеджер выбирал товар из каталога на 40 позиций, нажимал «отправить», и заказ появлялся в 1С через несколько секунд. Подрядчик закрыл проект и выставил акт.

Через месяц каталог вырос до нескольких тысяч позиций, а с планшетов стали одновременно работать все 15 менеджеров отдела продаж. Приложение зависало при открытии каталога, часть заказов задваивалась, склад дважды отгрузил товар, которого уже не было в наличии. Дело было не в самих экранах — кнопки и формы работали исправно. Дело было в том, что бэкенда как отдельного слоя не существовало вообще: каждое нажатие в приложении напрямую обращалось к веб-сервисам 1С, и вся нагрузка — очереди запросов, проверка остатков, кэш каталога — легла прямо на боевую базу бухгалтерии.

Три недели ушло на поиск причины, ещё столько же — на переписку с подрядчиком, который настаивал, что приложение работает исправно, а проблема в самой 1С. В итоге компания оплатила срочную доработку у другого исполнителя, а склад почти месяц вручную сверял остатки после каждой спорной отгрузки. Заложи компания бэкенд в архитектуру сразу, переделки бы не понадобилось.

что делает бэкенд и почему без него приложение — просто набор экранов

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

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

Без бэкенда каждое действие в приложении — это отдельный запрос к боевой базе 1С, будто пятнадцать человек одновременно звонят на один и тот же телефон бухгалтера с вопросом об остатках. Один разговор ещё можно выдержать, пятнадцать одновременных — уже нет, особенно если бухгалтерия в этот момент закрывает месяц.

В кейсе с торговой компанией ни одной из этих функций не было — только фронтенд, который напрямую обращался к 1С. Если бы приложению нужно было хранить персональные данные покупателей — телефон, адрес доставки, — их пришлось бы обрабатывать по требованиям 152-ФЗ, а без бэкенда невозможно даже разграничить, кто из менеджеров и когда видел карточку конкретного клиента.

как работает связка «приложение — бэкенд — 1С» по шагам

Правильная архитектура выглядит иначе, и разница видна на том же сценарии с заказом.

1. ✓Менеджер нажимает «оформить заказ» в приложении на планшете.
2. ✓Приложение отправляет запрос не в 1С напрямую, а на свой бэкенд-сервер — с токеном, который подтверждает личность менеджера.
3. ✓Бэкенд проверяет права доступа и смотрит в собственный кэш: если каталог и остатки уже загружены за последние несколько минут, отвечает сразу, не трогая 1С.
4. ✓Если данных в кэше нет или заказ нужно провести, бэкенд обращается к 1С через свой пул соединений — один канал вместо пятнадцати параллельных запросов от разных планшетов.
5. ✓1С обрабатывает операцию и возвращает результат; бэкенд обновляет кэш и отправляет короткий ответ на экран приложения.

Если бы все 15 планшетов слали запросы в 1С одновременно каждые несколько секунд, эта нагрузка совпадала бы с закрытием месяца в бухгалтерии — а это худшее время для лишних обращений к базе. Кэш на бэкенде убирает большую часть этого потока: 1С отвечает не на каждый клик с экрана, а на пакет запросов раз в несколько минут.

В такой схеме 1С обращается только к одному клиенту — бэкенду, а не к пятнадцати планшетам сразу. Именно это чаще всего снимает зависания при закрытии месяца или при массовой синхронизации: очередь запросов становится управляемой, а не хаотичной.

три варианта бэкенда для приложения, которое работает с 1С

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

когда достаточно прямого подключения к 1С

Прямое подключение — не всегда ошибка. Если приложением пользуются 2-3 сотрудника, а заказов в день немного, боевая база 1С справляется с нагрузкой без проблем, и городить отдельный сервер невыгодно. Разница появляется, когда число пользователей и объём каталога растут: те же запросы, которые раньше проходили незаметно, начинают конкурировать за ресурсы базы с обычной бухгалтерской работой.

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

как это решили и что изменилось после переноса логики на сервер

Логику вынесли на отдельный сервер: бэкенд синхронизируется с 1С раз в несколько минут пакетами, а не при каждом клике. Каталог и остатки кэшируются на самом устройстве, поэтому приложение открывается мгновенно даже при слабом интернете на выезде. Заказы, оформленные офлайн, встают в очередь и отправляются, как только появляется связь, без дублей и потерь. Такой пересмотр архитектуры обычно укладывается в развитие уже собранного приложения, а не требует переписывать его с нуля — меняется бэкенд, а не то, что видит менеджер на экране.

Для такого сценария мы обычно собираем B2B-приложение с 1С: фронтенд под задачи менеджеров и отдельный бэкенд, который берёт на себя всю связь с базой. Если готового API ещё нет, отдельно закрываем интеграцию приложения с 1С — без неё бэкенду просто не с чем синхронизироваться.

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

признаки, что вашему приложению уже нужен полноценный бэкенд

• ✓в демо-версии всё работает быстро, а с реальным каталогом и десятком пользователей приложение тормозит или зависает;
• ✓заказы иногда дублируются или пропадают при нестабильном интернете на выезде;
• ✓1С подвисает именно тогда, когда приложением одновременно пользуется несколько сотрудников;
• ✓логика авторизации и доступа зашита прямо в код приложения, а не вынесена в отдельный сервис;
• ✓нет истории — кто, когда и что менял, если заказ разошёлся с фактической отгрузкой.

во что обходится компания, если тянуть с решением

Пока компания тянет с переносом логики на бэкенд, она платит дважды. Первый раз — временем кладовщика или бухгалтера, который вручную сверяет остатки после каждого сбоя синхронизации. Второй раз — упущенными заказами: если менеджер оформил заявку офлайн, а приложение потеряло её при разрыве связи, клиент уходит к тому, кто ответил быстрее. Для компании с 15 менеджерами в поле это не разовый инцидент, а повторяющийся риск на каждый рабочий день.

Если совпало хотя бы два пункта из списка, приложению нужен не косметический патч, а отдельный бэкенд-слой между экраном и 1С. Мы проектируем такие связки с расчётом на реальную нагрузку, а не на демо-каталог из сорока позиций: переделать архитектуру через полгода после запуска, когда бизнес уже завязан на приложение, обходится дороже, чем заложить бэкенд сразу.

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

Чем бэкенд отличается от фронтенда в мобильном приложении?

Фронтенд — это экраны, кнопки и формы, которые видит пользователь на телефоне. Бэкенд — серверная часть: код и база данных, которые проверяют права доступа, хранят состояние заказа и синхронизируют данные с 1С. Без бэкенда приложение может показывать интерфейс, но не умеет надёжно обрабатывать данные при росте нагрузки.

Можно ли обойтись без отдельного бэкенда и подключить приложение к 1С напрямую?

Технически можно, и для демо или пилота на 3-5 пользователях это работает. Но при росте числа сотрудников и каталога каждый запрос из приложения идёт прямо в боевую базу 1С без очереди и кэша, поэтому база подвисает, а заказы дублируются. Для рабочей нагрузки нужен отдельный бэкенд-слой.

Сколько стоит разработать бэкенд для мобильного приложения с 1С?

Разработка мобильного приложения с отдельным бэкендом начинается от 500 000 ₽ — цена зависит от числа интеграций, офлайн-режима и сложности синхронизации с 1С. Дополнительно нужен сервер для бэкенда: аренда от 1 100 ₽ в месяц за пользователя. Точную стоимость считаем по техническому заданию.

Где физически размещается бэкенд приложения и нужен ли отдельный сервер?

Бэкенд работает на сервере — своём или арендованном, отдельно от рабочих компьютеров сотрудников. Мы подбираем конфигурацию сервера по системным требованиям 1С, чтобы синхронизация не тормозила ни базу, ни приложение. Аренда сервера для 1С начинается от 1 100 ₽ в месяц за пользователя.

Как понять, что текущему приложению уже нужен полноценный бэкенд?

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