ШАБЛОН ПРОЕКТИРОВАНИЯ API GATEWAY

Давайте сегодня подумаем о чем-то большом.

Откройте любой маркетплейс. Что вы там видите?
⬛корзину;
⬛профиль пользователя;
⬛каталог;
⬛персональные рекомендации;
⬛баннеры с акциями;
⬛поиск;
⬛и так далее.

За каждой из этих функций стоит отдельный микросервис.

А теперь смените устройство. Если открывали сайт с телефона — возьмите ноутбук. Интерфейс, скорее всего, будет отличаться. Где-то изменится расположение блоков, где-то появятся дополнительные элементы, а где-то часть информации вообще исчезнет.

Вернемся к микросервисам.

Допустим, вам нужно получить профиль пользователя. Казалось бы, ничего сложного. Нужно знать адрес сервиса и его API. Но на практике все интереснее. Клиенту приходится проходить аутентификацию, авторизацию, уметь переключаться на другой инстанс, если текущий недоступен, обрабатывать ошибки, фильтровать ответ под конкретное устройство и так далее.

Теперь повторите все то же самое для получения информации про корзину.

Потом тоже самое для рекомендаций.

И так далее.

В итоге для загрузки одной главной страницы клиент может отправить десяток запросов. Логика клиентского приложения разрастается, нагрузка на сеть увеличивается, а внутри инфраструктуры каждый сервис еще и по-своему решает вопросы безопасности. Выглядит не очень.

Именно для таких случаев существует архитектурный паттерн API Gateway.

Перед всеми внутренними сервисами появляется еще один — API Gateway. Именно он становится единой точкой входа для клиентов.

Теперь клиенту не надо бегать во всем сервисам: «дай профиль», «дай корзину»; а просто сходить в одно место с запросом «собери мне главную страницу для десктопной версии».

Все остальное Gateway берет на себя. Он один раз проводит аутентификацию пользователя, сам обращается к нужным микросервисам, собирает итоговый ответ, убирает лишние данные и возвращает клиенту именно то, что нужно.

В результате:
⬛Клиент становится заметно проще.
⬛Уменьшается количество сетевых запросов. Так же экономим на размере данных, которые гоняем по сети.
⬛Внутренние API можно не раскрывать наружу. Да и вообще всю внутреннюю архитектуру.
⬛Еще один приятный бонус — Rate Limiting. Защита от нетерпеливых пользователей, которые нажимают "обновить" 100500 раз в секунду. Можно централизованно ограничить количество запросов от одного пользователя. Если бы такие лимиты настраивались отдельно в каждом сервисе, легко получить ситуацию, когда половина страницы загрузилась, а вторая половина уже уперлась в лимиты.
⬛ API Gateway можно сделать несколько. И нужно сделать несколько, чтобы не получить единую точку отказа. Но еще можно сделать отдельный Gateway для мобильных клиентов и отдельный — для веб-версии.
⬛Может показаться, что этот паттерн нужен только для взаимодействия фронтенда с бэкендом. Или только для взаимодействия между внешним и внутренним мирами. Но это не так. API Gateway нередко используют и внутри крупных систем. Например, когда одна большая внутренняя система интегрируется с другой.

Есть ли у такого подхода минусы? Конечно. Например, это дополнительный компонент инфраструктуры, который тоже нужно разрабатывать, масштабировать и поддерживать. Другие минусы набрасывайте в комментарии.

Поэтому API Gateway — не серебряная пуля. Как и любой архитектурный паттерн, его стоит внедрять только тогда, когда преимущества действительно перевешивают недостатки.

P.S. На фото — дом в предвкушении летней грозы.

#бабанюра_программирует