Налаштування 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 тижні.