Бэкенд и API для мобильного приложения

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

Чем API отличается от бэкенда

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

Аналогия из ресторана: официант принимает заказ и приносит блюдо, но готовят на кухне. Официант — это API, кухня — бэкенд. Клиент никогда не заходит на кухню напрямую и не знает, в каком порядке там работают.

Одно нажатие кнопки «Оформить заказ» превращается на сервере в цепочку действий:

• проверить, что пользователь авторизован и ему можно оформлять заказ;
• сверить наличие товаров и актуальные цены, а не те, что лежали в приложении;
• посчитать доставку, скидку и итоговую сумму;
• создать заказ и платёж у платёжного провайдера;
• передать заказ в CRM и в учётную систему;
• отправить уведомление клиенту и сотруднику.

Приложение из этой цепочки видит только результат. Поэтому список методов API описывают вместе со сценариями пользователя — на этапе проектирования, а не когда экраны уже нарисованы. Как это встроено в проект целиком, разобрано в статье о разработке приложения для iOS и Android.

Из чего состоит серверная часть

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

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

Как устроены вход и права доступа

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

• Вход по номеру телефона с одноразовым кодом в SMS или в Telegram — самый частый вариант для местного рынка.
• Вход по почте и паролю: на сервере хранится не пароль, а его хеш, восстановление идёт по одноразовой ссылке.
• Вход по биометрии — на устройстве: телефон подтверждает лицо или отпечаток и открывает сохранённый токен. Сервер биометрию не получает и не хранит.
• Корпоративная учётная запись — для внутренних приложений, когда сотрудники входят через единую систему компании.

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

Отдельный метод нужен для удаления аккаунта: правило 5.1.1(v) App Store Review Guidelines требует, чтобы в приложении с регистрацией можно было удалить аккаунт. Удаление затрагивает и связанные данные, поэтому его продумывают на этапе схемы базы, а не перед отправкой в магазин.

Платежи: что делает сервер, а что провайдер

Оплату принимает платёжный провайдер, а не ваш бэкенд. Сервер создаёт платёж у провайдера, получает от него подтверждение и меняет статус заказа. Карточные данные при этом не проходят через приложение и не хранятся у вас.

1. Приложение просит сервер создать заказ и получить параметры оплаты.
2. Сервер пересчитывает сумму по своим данным и создаёт платёж у провайдера.
3. Клиент подтверждает оплату на стороне провайдера: на его странице, в его форме или по сохранённой карте.
4. Провайдер сообщает серверу результат, сервер проверяет подпись запроса и сверяет сумму.
5. Сервер меняет статус заказа, отправляет уведомление и передаёт данные в учётную систему.

Так устроены и местные сервисы: у Payme привязка карты и списания выполняются клиентскими методами Subscribe API, а подтверждение платежа сервер получает от провайдера, а не от приложения. Доверять статусу, который прислал клиент, нельзя: приложение на чужом телефоне можно изменить.

Интеграции: CRM, 1С и внешние сервисы

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

• Регистрация в приложении создаёт контакт в CRM, заявка — сделку, оплата двигает её на следующий этап.
• Каталог, цены и остатки приходят из учётной системы и обновляются по расписанию или по событию.
• Документы и чеки формируются в учётной системе и становятся доступны в личном кабинете.
• Служба доставки получает заказ и возвращает статус и трек-номер.
• Телефония и мессенджеры связывают обращение клиента с его карточкой.
• Аналитика собирает события приложения и связывает их с продажами.

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

Безопасность серверной части

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

• Весь обмен идёт по HTTPS. В Android начиная с версии 9 (API 28) открытый HTTP отключён по умолчанию, и обходить это исключениями не нужно.
• Токен доступа живёт недолго и обновляется по отдельному токену; оба хранятся в защищённом хранилище устройства.
• Каждый метод API проверяет роль пользователя и принадлежность данных, а не полагается на скрытые элементы интерфейса.
• Входящие данные проверяются на сервере: типы, границы значений, размер файлов, количество элементов.
• Стоят ограничения на частоту запросов и на попытки входа, чтобы перебор кодов не работал.
• Действия с данными пишутся в журнал: кто, что и когда изменил.
• Резервные копии делаются ежедневно, и восстановление из них регулярно проверяется.
• Библиотеки и системные пакеты обновляются, а список зависимостей известен и пересматривается.

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

Где размещать сервер и что требует закон

Место размещения бэкенда — не только вопрос скорости. Для приложений, которые работают с данными граждан Узбекистана, оно определяется законом.

Важно По статье 27-1 закона «О персональных данных» в редакции ЗРУ-1125 от 26 марта 2026 года обязательному хранению на территории Узбекистана подлежат биометрические и генетические данные, а также данные абонентов операторов связи. Остальные персональные данные можно обрабатывать за рубежом при соблюдении условий той же статьи, а в Государственном реестре регистрируют только базы с данными, для которых хранение в Узбекистане обязательно.

Для трансграничной передачи Кабинет Министров постановлением № 415 от 29 июля 2026 года, действующим с 3 августа 2026 года, утвердил перечень иностранных государств с адекватной защитой персональных данных. Прежде чем выбирать зарубежное облако, проверьте, входит ли страна провайдера в этот перечень: от этого зависит, какие условия придётся выполнить.

Практический вывод: если приложение хранит данные клиентов, размещение внутри страны снимает часть вопросов сразу. Мы держим серверы в дата-центре в Узбекистане — сервер под сайт или CRM от 30 $ в месяц, с резервным копированием и мониторингом.

Как проходит разработка бэкенда

Серверную часть делают параллельно с интерфейсом, но начинают раньше: без описанных методов API мобильной команде нечего вызывать.

1. Разбор требований: сценарии, роли, правила расчётов, список внешних систем.
2. Проектирование: схема данных, состав методов API, форматы ответов и ошибок.
3. Разработка базы данных: таблицы, связи, индексы, правила хранения и удаления.
4. Разработка методов API и бизнес-логики с автоматическими тестами на ключевые сценарии.
5. Подключение интеграций: платежи, CRM, учётная система, уведомления, карты.
6. Тестирование: логика, права доступа, поведение под нагрузкой, восстановление из копии.
7. Развёртывание, мониторинг и передача документации по API мобильной команде.

Готовый API описывают документацией, по которой можно работать без разработчика рядом: адрес метода, параметры, пример запроса и ответа, коды ошибок. Эта документация остаётся у заказчика и позволяет сменить подрядчика без переписывания сервера.

Как мы делаем серверную часть

Мы в Syntra Systems начинаем с сценариев и схемы данных, а не с фреймворка. Описываем методы API вместе с мобильной командой, закладываем права доступа и журналирование сразу, а интеграции с CRM и платёжными системами проверяем на тестовом контуре до релиза.

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

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