30 сотрудников синхронизируются в 9 утра: бэкенд на Go для приложения с 1С

Go для мобильной разработки — это не замена Swift или Kotlin в интерфейсе, а язык бэкенда и общей бизнес-логики мобильного приложения: он выдерживает всплеск одновременных запросов при синхронизации с 1С без роста нагрузки на сервер, а через gomobile один и тот же код офлайн-очереди компилируется в библиотеку для iOS и Android.

🧭 Где в мобильной разработке на самом деле работает Go

Формулировка «Go для мобильной разработки» сбивает с толку: нативный интерфейс на iOS пишут на Swift, на Android — на Kotlin, кроссплатформенные варианты берут Flutter или React Native. Go в эту тройку не встаёт — он туда и не метит. У него два реальных применения в мобильном проекте.

Первое — бэкенд, к которому обращается приложение: API, шлюз до 1С, очередь заявок, пуш-уведомления. Второе — общий код бизнес-логики, который через инструмент gomobile компилируется в .framework для iOS и .aar для Android: один и тот же алгоритм офлайн-очереди, шифрования токена доступа или дедупликации заказов при плохой связи в разъездах работает одинаково на обеих платформах, без двух параллельных реализаций, которые рано или поздно разойдутся в поведении.

☕ Утро понедельника: где ломается синхронизация

Отдел продаж торговой компании — 30 представителей, у каждого в кармане планшет с приложением заказов, связанным с 1С. В 9:00 все выходят на маршрут и открывают приложение одновременно: нужно скачать актуальные остатки и цены, отправить заказы, принятые накануне вечером офлайн. Тридцать одновременных сессий — не нагрузка для банковского процессинга, но для однопоточного бэкенда на Node.js или для Python с классическим WSGI-сервером это уже очередь: запросы обрабатываются один за другим, а не параллельно.

Но пока один представитель ждёт ответа сервера несколько секунд, следующий уже повторно жмёт «отправить», и в 1С прилетают два одинаковых документа заказа с разными временными метками. Кладовщик видит задвоенную позицию, списывает товар дважды, потом полдня разбирается, где реальный остаток, а где ошибка синхронизации.

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

⚖️ Три варианта бэкенда — что действительно различается

Разница между Go, Node.js и Python на этом сценарии не в синтаксисе, а в том, как каждый рантайм ведёт себя под тридцатью параллельными клиентами и что это значит для сервера, на котором крутится бэкенд.

Для мобильного B2B-приложения, где пик нагрузки приходится на начало и конец смены, а не размазан равномерно по дню, это не теория: один и тот же арендованный сервер тянет Go-бэкенд с запасом, а для Node.js или Python под ту же нагрузку обычно берут тариф на уровень выше — либо мирятся с очередями по утрам.

🔁 Общий код на телефоне: что даёт gomobile

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

gomobile позволяет написать этот кусок логики один раз на Go, собрать как библиотеку и подключить в оба проекта. Меняется поведение очереди — меняется код в одном месте, а не в двух. Для команды это не вопрос моды на язык, а вопрос того, что QA проверяет одну реализацию, а не гоняется за расхождениями между платформами.

💰 Цена бездействия

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

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

🛠️ Как мы это делаем в проектах ukved

В своих проектах мы ставим Go на роль шлюза между мобильным клиентом и 1С: он принимает заявки от приложения, кладёт их в очередь, подтверждает запись в 1С и только после этого отвечает клиенту «принято» — задвоения так не проходят. Для офлайн-сценариев, где логика должна быть идентичной на iOS и Android, выносим её в общий модуль через gomobile.

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

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

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

Значит ли это, что всё мобильное приложение пишут на Go?

Нет: интерфейс на iOS и Android по-прежнему делают на Swift, Kotlin или Flutter — Go туда не встраивают. Он закрывает бэкенд, который синхронизирует приложение с 1С, и через gomobile — общий код офлайн-логики, одинаковый для обеих платформ.

Есть смысл ставить Go, если у нас пока 5-10 пользователей приложения, а не 30?

Да: при таком объёме разница в нагрузке не критична для любого стека, но если команда будет расти, бэкенд на Go не придётся переписывать при увеличении числа сотрудников — он работает с запасом и сейчас, и при выросшей нагрузке через год.

Сколько стоит мобильное B2B-приложение с бэкендом на Go и интеграцией с 1С?

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

Можно ли заменить бэкенд на Node.js или Python на Go, не переделывая само приложение?

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

Как Go взаимодействует с 1С — напрямую или через посредника?

Через HTTP-сервис 1С или OData: Go-бэкенд выступает шлюзом, кладёт входящие заявки в очередь, повторяет попытку записи при сбое и только после подтверждения от 1С отвечает мобильному приложению, что заказ принят.