Настройка API Gateway для мобильного приложения
Мобильный клиент не должен знать, что за ним стоит пять разных сервисов, три команды и две БД. API Gateway — точка входа, которая берёт на себя аутентификацию, роутинг, rate limiting и трансформацию ответов, разгружая сами сервисы от инфраструктурного кода.
Что решает Gateway, а что нет
Gateway хорош для: единого TLS-терминирования, JWT-валидации без дублирования в каждом сервисе, rate limiting по IP и по токену, версионирования API (/v1, /v2), логирования всех входящих запросов.
Gateway не замена бизнес-логике. Агрегацию нескольких сервисов в один ответ лучше делать в BFF (Backend for Frontend) — отдельном сервисе под конкретный клиент. Gateway — не место для if (user.isPremium) { ... }.
Варианты и выбор
| Решение | Когда подходит | Особенности |
|---|---|---|
| Kong | Kubernetes, много плагинов, self-hosted | Декларативная конфигурация через CRD, плагины для OAuth2/JWT/rate-limit из коробки |
| AWS API Gateway | Инфраструктура в AWS | Нативная интеграция с Lambda, Cognito, WAF; платно за запросы |
| Traefik | Kubernetes-native, GitOps | Автоматический service discovery, cert-manager интеграция |
| Nginx + njs | Простой случай, минимальный overhead | Скриптуется на JavaScript, но сложнее масштабировать конфигурацию |
| Custom Go service (BFF) | Агрегация данных, нестандартная логика | Полный контроль, но нужно поддерживать |
Для большинства мобильных проектов с Kubernetes — Kong или Traefik. Для AWS-среды — AWS API Gateway с Lambda authorizer.
Ключевые настройки для мобильного клиента
Rate limiting. Два уровня: по IP (защита от DDoS) и по токену (защита от багов на клиенте, retry storm). Kong plugin rate-limiting: 100 req/min на анонимный IP, 1000 req/min на аутентифицированного пользователя. При превышении — 429 Too Many Requests с заголовком Retry-After.
JWT validation. Gateway проверяет подпись и срок действия токена, передаёт X-User-ID и X-User-Role в upstream. Сервисы доверяют этим заголовкам без повторной проверки подписи — это убирает jsonwebtoken зависимость из каждого сервиса.
Timeouts. Connect timeout — 5 секунд, read timeout — 30 секунд. Если upstream не ответил — Gateway возвращает 504 Gateway Timeout, а не висит. Мобильный клиент получает явную ошибку и может показать пользователю понятное сообщение.
Circuit breaker на уровне Gateway. Kong plugin proxy-cache + health-check: при 50% ошибок за 10 секунд Gateway перестаёт слать запросы в нездоровый upstream и возвращает кеш или 503.
Кейс: e-commerce приложение, 5 бэкенд-сервисов. До Gateway каждый сервис валидировал JWT самостоятельно: 5 копий кода, обновление секрета требовало деплоя всех пяти. После Kong: JWT-плагин в одном месте, X-User-ID прокидывается хедером, время валидации токена — до 2ms на Gateway вместо 15–20ms в каждом сервисе.
Сроки настройки: базовая конфигурация Gateway с роутингом, JWT, rate limiting — 3–5 дней. Полноценная настройка с мониторингом, WAF, CI/CD для конфигурации — 2–3 недели.