Давайте изучим шлюзы API

Вау, такое прекрасное платье! Во время серфинга в Интернете почти невозможно не увидеть рекламу красивых платьев, если мы искали раньше. Однако что может произойти, когда мы нажмем на рекламу этих платьев? Направляемся на сайт покупок и видим все детали этого платья. Эти данные поступают из одного и того же сервиса или они агрегируются и отправляются нам? Сегодня я расскажу о втором варианте — API-шлюзах.

Что такое шлюзы API?

Шлюз API обрабатывает все вызовы API от клиентов, направляя их в соответствующую микрослужбу, вызывает эти микрослужбы и собирает результаты. Шлюз API скрывает внутренние API от своих клиентов. Если в микросервисах есть какой-либо сбой, шлюз API может замаскировать его, возвращая кэшированные данные или данные по умолчанию. Это упрощает как реализацию клиента, так и приложение микрослужб, поскольку является точкой входа для каждого запроса, поступающего от клиента.

Обзор проекта

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

Когда клиенты хотят увидеть наше красивое платье, они отправляют запрос на шлюз, который имеет конечную точку products/:id. Чтобы агрегировать все эти данные, шлюз отправляет запрос нашим внутренним микросервисам, которые имеют разные конечные точки. Наш клиент должен был отправить запрос к этим микросервисам, если нет шлюза.

Погрузитесь в API-шлюз

Наш герой должен сделать три вызова API, чтобы агрегировать эти фрагменты информации. С точки зрения эффективности было бы гораздо разумнее запускать как можно больше вызовов одновременно. Она хочет ответить всем клиентам, которые просят показать детали платья. Хотя она не может быть везде одновременно, она может летать очень быстро, собирая все данные. Ей нужно сократить общее время ожидания. Вот почему мы помогаем ей с горутинами.

У нас более одной горутины, потому что у нас есть три вызова API. Наш герой занят, поэтому ей нужно знать, когда ее работа сделана. Поэтому мы ждем выполнения трех горутин, а затем отправляем агрегированные данные клиенту.

Бонус: лучший друг

Предположим, что у вас есть как мобильная служба, так и веб-служба, а это означает, что у вас разные пользовательские интерфейсы, и вы знаете, что природа мобильного взаимодействия часто резко отличается от веб-интерфейса на настольном компьютере. Вы предпочитаете предоставлять один API для каждого типа клиентов или предоставлять один API для каждого клиента?

Что мы подразумеваем под дифференциацией? Мобильные устройства должны совершать меньше вызовов из-за продолжительности работы от батареи и должны отображать разные данные при сравнении с настольными аналогами. Следовательно, оба пользовательских интерфейса должны поддерживаться разными API с уникальными функциями, а не одним общим API.

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

Нижестоящая служба инициирует запросы и получает ответы.

Восходящая служба получает запросы и возвращает ответы.

Подробнее о BFF читайте в этой статье.

Исходный код

https://github.com/dilaragorum/lovely-dress-go

Спасибо, что дочитали до этого места. Я стараюсь, чтобы мой проект был простым, чтобы сосредоточиться на основной концепции — шлюзе API. Буду рад, если у вас будут рекомендации и отзывы.

Вот ссылка на мои предыдущие статьи: