Зачем API Gateway?

Контекст

Прежде чем писать код, важно понять, какую проблему мы решаем. Без API Gateway каждый клиент (веб-приложение, мобильное приложение, партнёрская интеграция) должен знать адреса всех backend-сервисов и самостоятельно реализовывать общую логику: добавление токенов, обработку ошибок, повторные попытки. Это как если бы пассажир при каждом перелёте должен был самостоятельно связываться с диспетчером, пилотом, службой безопасности и багажным отделением, вместо того чтобы пройти регистрацию в аэропорту.

Ключевая концепция: паттерн API Gateway

API Gateway — это единая точка входа для всех клиентов. Вместо того чтобы клиент общался напрямую с десятком микросервисов, он отправляет все запросы на один адрес. Gateway принимает запрос, определяет, какому сервису он предназначен, и перенаправляет его.

Реальные примеры:

• Netflix Zuul/Gateway — обрабатывает миллиарды запросов в день
• Kong — популярный open-source gateway на базе Nginx
• AWS API Gateway — управляемый сервис для serverless архитектур
• Nginx — часто используется как простой Reverse Proxy

Зачем это нужно:

• Единая точка входа — клиент знает только один адрес
• Инкапсуляция — внутренняя структура сервисов скрыта от клиента
• Гибкость — можно менять backend без изменения клиента

Ключевая концепция: Сквозная функциональность

Сквозная функциональность — это функциональность, которая нужна везде, но не относится к бизнес-логике конкретного сервиса. Примеры:

• Аутентификация и авторизация
• Rate limiting (ограничение количества запросов)
• Логирование и трейсинг
• CORS заголовки
• Кэширование

Без gateway каждый сервис должен реализовывать эту логику самостоятельно. С gateway — она централизована в одном месте. Это как пост охраны на входе в бизнес-центр: проверяет пропуска, записывает посетителей, следит за порядком — и делает это для всех офисов сразу.

Цели этапа

Зачем: Зафиксировать архитектурное решение о введении API Gateway в README до написания кода — чтобы иметь ясное представление о роли gateway и его функциях.

Что делаем:

Обновите README.md проекта. Добавьте в него:

1. Роль API Gateway — опишите, зачем нужен gateway как единая точка входа (своими словами, на основе изученного материала)
2. Сквозные функции — перечислите, какие задачи gateway будет решать централизованно: CORS, rate limiting, structured logging, caching, маршрутизация
3. Архитектура — опишите, как gateway связывает клиента с backend-сервисами (auth-service, books-service, worker-service)

Пример работы

Сравнение архитектуры без gateway и с gateway:

Без API Gateway:

Frontend ──┬── auth-service:8081/api/v1/auth/login
           ├── auth-service:8081/api/v1/users/me
           ├── books-service:8082/api/v1/books
           └── books-service:8082/api/v1/books/123/reviews

С API Gateway:

Frontend ──── gateway:8000/api/v1/* ──┬── auth-service:8081
                                      └── books-service:8082

Frontend знает только gateway:8000, всё остальное — внутренняя кухня.