Backend для мобильного приложения: что нужно знать заказчику

Роль backend в мобильном продукте

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

В контракте и ТЗ следует чётко прописать: какие операции выполняет сервер, какие данные хранятся, какие интеграции требуются (платежи, обмен с CRM/ERP, пуш‑сервисы), и требования по SLA и защите персональных данных.

Архитектура и выбор технологий

Выбор архитектуры зависит от ожидаемой нагрузки, сроков и бюджета. Для MVP обычно достаточно монолита с API‑слоем; для продукта с ростом — микросервисы, событийная шина и независимые базы данных. Ключевые критерии: скорость разработки, стоимость поддержки, готовность к горизонтальному масштабированию.

• Монолит — быстрее старт, дешевле MVP, сложнее масштабировать отдельно функционал
• Микросервисы — гибкость и независимость команд, выше сложность DevOps
• Языки/фреймворки — Node.js/Express, Python/Django, Go, Java/Spring — выбирать по компетенциям команды
• Базы данных — PostgreSQL для транзакций, Redis для кеша и очередей, MongoDB для гибкой модели
• Развёртывание — контейнеры (Docker) + оркестратор (Kubernetes) для масштабируемости

API: контракты, версияция и формат данных

API — главный интерфейс между мобильным приложением и сервером. Для надёжной интеграции нужен документированный контракт (OpenAPI/Swagger), правила версияции и лимиты по размерам/скорости запросов. Прописать контракт в ТЗ — экономия времени для обеих команд.

• Документация API в OpenAPI 3.0 и мок‑сервер для параллельной разработки
• Версия API в пути (/v1/) и совместимость при изменениях
• Использовать сжатие (gzip) и минимизировать payload — важно для мобильных сетей
• Валидация входных данных на сервере и понятные коды ошибок
• Лимит запросов и механизмы throttling для защиты от перегрузки

Безопасность и аутентификация

Безопасность — одна из ключевых задач заказчика. Обязательно требовать шифрование транспорта (TLS 1.2+), хранение чувствительных данных в зашифрованном виде, регулярные бэкапы и ревью зависимостей. Для российских проектов учитывать требования 152‑ФЗ при работе с персональными данными.

• Аутентификация — OAuth2 / OpenID Connect или JWT с коротким TTL и refresh
• Двухфакторная аутентификация для критичных операций
• Шифрование данных на диске и в резервных копиях, управление ключами
• WAF, ограничение доступа по IP/geo и мониторинг подозрительных действий
• Регулярные pentest и обновление зависимостей по CVE

Масштабирование и производительность

Оценить нагрузки в RPS (запросы в секунду) и объём данных. Для достижения отклика <200–300 мс важны кеширование на уровне Redis, CDN для статики и оптимизация запросов к базе (индексы, шардирование). Горизонтальное масштабирование сервисов и асинхронная обработка тяжёлых задач снижает пиковую нагрузку.

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

Эксплуатация, мониторинг и бюджет

Эксплуатация включает CI/CD, мониторинг, логирование и инцидент‑менеджмент. Ключевые метрики: latency, error rate, p95/p99, Liveness/Readiness. Инструменты — Prometheus/Grafana, ELK или ClickHouse для логов, Sentry для ошибок.

Бюджет на поддержку обычно 15–40% от стоимости разработки в год в зависимости от SLA. В контракте прописать RTO/RPO, количество инцидентных часов в месяце, сроки исправления критических дефектов и порядок передачи исходников/документации.