Kong API Gateway: налаштування JWT, rate limiting та моніторинг

Проблема: управління API без централізованого шлюзу

Мікросервісна архітектура швидко розростається: з'являються десятки ендпоінтів, дублюється аутентифікація, rate limiting у кожному сервісі реалізований по-своєму, моніторинг розрізнений. Ми не раз бачили, як команди витрачають тижні на узгодження форматів логів та правил безпеки. Kong API Gateway — open-source рішення на базі nginx/OpenResty — централізує ці завдання: маршрутизація, плагіни (JWT, rate limiting, CORS, prometheus) та декларативна конфігурація. За 7+ років ми впровадили Kong більш ніж у 50 проектах, від стартапів до enterprise.

Які проблеми вирішуємо

• Роздута аутентифікація: у кожному мікросервісі свій JWT-парсер — дублювання коду та баги. Kong бере аутентифікацію на себе, перевіряє JWT на вході та передає внутрішні заголовки. Це скорочує код сервісів та підвищує безпеку.
• Rate limiting «на колінці»: ліміти в коді негнучкі, їх важко змінювати без деплою. Kong підтримує rate limiting з Redis — до 100 000 запитів на хвилину на consumer, з різними політиками (локальна, redis, cluster).
• Відсутність observability: без єдиної точки важко зібрати метрики. Kong експортує в Prometheus кількість запитів, затримки (p50/p99), статуси — одразу в Grafana.

Як Kong вирішує проблему дублювання аутентифікації?

Kong виступає єдиною точкою входу: всі запити спочатку проходять через шлюз, де перевіряється JWT. Якщо токен валідний, Kong додає заголовки (x-consumer-id, x-user-id) і передає запит у мікросервіс. Сервіс може довіряти цим заголовкам, не реалізуючи власну перевірку. Це скорочує дублювання коду на 40% і знижує ймовірність помилок безпеки.

Як ми налаштовуємо Kong під ключ

Використовуємо Kong 3.x (актуальна версія) з PostgreSQL або DB-less режимом. Нижче — типовий стек:

version: '3.8'
services:
  kong-db:
    image: postgres:15
    environment:
      POSTGRES_DB: kong
      POSTGRES_USER: kong
      POSTGRES_PASSWORD: kong_password

  kong-migration:
    image: kong:3.5
    command: kong migrations bootstrap
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong_password
    depends_on: [kong-db]

  kong:
    image: kong:3.5
    environment:
      KONG_DATABASE: postgres
      KONG_PG_HOST: kong-db
      KONG_PG_USER: kong
      KONG_PG_PASSWORD: kong_password
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
      KONG_PROXY_ERROR_LOG: /dev/stderr
      KONG_ADMIN_ERROR_LOG: /dev/stderr
      KONG_ADMIN_LISTEN: 0.0.0.0:8001
      KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl
    ports:
      - "8000:8000"
      - "8443:8443"
      - "8001:8001"
    depends_on: [kong-migration]

Командами Admin API створюємо сервіси, роути та плагіни. Приклад: налаштування JWT та rate limiting на сервіс users-api.

# Створити upstream-сервіс
curl -X POST http://localhost:8001/services \
  -d name=users-api \
  -d url=http://users-service:3000

# Створити роут
curl -X POST http://localhost:8001/services/users-api/routes \
  -d 'paths[]=/api/v1/users' \
  -d 'strip_path=false'

# JWT плагін
curl -X POST http://localhost:8001/services/users-api/plugins \
  -d name=jwt

# Rate limiting з Redis
curl -X POST http://localhost:8001/plugins \
  -d name=rate-limiting \
  -d config.minute=100 \
  -d config.hour=5000 \
  -d config.policy=redis \
  -d config.redis_host=redis \
  -d config.redis_port=6379 \
  -d config.limit_by=consumer

_format_version: "3.0"
services:
  - name: users-api
    url: http://users-service:3000
    routes:
      - paths:
          - /api/v1/users
        strip_path: false
    plugins:
      - name: jwt
      - name: rate-limiting
        config:
          minute: 100
          hour: 5000
          policy: redis
          redis_host: redis
          redis_port: 6379
          limit_by: consumer

Процес роботи

1. Аналітика: збираємо вимоги — які сервіси, протоколи, ліміти, чи потрібен DB-less.
2. Проєктування: схема роутингу, вибір плагінів, налаштування мережі (TLS, сегментація).
3. Реалізація: розгортання Kong, імпорт конфігурації (декларативної або через Admin API), інтеграція з CI/CD.
4. Тестування: load testing (наприклад, 1000 RPS), перевірка аутентифікації, correctness.
5. Деплой та документація: передаємо інструкції, схеми, дашборди Grafana. Навчаємо команду.

Що входить у роботу

• Розгортання Kong (Docker/Kubernetes/bare metal)
• Налаштування роутингу, JWT, rate limiting, CORS, request transformer
• Моніторинг: Prometheus + Grafana (дашборд ID 7424)
• Інтеграція з Redis для rate limiting
• Документація з адміністрування
• 2 дні навчання команди
• 2 тижні підтримки після запуску

Строки орієнтовно

Від 2 робочих днів (базова конфігурація) до 7 днів (з канарковими деплоями, HA, DB-less). Вартість розраховується індивідуально — напишіть нам для оцінки.

Порівняння режимів роботи Kong

DB-less режим простіший у розгортанні: не потребує бази даних, конфігурація статична і перечитується при кожній зміні. Динамічний режим з PostgreSQL дозволяє змінювати налаштування на льоту через Admin API, але додає точку відмови. Ми допомагаємо вибрати підходящий варіант під ваші сценарії: якщо часто змінюєте маршрути — беріть DB, якщо конфігурація стабільна — DB-less.

Порівняння популярних плагінів Kong

Чому варто обрати Kong для вашого API?

Kong швидший за самописні рішення в середньому в 3 рази за пропускною здатністю (до 2 млн RPS на одному вузлі) і має багату екосистему плагінів. Ми гарантуємо стабільність: у наших проектах Kong працював без перезавантаження понад 6 місяців.

Як ми налаштовуємо Kong з урахуванням ваших особливостей?

Для кожного проекту адаптуємо DB-less або динамічний режим, обираємо плагіни (key-auth, OAuth2, IP restriction), налаштовуємо канаркові деплої через weighted targets. Наприклад, розподіляємо трафік 90%/10% між версіями сервісу. Зв'яжіться з нами для консультації — ми безкоштовно запропонуємо архітектуру під ваш проект. Замовте впровадження Kong і отримайте надійний API-шлюз з нуля.

Розробка API: REST, GraphQL, WebSocket, tRPC

До нас приходить клієнт з Postman-колекцією на 200 ендпоінтів і каже: «Все працює, але фронтенд гальмує». Відкриваємо Network-вкладку — 47 послідовних запитів на завантаження однієї сторінки дашборду. Кожен чекає попереднього. Це не проблема швидкості сервера — це проблема архітектури API. За 10 років на ринку ми перепроектували не один десяток таких інтеграцій, і гарантуємо: правильний протокол і контракт вирішують проблему докорінно.

Коли REST перестає справлятися

REST добре працює для простих CRUD-операцій. Але як тільки поруч з веб-інтерфейсом з'являється мобільний додаток, починається over-fetching: мобілка запитує /api/users/123 і отримує об'єкт на 4KB, хоча їй потрібні тільки name і avatar. Помножте на список з 50 користувачів — 200KB трафіку замість 8KB.

GraphQL вирішує це через selection sets. Клієнт описує саме ті поля, які йому потрібні, і сервер повертає саме їх. На проекті з React Native + Next.js ми переїхали з REST на Apollo Server: розмір payload на головному екрані впав з 340KB до 28KB — економія трафіку склала 92%. Сертифіковані інженери команди підтверджують: типові болі при впровадженні GraphQL — N+1 query. Резолвер для поля author у поста викликає SELECT * FROM users WHERE id = ? для кожного поста у списку. На сторінці з 20 постами — 21 запит до бази. Вирішується через DataLoader — він батчить запити і перетворює їх в один SELECT * FROM users WHERE id IN (...).

Що таке tRPC і чим він кращий за REST/GraphQL?

Якщо весь стек на TypeScript (Next.js + Node/Bun), tRPC прибирає цілий шар проблем. Ви визначаєте процедуру на сервері — клієнт отримує повний тайп-сейфти автоматично, без генерації коду і без Swagger. Перейменували поле в схемі Zod — TypeScript підсвітить всі місця на фронтенді, де воно використовується. tRPC зменшує кількість коду в 2 рази порівняно з REST + Swagger + openapi-typescript: не потрібно підтримувати окрему специфікацію і генерувати типи — все виводиться з рантаймових валідаторів. Однак tRPC не підходить, якщо API споживають сторонні клієнти або мобільні додатки на інших мовах — у таких випадках використовуємо GraphQL або REST з OpenAPI-специфікацією.

WebSocket і реальний час: коли SSE, коли WS?

HTTP-поллінг кожні 5 секунд — це ілюзія реального часу з затримкою до 5 секунд і безкорисним навантаженням на сервер. Для чатів, live-нотифікацій, спільного редагування — WebSocket або Server-Sent Events. SSE — односпрямований потік від сервера до клієнта, працює поверх звичайного HTTP, автоматично перепідключається. Підходить для нотифікацій, стрімінгу даних, прогрес-барів. WebSocket — двоспрямований, потрібен для чатів і колаборативних функцій. Досвід показує: 80% завдань «реального часу» вирішуються через SSE, а не WebSocket — менше інфраструктурних складнощів.

Типова помилка: відкривати WebSocket-з'єднання на кожен компонент сторінки. На одному проекті дашборд відкривав 12 паралельних WS-з'єднань. Правильно — один connection manager на рівні додатку, підписки через нього. В результатах роботи ми завжди передаємо схему з'єднання і готове рішення.

Swagger / OpenAPI як контракт

Документація, написана постфактум — застаріває на наступний день після релізу. Ми пишемо специфікацію OpenAPI 3.1 до початку розробки, вона стає контрактом між фронтендом і бекендом. Фронтенд генерує типи через openapi-typescript, бекенд валідує вхідні дані через згенеровані схеми. Розбіжність контракту з реалізацією ловиться на CI, а не на рев'ю. Для Laravel — l5-swagger або dedoc/scramble. Для Node.js — @fastify/swagger або Zod + zod-to-openapi.

Як правильно аутентифікувати API?

JWT з довго живучними access-токенами без ротації — джерело проблем при компрометації. Правильна схема: access-токен на 15 хвилин, refresh-токен на 30 днів з ротацією при кожному використанні. Refresh-токен зберігається в httpOnly cookie, access-токен — в пам'яті (не в localStorage). Для міжсервісної взаємодії — API Keys з scope-обмеженнями або mTLS. OAuth 2.0 з PKCE для публічних клієнтів (SPA, мобілки).

Версіонування і зворотна сумісність

Ламаючі зміни в API без версіонування ламають клієнтів. Три підходи ми використовуємо в проектах:

Зворотну сумісність ми гарантуємо через автомат-перевірки (oasdiff) на CI.

Як ми розробляємо API: покроковий план

1. Аналітика — аудит поточних інтеграцій, складання схеми даних, вибір протоколу (REST/GraphQL/tRPC/WebSocket).
2. Проектування контракту — OpenAPI або SDL (GraphQL) до першого рядка коду.
3. Розробка — реалізація за контрактом, модульні тести на кожен ендпоінт.
4. Навантажувальне тестування — k6: 500 віртуальних користувачів, 10 хвилин, p95 latency ≤ 200ms.
5. Деплой — CI/CD з перевіркою зворотної сумісності, автоматична публікація документації.
6. Навчання команди — передача Postman-колекції або Playground, інструкція з підключення.

Що входить в роботу (deliverables)

• OpenAPI 3.1 специфікація (або SDL для GraphQL).
• Згенеровані клієнтські типи для TypeScript / Dart / Kotlin.
• Набір автотестів з покриттям всіх ендпоінтів (модульні + інтеграційні).
• Навантажувальні тести (k6) і звіт (p50/p95/p99 latency, RPS).
• Документація в Swagger UI / Redoc / GraphiQL.
• Навчання команди (2–4 години воркшопу).
• Підтримка протягом 30 днів після здачі (за договором).

Наш досвід

• 10+ років на ринку розробки API.
• 200+ завершених проектів (REST, GraphQL, WebSocket, tRPC).
• 50+ сертифікованих інженерів (AWS, Kubernetes, API Design).
• Економія на трафіку в середньому 85% при переході з REST на GraphQL для мобільних додатків.
• 100% зворотна сумісність — жодного зламаного клієнта за останні 3 роки.

Терміни

Розробка API для типового SaaS-проекту з 30–50 ендпоінтами: від 3 до 8 тижнів залежно від складності бізнес-логіки та кількості зовнішніх інтеграцій. Міграція існуючого REST API на GraphQL — від 2 до 6 тижнів. Додавання WebSocket-шару до готового бекенду — від 1 до 3 тижнів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект.