🔀❌ 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