Каталог есть, заказ не уходит в 1С: с чего начать бэк мобильного магазина

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

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

Заказчик присылает макет из Figma — три экрана: каталог, корзина, оплата — и просит оценить, сколько будет стоить «вот такое приложение». В переписке ни слова про бэкенд: он в голове заказчика уже существует, потому что «данные же есть в 1С».

На первом созвоне выясняется другое: обмен с 1С настроен только для сайта на Bitrix через выгрузку раз в сутки, а мобильного API нет вообще. Веб-сервисы в конфигурации не опубликованы, права доступа для внешних клиентов не заведены, и открыть базу наружу без доработки нельзя.

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

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

как исправить: с чего реально начинается архитектура e-commerce приложения

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

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

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

что фронт не должен делать никогда

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

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

что делать, если ошибка повторяется: бэкенд снова недооценен на этапе ТЗ

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

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

Если пропустить пересчёт бэкенда и просто добавить экран поверх старого API, два контрагента через один и тот же кэш могут увидеть чужие цены. Это уже не испорченное впечатление, а разглашение коммерческих условий одного клиента другому — с претензией и репутационными последствиями, которые не покрываются переделкой интерфейса за вечер. В опте, где скидка одному дилеру ниже, чем другому, такая утечка стоит дороже самого проекта.

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

🔒 как предотвратить: интеграция с 1С с первого спринта, а не в конце

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

что проверить в первом спринте

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

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

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

💰 сколько стоит бэкенд отдельно от фронта и как выбрать архитектуру

На старте есть три рабочих варианта бэкенда для мобильного e-commerce приложения, и они сильно расходятся по цене, срокам и тому, как ведут себя под нагрузкой. Выбор между ними определяет не только бюджет разработки, но и то, во что упрётся магазин через год роста трафика.

Разработка мобильного e-commerce приложения с интеграцией с 1С начинается от 500 000 рублей — сумма зависит от того, какой из трёх вариантов бэкенда выбран, и от количества бизнес-процессов, которые нужно перенести из 1С в API. На старте проекта эту сумму не называют вслепую: сначала считают конкретные эндпоинты и нагрузку, а не берут цифру «на глаз» по количеству экранов. Актуальные условия расчёта — на странице цены и тарифы.

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

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

Цена начинается от 500 000 рублей и зависит от выбранной архитектуры бэкенда — 1С:Мобильная платформа, REST-обвязка над существующей базой или отдельный сервис — и от количества бизнес-процессов, которые переносят из 1С в API.

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

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

Что такое 1С:Мобильная платформа и когда её стоит использовать?

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

Как быстро можно проверить, готова ли 1С к мобильной интеграции?

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

Нужно ли отдельно согласовывать хранение персональных данных покупателей в приложении?

Да. Если приложение хранит имя, телефон и адрес доставки, действуют требования 152-ФЗ: нужны политика хранения, согласие на обработку данных прямо в приложении и понимание, на каком сервере физически лежит база.