API Gateway to pojedynczy punkt wejścia, przez który przechodzą żądania klientów (przeglądarki, aplikacji mobilnej, innego serwisu) zanim trafią do właściwych usług w Twoim systemie. Zamiast pozwalać, żeby front-end gadał bezpośrednio z dziesiątkami mikroserwisów, stawiasz jednego „recepcjonistę”, który przyjmuje ruch, sprawdza kto puka, kieruje żądanie tam gdzie trzeba i odsyła odpowiedź. To wzorzec architektoniczny szczególnie popularny w świecie mikroserwisów, ale przyda się wszędzie, gdzie chcesz mieć kontrolę nad tym, co wchodzi.
Co robi i po co Ci to
Gateway zdejmuje z poszczególnych usług powtarzalną robotę. Zajmuje się routingiem (żądanie na /users idzie do usługi użytkowników, /orders do zamówień), uwierzytelnianiem i autoryzacją (sprawdza token JWT albo klucz API, zanim dopuści dalej), rate limitingiem (np. 100 żądań na minutę na klienta, żeby ktoś Ci nie zatkał backendu) oraz terminacją TLS. Często dochodzi do tego logowanie, metryki, cache i kompresja.
Druga ważna rola to agregacja i upraszczanie API. Klient mobilny zamiast wykonywać pięć osobnych zapytań, wysyła jedno do gatewaya, a ten zbiera dane z kilku usług i zwraca gotową paczkę. Dzięki temu mikroserwisy mogą się zmieniać w środku, a klient nadal widzi stabilny, jeden adres.
Jak to wygląda w praktyce
Popularne narzędzia to Kong, NGINX, Traefik, a w chmurze AWS API Gateway czy Azure API Management. W Kubernetesie tę rolę często pełni Ingress albo Gateway API. Minimalny routing w NGINX wygląda tak:
location /users/ { proxy_pass http://users-service:8080/; }location /orders/ { proxy_pass http://orders-service:8080/; }
Klient woła zawsze api.twojadomena.pl, a gateway decyduje, do którego kontenera trafi ruch. Dodajesz limit (limit_req_zone) i sprawdzanie nagłówka Authorization i masz komplet podstaw.
Na co uważać
Największy mit: „gateway załatwi mi bezpieczeństwo”. Nie zwalnia Cię to z zabezpieczania samych usług, bo jeśli ktoś wejdzie do sieci wewnętrznej z pominięciem gatewaya, drzwi stoją otworem. Drugi błąd to single point of failure, jeden gateway bez redundancji potrafi położyć cały system, więc uruchamiaj go w kilku instancjach. Nie pakuj też do gatewaya logiki biznesowej, jego zadanie to przekierowywać i pilnować, a nie liczyć ceny zamówienia. I pamiętaj o dodatkowym opóźnieniu (latencji), bo każdy hop kosztuje milisekundy.
Pojęcia powiązane: reverse proxy, load balancer, mikroserwisy, service mesh, rate limiting, JWT, OAuth 2.0, Kubernetes Ingress, BFF (Backend for Frontend).