Словник для шаблонів шлюзу API: BFF, обмеження швидкості і делегування автентифікації

API-шлюз є входом в архітектуру мікросервісів. Обговорення їх вільно англійською мовою — в оглядах дизайну, обговореннях архітектури або технічних інтерв’ю — вимагає точного словника для маршрутизації, безпеки і шаблонів агрегації.

---

Що таке API-шлюз?

** API- шлюз ** — це сервер, який виконує роль єдиної точки входу для запитів клієнтів. Він обробляє крос-сегментні проблеми, тому окремі служби не повинні.

Загальні обов’ язки:

• ** Маршрутизація запитів ** — направлення запитів до відповідної серверної служби
• ** Автентифікація і авторизація ** — перевірка ідентичності та прав доступу
• ** Обмеження швидкості ** — керування обсягом запитів на клієнта
• ** Балансування навантаження ** — розподіл запитів між екземплярами служб
• ** Переклад протоколу ** — перетворення між REST, gRPC, WebSocket

У реченнях

• «Шлюз ** маршрутизує ** запити на основі шляху URL і методу HTTP.»
• «Ми централізуємо автентифікацію на шлюзі, а не в кожній службі.»
• «Шлюз агрегує відповіді від трьох мікросервісів в одну корисну нагрузку.»

---

Сервер для фронтенд (BFF)

Шаблон Backend for Frontend (BFF) створює спеціальний шар API для кожного типу клієнта (мобільного, веб-, стороннього).

«Кожен фронтенд має свій власний BFF, який ** підлаштовує ** форму відповіді до своїх специфічних потреб.»

Чому використовувати BFF?

• «The mobile BFF reduces payload size by returning only the fields the app needs.» (англійською)
• «Web BFF може агрегувати дані з п’яти сервісів, тому браузер робить один запит.»
• Різні клієнти мають різні допуски затримки — BFF оптимізує для кожного

Vocabulary

• • spin up a BFF * — створити спеціальний шар сервера для клієнта
• • власник BFF * — BFF відповідає за організацію викликів служб, які лежать в основі
• • клієнтський контракт API * — інтерфейс, який відповідає потребам одного з клієнтів

---

Обмеження швидкості

** Обмеження швидкості ** (також називається обмеженням) обмежує кількість запитів, які клієнт може надати за певний проміжок часу.

Types

• ** Виправлено вікно ** — « Дозволяє 100 запитів ** за хвилину **. Зчитувач скидається на початку кожної хвилини.»
• Sliding window — « Підраховує запити у прокручуваному вікні за останні 60 секунд »
• Token bucket — «Клієнти накопичують токени за фіксованою ставкою; кожен запит споживає один»
• Leaky bucket — « Запити обробляються з фіксованою швидкістю незалежно від кількості запитів »

В обсуждениях дизайна

• «Ми примушуємо обмеження швидкості 1000 запитів на годину на API ключ»
• «Клієнти, які перевищують обмеження, отримують відповідь 429 Too Many Requests»
• «Ми дозволяємо bursting до 200 запитів в будь-якому 10-секундному вікні.»
• «Обмеження ставки застосовується ** на орендаря **, а не глобально.»

Заголовки відповідей для обмеження швидкості

Інженери часто обговорюють ці питання під час перегляду коду:

• X-RateLimit-Limit — максимально допустима кількість запитів
• X-RateLimit-Remaining — скільки запитів залишилося
• Retry-After — коли клієнт може спробувати ще раз

---

Делегація УНР

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

Patterns

• ** Перевірка JWT на шлюзі ** — « Шлюз ** перевіряє ** підпис JWT; служби тільки розбирають декодовані заявки. »
• ** Інтроспекція токенів OAuth 2. 0** — « Шлюз викликає сервер автентифікації для ** перевірки ** непрозорого токена перед пересиланням. »
• mTLS (mutual TLS) — « Служби автентифікують один одного за допомогою сертифікатів, а не токенів. »

Ключові фрази

• «Шлюз знімає зовнішній токен і вставляє внутрішній заголовок ідентичності сервісу»
• «Довгострокові послуги довіряють твердженню ідентичності шлюзів»
• «Ми використовуємо JWKS (JSON Web Key Sets) для перевірки підписів токенів без поїздки в обидві сторони до сервера аутентифікації»
• «Шлюз примушує авторизацію на основі обсягу — послуги бачать тільки попередньо авторизовані запити.»

---

Маршрутизація запитів

** Маршрутизація запитів ** направляє вхідний трафік до відповідної серверної служби за допомогою правил.

Типи маршрутизації

• ** Маршрутизація за допомогою шляхів** — /api/users/* → Служба користувача
• ** Маршрутизація за заголовками ** — X-Version: v2 → Нова версія сервісу
• ** Вважене маршрутизування ** — « 80% до стабільного, 20% до канарського »
• Content-based routing — «Маршрутизація запитів з Content-Type: application/xml до застарілого обробника»

У розмові

• «Ми ** маршрут ** за префіксом шляху — /payments/ йде до платіжної служби. ”
• «Шлюз ** переписує ** шлях перед пересиланням до бекенду.»
• «Traffic is split 95/5 between the stable and canary releases.» (англійською)
• «Ми використовуємо ** host-based routing ** для обслуговування різних рентерів з одного і того ж шлюзового порту.»

---

Список мов світу The Common Gateway Dictionary

Term	Definition
upstream	The backend service the gateway calls
downstream	The client that calls the gateway
passthrough	Forwarding a request with minimal modification
circuit breaker	Stops routing to a failing backend after a threshold
sticky session	Routes requests from the same client to the same instance
egress	Traffic leaving the system
ingress	Traffic entering the system

---

Ключеві моменти

• ** API gateway ** — єдина точка входу, яка обробляє маршрутизацію, автентифікацію, обмеження швидкості і балансування навантаження.
• ** BFF ** — виділений шар шлюзу для кожного типу клієнта (мобільний, веб, сторонній).
• ** Обмеження швидкості ** — застосовується до ключа/ користувача API за допомогою фіксованого вікна, рухомого вікна або контейнера токенів.
• ** Делегування автентифікації ** — шлюз перевіряє ідентичність, щоб служби могли довіряти твердженню, яке надходить з нижнього рівня.
• ** Маршрутизація запитів ** — правила, засновані на шляху, заголовку, ваганні або засновані на вмісту.
• Ключові дієслова: * маршрутизація, примус, агрегування, перевірка, введення, видалення, перезапис, розділення *.

На практиці: Навігація Nuance — перспектива розробника

Будьмо чесними; технічний жаргон може здатися особливо складним, коли ви вивчаєте нову мову. Самі слова можуть бути простими, але спосіб, в який вони використовуються - тонкі наслідки і улюблена фраза - можуть відкинути вас. Це особливо стосується обговорень API-шлюзів, де терміни «BFF», «обмеження швидкості» і «делегування аутентифікації» не є просто технічними описами; вони представляють певний архітектурний підхід з пов’язаними обов’язками і потенційними викликами.

Поширеною проблемою для розробників, які вивчають англійську мову в професійному контексті, є розуміння різниці між заявою про вимоги і пропозицією рішення. Наприклад, замість того, щоб просто сказати «Ми потребуємо обмеження швидкості», більш ефективним комунікації буде: «Щоб захистити нашу основну службу від надмірного навантаження під час пікових часових інтервалів, давайте реалізуємо обмеження швидкості на кінцевій точці /users/login». Зауважте, як додавання контексту - * чому * ви реалізуєте обмеження швидкості - негайно прояснює мету і дозволяє обговорювати конкретні пороги або стратегії. Аналогічно, при перегляді коду колеги, пов’язаного з конфігурацією API-шлюзів, важливо вийти за рамки простої ідентифікації помилок. Замість того, щоб сказати «Це не обробляє автентифікацію», більш конструктивним коментарем може бути: «Чи можемо ми дослідити використання делегування автентифікації тут? Це дозволить нам централізувати управління ідентифікацією користувачів і зменшити дублювання в наших службах»

Інша важлива відмінність полягає у використанні дієслів. « Впровадити » часто вважається кращим за « Звести », коли описуються технічні рішення, що свідчить про більш формалізований процес. « Розгорнути » означає просто випустити код, « налаштувати » означає встановити параметри і правила у самому шлюзі. Крім того, такі фрази як «зменшити когнітивне навантаження» або «покращити оперативну ефективність» зазвичай використовуються для виправдання архітектурних рішень - вони говорять про ширші бізнес-цілі, ніж просто безпосереднє технічне завдання. Звернення уваги на ці нюанси значно покращить вашу здатність ефективно брати участь у обговоренні проекту і зробити значний внесок у перегляд коду.

І, нарешті, не бійтеся прохання про пояснення. Якщо ви не впевнені, що хтось має на увазі, ввічливо попросіть пояснення. Просте «Чи можете ви розібратися, що ви маєте на увазі під «оптимізацією шаблону BFF тут?» може відкрити діалог і запобігти непорозумінням. Ясне спілкування є найважливішим - це уникнення переробки, зменшення неоднозначності і сприяння співпраці в межах вашої команди.

# Example using curl to simulate rate limiting (Illustrative - not production ready)
curl -v --rate-limit 5/second http://api.example.com/users/login