🔀❌ API Gateway нужен не всегда: 6 способов организовать вход в Backend 🔀❌
API Gateway — это компонент архитектуры, который выступает единой точкой входа для клиентских запросов к backend-системе и перенаправляет их в нужные внутренние сервисы.
Ключевые задачи:
▫️ маршрутизация запросов
▫️ аутентификация и авторизация
▫️ ограничения нагрузки (rate limiting)
▫️ единые логирование и мониторинг
▫️ преобразования запросов/ответов,
▫️ агрегация данных из нескольких сервисов.
При этом API Gateway не владеет данными и не управляет бизнес-процессами. Это его особенность.
На архитектурных схемах перед микросервисами часто "по умолчанию" появляется API Gateway.
✅ Есть микросервисы? Значит, нужен API Gateway.
❌ Но это не обязательное правило.
API Gateway — только один из способов организовать взаимодействие клиентских приложений с Backend.
Важно знать альтернативы:
1️⃣ Прямое обращение к монолиту
Если Backend представляет собой одно приложение, клиент может обращаться непосредственно к нему.
Отдельный API Gateway здесь точно не нужен: маршрутизировать запросы между несколькими Backend-сервисами просто некуда.
При этом перед приложением всё равно могут находиться инфраструктурные компоненты: reverse proxy, load balancer или Ingress.
2️⃣ Сервис-ядро
В сервис-ориентированной архитектуре может быть главный "сервис-ядро" — основная точка входа и владелец ключевых бизнес-процессов.
Это аналог оркестратора.
Клиент обращается к сервису-ядру, а тот вызывает сервис уведомлений, файловый сервис, сервис отчётности и другие вспомогательные компоненты.
Важно правильно назвать такой компонент.
Если он выполняет бизнес-логику и управляет процессами — это сервис-ядро, а не API Gateway.
3️⃣ Прямое обращение к нескольким сервисам
Клиент может вызывать публичные API сервисов напрямую.
Подход допустим, если сервисов немного, их контракты стабильны, а все точки входа действительно можно открыть клиенту.
Но клиент начинает знать внутреннюю структуру Backend. При изменении границ сервисов придётся менять и клиентское приложение.
4️⃣ Backend for Frontend (BFF)
Для каждого типа клиентского приложения создаётся свой Backend:
▫️ BFF для мобильного приложения
▫️ BFF для веб-интерфейса
▫️ BFF для админки
BFF адаптирует данные под конкретный интерфейс и объединяет обращения к нескольким сервисам.
Это особенно полезно, когда у клиентов разные сценарии, модели данных и требования к скорости ответа.
При этом BFF и API Gateway могут использоваться вместе.
5️⃣ Reverse proxy, Load Balancer или Ingress
Если нужно только:
▫️ принять HTTPS-запрос,
▫️ завершить TLS,
▫️ распределить нагрузку,
▫️ направить запрос в нужный сервис,
то может быть достаточно инфраструктурного прокси или Ingress.
Полноценный API Gateway нужен, когда появляются дополнительные задачи: управление API, проверка токенов, rate limiting, квоты, трансформация запросов и централизованные политики доступа.
6️⃣ Интеграционная шина — ESB
В сервис-ориентированной или legacy-архитектуре запрос может поступать через интеграционную шину.
ESB маршрутизирует сообщения, преобразует форматы и протоколы, связывает внутренние и внешние системы.
Но шина — не просто другое название API Gateway или Kafka.
Если перенести в неё всю бизнес-логику и подключить к БД, она станет сложным центральным компонентом, от которого будут зависеть все интеграции.
👉 Как понять, что нужен именно API Gateway?
Берём его, когда необходимо:
✔️ скрыть внутреннюю структуру сервисов
✔️ предоставить клиентам единую точку входа
✔️ централизовать авторизацию и лимиты запросов
✔️ маршрутизировать вызовы между публичными API
✔️ централизировать мониторинг и логирование "из коробки"
✔️ управлять версиями API
При этом количество сервисов — не главный критерий.
Пять сервисов с мобильным приложением, партнёрским API и разными моделями доступа могут потребовать Gateway.
А двадцать внутренних сервисов, скрытых в одном Backend, могут не требовать публичного Gateway, а требовать BFF или иного подхода.
А какое решение у вас на проекте?
Делитесь в комментариях 🙏
📱 Tg | 💙 ВК | 💬 Max
