API-шлюз - окремий сервіс-«вхідні двері» перед вашими API. Клієнти звертаються лише до нього, а він маршрутизує запити до внутрішніх сервісів.
клієнти → API-шлюз → сервіс замовлень
→ сервіс користувачів
→ сервіс платежів
Що зазвичай робить шлюз:
- маршрутизація:
/api/orders/*- до одного сервісу,/api/users/*- до іншого; - автентифікація: перевірка токенів чи API-ключів один раз на вході, далі - довірений заголовок з ідентифікатором користувача;
- обмеження частоти і квоти для клієнтів і тарифів;
- TLS-термінація, CORS, стиснення;
- кешування відповідей;
- трансформація: перетворення форматів, об'єднання відповідей кількох сервісів в одну;
- спостережуваність: централізовані журнали, метрики, трасування запитів;
- версіонування і поступове перемикання трафіку між версіями сервісу.
Приклади: Kong, Tyk, AWS API Gateway, Azure API Management, Cloudflare (частково), Traefik і Nginx як простіші варіанти.
Коли шлюз доречний:
- кілька сервісів, які мають виглядати як одне API;
- публічне API з ключами, тарифами, квотами й порталом для розробників;
- потрібно централізовано застосовувати політики, а не дублювати їх у кожному сервісі.
Коли він зайвий: один моноліт на Laravel. Маршрутизація, автентифікація (Sanctum, Passport), обмеження частоти (throttle) уже є у фреймворку, а зовнішній шлюз лише додасть ще одну ланку, яка може впасти.
Ризики шлюзу:
- єдина точка відмови і вузьке місце - потребує резервування;
- «розумний шлюз»: бізнес-логіка, що поступово переїжджає в конфігурацію шлюзу, стає некерованою. Шлюз має займатися наскрізними задачами, а не правилами предметної області;
- додаткова затримка на кожен запит.
Споріднений патерн - BFF (backend for frontend): окремий шлюз під кожен тип клієнта, що збирає дані саме під його екрани.