API Gateways: Der Türsteher für Ihren Club

Stellen Sie sich vor, Sie betreiben einen exklusiven Club (Ihr Backend). Innen gibt es verschiedene Bars: Die Datenbank-Bar, die User-Service-Bar, die Payment-Bar. Würden Sie jeden Gast direkt zur Bar rennen lassen? Nein. Sie haben einen Türsteher. Er prüft den Ausweis (Auth). Er zählt die Leute (Rate Limiting). Er sagt, wo die Garderobe ist (Routing).

In der Software-Architektur ist das das API Gateway. Es ist die einzige Tür nach draußen. Dahinter können 50 Microservices liegen oder ein alter Monolith – dem Client (Handy App) ist das egal. Er spricht nur mit dem Türsteher.

Featured Snippet: Ein API Gateway ist eine Server-Komponente, die als einziger Einstiegspunkt (Single Entry Point) für alle Client-Anfragen an ein Backend-System dient. Es übernimmt Querschnittsfunktionen ("Cross-Cutting Concerns") wie Authentifizierung (OAuth/JWT), Rate Limiting (DDOS-Schutz), Caching und Request Routing. Bekannte Lösungen sind Kong, Tyk oder AWS API Gateway.

---

The Cost of Inaction: Das "Spaghetti-Netzwerk"

Ohne Gateway rufen Ihre Apps (iOS, Android, Web) direkt verschiedene Services auf.

• iOS App ruft Service A (Port 3000)
• Web App ruft Service B (Port 4000)
• Service A braucht Login, Service B braucht keinen.

Das Chaos:

1. Sicherheit: Sie müssen Authentifizierung in jedem Service neu implementieren (Fehlerquelle!).
2. Kopplung: Wenn Sie Service A umbenennen, bricht die iOS App.
3. Performance: Das Handy muss 10 Requests an 10 Services machen (langsam).

Mit Gateway macht das Handy einen Request an das Gateway. Das Gateway holt alles und schickt es gebündelt zurück.

---

Die 3 Hauptaufgaben des Gateways

Security (Auth Offloading)

Der Microservice dahinter sollte nicht wissen müssen, wie man ein JWT (JSON Web Token) validiert oder wie OAuth2 funktioniert. Das Gateway macht das.

• Gateway prüft Token: "Ist das gültig?"
• Wenn ja: Leite Request weiter an Service (mit Nutzer-ID im Header).
• Wenn nein: Blockiere sofort (401 Unauthorized). Der Service dahinter vertraut dem Gateway ("Wenn die Anfrage durchkam, ist sie sicher").

Traffic Management (Rate Limiting)

Sie wollen nicht, dass ein kaputtes Skript Ihr Backend mit 10.000 Anfragen pro Sekunde grillt. Das Gateway sagt: "User X darf nur 100 Requests pro Minute machen." Wenn er mehr macht: 429 Too Many Requests. Das schützt Ihre Datenbank vor Überlastung.

Backend for Frontend (BFF) Pattern

Ein Handy hat andere Bedürfnisse als ein Desktop.

• Desktop will alle Details (High Res Bilder).
• Handy will nur Titel (Low Res, wenig Daten). Sie können im Gateway verschiedene Endpunkte bauen: /api/mobile/feed und /api/desktop/feed. Das Gateway aggregiert die Daten passend für das Endgerät, ohne dass Sie das Backend ändern müssen.

---

Myth-Busting: "Gateway ist ein Single Point of Failure (SPOF)"

Kritiker sagen: "Wenn das Gateway down ist, ist alles down." Das stimmt. Aber: Der Türsteher ist auch der stabilste Typ im Club. Gateways (wie NGINX oder AWS API Gateway) sind auf extreme Last ausgelegt und hochverfügbar (Cluster). Es ist wahrscheinlicher, dass Ihr selbstgeschriebener Node.js Service abstürzt, als dass der NGINX Reverse Proxy abstürzt. Das Risiko ist da, aber es ist kontrollierbar.

---

Unasked Question: "Service Mesh vs. API Gateway?"

Ein Nerd-Thema.

• API Gateway regelt den Verkehr von Draußen nach Drinnen (North-South Traffic). Client -> Server.
• Service Mesh (Istio, Linkerd) regelt den Verkehr Drinnen zwischen den Services (East-West Traffic). Service A -> Service B.

Brauchen Sie beides? Für 98% der Projekte reicht ein API Gateway. Service Mesh ist Komplexitäts-Overkill, solange Sie nicht Kubernetes im großen Stil fahren.

---

FAQ: API Gateways