Для большинства мобильных приложений рациональный выбор — REST: он дешевле в разработке, проще в поддержке и не требует редких специалистов. GraphQL оправдан, когда у продукта сложная модель данных, десятки разных экранов и команда от трёх backend-разработчиков. Ниже — конкретные критерии выбора, цены для Казахстана и ошибки, которые мы видим на аудитах чужих проектов.

Почему выбор протокола API определяет экономику приложения

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

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

REST: что он даёт мобильному клиенту и где мешает

REST — это набор HTTP-эндпоинтов, каждый из которых отвечает за свой ресурс: GET /orders, POST /orders, GET /orders/57. Подход живёт с 2000 года, и в этом его главная сила: предсказуемость.

Сильные стороны REST

  • HTTP-кеширование из коробки. CDN, ETag, заголовки Cache-Control работают без дополнительного кода — для каталогов, справочников и контентных экранов это бесплатное ускорение.
  • Любой разработчик в Алматы его знает. Найти, заменить или усилить человека в команде — вопрос недель, а не месяцев.
  • Простая отладка. Один URL — один запрос — один код ответа. Логи, мониторинг, rate limiting и WAF настраиваются стандартными средствами.
  • Файлы и медиа. Загрузка фото и видео через multipart — родной сценарий для REST, в GraphQL это всегда обходное решение.

Где REST начинает мешать

  • Over-fetching. Эндпоинт возвращает полный объект, а экрану нужно три поля. На 4G в регионах Казахстана это ощутимо: лишние килобайты на каждый запрос.
  • Under-fetching. Сложный экран собирается из 4–6 запросов подряд — водопад, который растягивает загрузку до секунд.
  • Версионирование. Когда у клиента в сторе живут версии за два года, приходится тащить /v1, /v2, /v3 одновременно.

Первые две проблемы в мобильной разработке решаются паттерном BFF (Backend for Frontend): отдельный тонкий слой, который собирает данные под конкретный экран. Это дешевле перехода на GraphQL и закрывает 80% его преимуществ.

GraphQL: что меняется и какова цена

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

Реальные преимущества

  • Один запрос на экран вместо водопада — заметно быстрее на медленных сетях.
  • Схема как контракт: мобильные разработчики генерируют типобезопасный код из схемы, расхождения ловятся на компиляции, а не в проде.
  • Эволюция без версий: новые поля добавляются, старые помечаются deprecated — /v2 не нужен.
  • Подписки (subscriptions) для реалтайма: чаты, статусы заказов, котировки.

Скрытая стоимость, о которой молчат туториалы

  • Кеширование надо строить руками. Все запросы идут POST на один URL — CDN и HTTP-кеш слепнут. Нужен нормализованный кеш на клиенте (Apollo, Relay) и persisted queries на сервере.
  • Безопасность сложнее. Злоумышленник может прислать запрос глубиной в 20 уровней и положить базу. Обязательны лимиты глубины и стоимости запроса — это отдельная работа.
  • Проблема N+1. Без DataLoader каждый вложенный список превращается в шквал SQL-запросов. Мы видели проекты, где «быстрый» GraphQL отвечал по четыре секунды именно из-за этого.
  • Кадры. Backend-разработчиков с боевым опытом GraphQL в Казахстане в разы меньше, чем REST-специалистов, и ставка у них выше.

Сравнение REST и GraphQL: таблица

Критерий REST GraphQL
Скорость первого релиза Быстрее: меньше инфраструктурной работы Дольше: схема, кодогенерация, лимиты
Трафик и скорость экранов Over-fetching, водопады запросов Один запрос на экран, точная выборка полей
Кеширование HTTP/CDN из коробки Только прикладное, требует настройки
Загрузка файлов Нативно (multipart) Обходные решения или отдельный REST-эндпоинт
Реалтайм Отдельно: WebSocket/SSE Subscriptions в стандарте
Эволюция API Версионирование /v1, /v2 Deprecated-поля без версий
Доступность специалистов в KZ Высокая Ограниченная, ставки выше
Стоимость разработки от 1 800 000 ₸ от 2 600 000 ₸

Чек-лист: когда что выбирать

Выбирайте REST, если:

  • это MVP или приложение с 10–25 экранами стандартной структуры: каталог, карточка, корзина, профиль;
  • бэкенд-команда — один-два разработчика;
  • важна интеграция с внешними системами — банки, 1С, маркетплейсы говорят на REST. Например, интеграция Kaspi Pay в приложение — это чистый REST-обмен, и городить поверх него GraphQL-обёртку нет смысла;
  • контент хорошо кешируется: новости, меню, расписания, справочники.

Выбирайте GraphQL, если:

  • у приложения сложный граф данных: соцсеть, маркетплейс с продавцами, отзывами и вариациями, B2B-платформа;
  • один бэкенд обслуживает iOS, Android, веб и партнёрский API — и каждому нужны разные срезы данных;
  • продукт будет активно меняться годами и боль версионирования наступит неизбежно;
  • в команде уже есть инженер с опытом эксплуатации GraphQL под нагрузкой.

Рабочий компромисс — гибрид: GraphQL для чтения сложных экранов, REST для платежей, загрузки файлов и вебхуков. Отдельный случай — каналы событий: какой бы протокол вы ни выбрали, доставка уведомлений пользователю идёт через FCM и APNs, и проектировать её нужно отдельно — как именно, мы разобрали в статье про push-уведомления в приложении.

Сколько стоит разработка API в Казахстане в 2026 году

Ориентиры по рынку Алматы для бэкенда мобильного приложения (без стоимости самих мобильных клиентов):

  • REST API для MVP — 15–25 эндпоинтов, авторизация по JWT, документация OpenAPI, деплой: от 1 800 000 до 3 500 000 ₸, 4–7 недель.
  • BFF-слой поверх существующего бэкенда — агрегация данных под экраны: от 1 200 000 ₸, 3–4 недели.
  • GraphQL-сервер — схема, DataLoader, persisted queries, лимиты глубины, кодогенерация для клиентов: от 2 600 000 до 5 000 000 ₸, 6–10 недель.
  • Реалтайм-канал (WebSocket или subscriptions) — от 600 000 ₸ дополнительно.
  • Поддержка и развитие API — от 250 000 ₸/мес за выделенные часы backend-инженера.

Разница в 30–45% между REST и GraphQL — это не «наценка за модность», а реальные человеко-часы на инфраструктуру: кеш, безопасность, мониторинг резолверов. Если эти часы не заложены в смету, вы получите GraphQL, который медленнее и дырявее обычного REST.

Как мы принимаем это решение в Applications.kz

Студия работает с 2007 года, за плечами 300+ проектов в Казахстане, ОАЭ и Таиланде, поэтому решение мы принимаем не по статьям из интернета, а по короткой процедуре на этапе проектирования:

  1. Считаем карту экранов и запросов: сколько источников данных нужно каждому экрану.
  2. Оцениваем граф данных: если связей «многие-ко-многим» меньше трёх — почти всегда REST или REST+BFF.
  3. Смотрим на команду заказчика: кто будет жить с этим API после нас.
  4. Закладываем нагрузочный профиль: пики, медленные сети в регионах, офлайн-режим.

Итог фиксируем в архитектурном документе вместе со сметой — заказчик видит, за что платит каждый тенге. Если вы выбираете стек для своего продукта, оставьте заявку на странице заказа разработки приложения или позвоните по номеру +7 (707) 928-13-15 — подготовим смету и рекомендацию по архитектуре за 24 часа.

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

Можно ли начать с REST и позже перейти на GraphQL?

Да, и это здоровая стратегия для MVP. Чтобы переход не стал второй разработкой, изолируйте сетевой слой в мобильном клиенте (repository-паттерн) и держите бизнес-логику на сервере, а не в эндпоинтах. Тогда GraphQL добавляется как фасад поверх существующих сервисов, и клиенты мигрируют экран за экраном без остановки релизов.

GraphQL быстрее REST?

Сам по себе — нет. GraphQL сокращает число запросов и объём данных, но без DataLoader и продуманных резолверов легко работает медленнее REST. Корректная формула: GraphQL быстрее на сложных экранах при грамотной реализации, REST быстрее на простых и кешируемых данных. Скорость определяет инженерия, а не аббревиатура протокола.

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

Для типового e-commerce в Казахстане — REST, в отдельных случаях с BFF-слоем. Платёжные провайдеры, СМС-шлюзы и службы доставки предоставляют REST-API и вебхуки, каталог отлично кешируется через CDN, а структура экранов предсказуема. GraphQL здесь добавит стоимости, но не добавит скорости.

Сколько времени занимает проектирование API до старта разработки?

В нашей практике — одна-две недели: карта экранов, схема данных, контракт эндпоинтов или GraphQL-схема, план версионирования и безопасности. Это 5–7% бюджета проекта, которые страхуют от переделок стоимостью в треть бюджета на втором году жизни продукта.

Нужен ли GraphQL, если приложение только под iOS?

Почти никогда. Главная экономия GraphQL — обслуживание нескольких разных клиентов одной схемой. Один клиент с командой из пары разработчиков получит те же результаты от аккуратного REST с BFF, но без затрат на инфраструктуру кеширования и защиты запросов.