API Gateway Patterns: Backend for Frontend, Composition, Aggregation und mehr

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

API Gateway Patterns sind bewährte Architekturmuster, die am Gateway implementiert werden, um Komplexität von Clients zu abstrahieren, Performance zu verbessern und Microservices zu orchestrieren. Wer diese Patterns kennt, kann Architekturentscheidungen fundiert treffen.

Was sind API Gateway Patterns?

API Gateway Patterns sind Architekturmuster, die das API Gateway als zentralen Knotenpunkt nutzen, um wiederkehrende Probleme der API-Architektur zu lösen. Sie definieren, wie das Gateway Anfragen transformiert, aggregiert, weiterleitet und absichert — ohne dass Clients oder Backends diese Logik selbst implementieren müssen.

Die wichtigsten Patterns:

1. Backend for Frontend (BFF): Spezielles Gateway pro Client-Typ
2. API Composition / Aggregation: Mehrere Backend-Calls in einer Anfrage
3. Protocol Translation: Protokollumwandlung am Gateway
4. Circuit Breaker: Schutz vor Kaskadenausfällen
5. Strangler Fig: Schrittweise Migration alter APIs
6. API Versioning: Versionierung und parallele API-Versionen
7. Request/Response Transformation: Payload-Anpassung am Gateway

Wer nutzt API Gateway Patterns?

• Softwarearchitekten wählen Patterns basierend auf Anforderungen
• Platform-Teams implementieren Patterns als Gateway-Konfiguration
• Backend-Entwickler müssen verstehen, wie das Gateway ihre Endpunkte transformiert
• Frontend-Entwickler profitieren von aggregierten und angepassten Antworten

Warum ist das Thema in der Informatik und für Prüfungen wichtig?

API Gateway Patterns sind Kernwissen für Architekturzertifizierungen (AWS Solutions Architect, Azure Solutions Architect) und werden in Microservices-Büchern (Sam Newman, Chris Richardson) ausführlich behandelt. In IHK-Prüfungen und im Informatikstudium werden Patterns wie BFF und Circuit Breaker als Beispiele für Entwurfsmuster auf Architekturebene abgefragt. Das Verständnis dieser Patterns ist Voraussetzung für das Design skalierbarer, wartbarer API-Landschaften.

Kernkonzepte im Detail

1. Backend for Frontend (BFF)

Das BFF-Pattern besagt: Jeder Client-Typ bekommt sein eigenes Gateway (oder eine eigene Gateway-Konfiguration), die genau auf seine Bedürfnisse zugeschnitten ist.

Das Problem: Eine Web-App, eine Mobile-App und ein B2B-Client haben unterschiedliche Anforderungen. Die Web-App braucht volle Daten für komplexe UIs. Die Mobile-App braucht reduzierte Daten für langsame Netzwerke. Der B2B-Client braucht Batch-Endpunkte und XML. Ein einziges Gateway kann all diese Anforderungen nicht optimal erfüllen.

Die Lösung: Drei BFFs:

• Web-BFF: Vollständige Antworten, komplexe Aggregationen, CORS
• Mobile-BFF: Reduzierte Felder, flache Hierarchien, Caching, niedrigere Rate Limits
• B2B-BFF: Batch-Endpunkte, XML-Transformation, mTLS, höhere Quotas

Jedes BFF kann unabhängig entwickelt, deployt und skaliert werden.

2. API Composition / Aggregation

Das Composition-Pattern fasst mehrere Backend-Anfragen in einer einzigen Client-Anfrage zusammen. Der Client sendet eine Anfrage an das Gateway, das Gateway ruft mehrere Backends parallel auf und kombiniert die Ergebnisse.

Beispiel: Ein Client ruft /api/dashboard auf. Das Gateway ruft parallel auf:

• /users/42 (User Service)
• /orders?userId=42 (Order Service)
• /notifications?userId=42 (Notification Service)

Das Gateway kombiniert die drei Antworten zu einer einzigen JSON-Antwort. Der Client macht einen Roundtrip statt drei.

Vorteile: Reduzierte Latenz (parallele Calls), reduzierte Client-Komplexität, zentrale Fehlerbehandlung. Nachteile: Das Gateway wird komplexer, Fehlerbehandlung bei teilweisen Ausfällen ist schwierig.

3. Protocol Translation

Das Gateway wandelt eingehende Protokolle in interne Protokolle um:

• REST zu gRPC: Externe Clients senden REST, das Gateway wandelt in gRPC für interne Microservices um. gRPC ist effizienter (Protobuf, HTTP/2), aber für externe Clients weniger zugänglich.
• SOAP zu REST: Legacy-SOAP-Services werden als moderne REST-APIs nach außen angeboten.
• HTTP zu WebSocket: Das Gateway hält WebSocket-Verbindungen und kommuniziert intern über HTTP.
• GraphQL zu REST: Das Gateway akzeptiert GraphQL-Queries und mappt sie auf REST-Backend-Calls.

4. Circuit Breaker

Der Circuit Breaker schützt das System vor Kaskadenausfällen. Er hat drei Zustände:

• Closed: Anfragen werden normal weitergeleitet. Fehler werden gezählt.
• Open: Ab einer Fehlerquote-Schwelle (z.B. 50% in 10 Sekunden) werden alle Anfragen sofort mit einer Fehlerantwort abgewiesen. Das Backend wird nicht mehr belastet.
• Half-Open: Nach einer Wartezeit (z.B. 30 Sekunden) wird eine probeweise Anfrage durchgelassen. Erfolgt sie, geht der Breaker zurück auf Closed. Schlägt sie fehl, bleibt er Open.

Das Pattern verhindert, dass ein langsamer oder ausgefallener Service das gesamte System blockiert, weil Clients auf Timeouts warten.

5. Strangler Fig

Das Strangler-Fig-Pattern ermöglicht die schrittweise Migration einer alten API zu einer neuen Architektur. Benannt nach der Würgerfeige, die einen Baum langsam umwächst und ersetzt.

Der Prozess:

1. Das Gateway leitet alle Anfragen an die alte API weiter (Facade).
2. Neue Endpunkte werden im neuen System implementiert. Das Gateway leitet diese an das neue System weiter.
3. Nach und nach werden weitere Endpunkte migriert.
4. Wenn alle Endpunkte migriert sind, wird die alte API abgeschaltet.

Vorteil: Migration ohne Big-Bang-Release, rollbackfähig, risikoarm.

6. API Versioning am Gateway

Das Gateway verwaltet mehrere API-Versionen parallel:

• /v1/users -> alter User Service (Legacy)
• /v2/users -> neuer User Service (mit erweiterten Feldern)

Das Gateway kann Versionen mappen: Ein v1-Request wird transformiert, damit er auch am v2-Backend funktioniert (Forward Compatibility). Oder das Gateway leitet v1 an das alte und v2 an das neue Backend weiter.

7. Request/Response Transformation

Das Gateway transformiert Payloads, ohne das Backend zu ändern:

• Feld-Reduktion: Mobile-Client bekommt nur 5 Felder statt 20
• Feld-Umbenennung: first_name (extern) zu firstName (intern)
• Format-Konvertierung: XML zu JSON, Snake_Case zu camelCase
• Header-Anreicherung: Security-Header, Correlation-ID, Tenant-ID
• Response-Filterung: Sensitive Felder für bestimmte Clients entfernen

Warum sind API Gateway Patterns in der Praxis wichtig?

Szenario 1: Mobile-App Performance

Eine Mobile-App braucht 3 API-Calls für einen Dashboard-Screen. Jeder Call hat 200ms Latenz. Gesamt: 600ms plus Rendering. Mit API Composition: 1 Call, parallele Backend-Aufrufe, Gesamt: 250ms. Die App fühlt sich deutlich schneller an.

Szenario 2: Legacy-Migration

Ein 10 Jahre alter Monolith soll zu Microservices migriert werden. Ein Big-Bang-Release ist zu riskant. Mit dem Strangler-Fig-Pattern werden Endpunkte nacheinander migriert, das Gateway leitet automatisch an das richtige System. Alte Clients merken nichts von der Migration.

Szenario 3: Kaskadenausfall verhindern

Service A ruft Service B auf, Service B ist langsam. Service A wartet auf Timeout, belegt Threads. Mehrere Requests stauen sich, Service A wird auch langsam. Der Circuit Breaker am Gateway erkennt die Fehler von Service B, öffnet den Circuit, und Service A bekommt sofort eine Fehlerantwort statt zu warten. Das System bleibt stabil.

Praxisbeispiel: Kong API Gateway mit Composition und Circuit Breaker

Dieses Beispiel zeigt zwei Patterns in der Praxis: API Composition (ein Endpunkt aggregiert mehrere Backend-Calls) und Circuit Breaker (Schutz vor Backend-Ausfällen). Es wurde gewählt, weil diese beiden Patterns die häufigsten in der Praxis sind und das größte architektonische Problem lösen: Client-Komplexität und Ausfallsicherheit.

# kong-patterns.yml
# API Gateway Patterns: Composition + Circuit Breaker + BFF

services:
  # --- Backend Services ---
  - name: user-service
    url: http://user-service.internal:3000

  - name: order-service
    url: http://order-service.internal:3001

  - name: notification-service
    url: http://notification-service.internal:3002

  # --- BFF: Mobile (reduzierte Daten) ---
  - name: mobile-bff
    url: http://bff-mobile.internal:4000
    routes:
      - name: mobile-dashboard
        paths:
          - /mobile/dashboard
        strip_path: false

  # --- BFF: Web (volle Daten) ---
  - name: web-bff
    url: http://bff-web.internal:4001
    routes:
      - name: web-dashboard
        paths:
          - /web/dashboard
        strip_path: false

routes:
  # --- Composition Route: /dashboard aggregiert 3 Services ---
  - name: dashboard-composite
    paths:
      - /api/dashboard
    strip_path: false
    service: user-service  # Fallback, wird durch Plugin überschrieben

plugins:
  # --- Circuit Breaker für alle Services ---
  - name: request-termination
    service: order-service
    config:
      status_code: 503
      message: "Order Service temporarily unavailable"

  # --- Rate Limiting pro BFF ---
  - name: rate-limiting
    route: mobile-dashboard
    config:
      minute: 60
      limit_by: ip

  - name: rate-limiting
    route: web-dashboard
    config:
      minute: 200
      limit_by: consumer

// bff-composition.js
// Backend for Frontend: Dashboard Composition mit Circuit Breaker
// Node.js/Express — aggregiert User, Orders und Notifications

const express = require('express');
const axios = require('axios');
const CircuitBreaker = require('opossum');

const app = express();

// Circuit Breaker für jeden Service
const userBreaker = new CircuitBreaker(async (userId) => {
  const res = await axios.get(`http://user-service.internal:3000/users/${userId}`, {
    timeout: 2000
  });
  return res.data;
}, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000
});

const orderBreaker = new CircuitBreaker(async (userId) => {
  const res = await axios.get(`http://order-service.internal:3001/orders?userId=${userId}`, {
    timeout: 2000
  });
  return res.data;
}, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000
});

const notificationBreaker = new CircuitBreaker(async (userId) => {
  const res = await axios.get(`http://notification-service.internal:3002/notifications?userId=${userId}`, {
    timeout: 2000
  });
  return res.data;
}, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000
});

// Fallback-Funktionen bei Circuit Open
userBreaker.fallback(() => ({ id: null, name: 'Unbekannt', error: 'User Service unavailable' }));
orderBreaker.fallback(() => ({ orders: [], error: 'Order Service unavailable' }));
notificationBreaker.fallback(() => ({ notifications: [], error: 'Notification Service unavailable' }));

// Composition Endpoint: /api/dashboard?userId=42
app.get('/api/dashboard', async (req, res) => {
  const userId = req.query.userId;
  if (!userId) {
    return res.status(400).json({
      error: 'MISSING_PARAMETER',
      message: 'userId ist erforderlich'
    });
  }

  // Parallele Aufrufe mit Circuit Breaker
  const [user, orders, notifications] = await Promise.all([
    userBreaker.fire(userId),
    orderBreaker.fire(userId),
    notificationBreaker.fire(userId)
  ]);

  // Aggregierte Antwort
  res.json({
    user: user,
    orders: orders.orders || [],
    orderCount: orders.orders ? orders.orders.length : 0,
    notifications: notifications.notifications || [],
    unreadNotifications: notifications.notifications
      ? notifications.notifications.filter(n => !n.read).length
      : 0,
    // Markierung von teilweisen Ausfällen
    _meta: {
      userAvailable: !user.error,
      ordersAvailable: !orders.error,
      notificationsAvailable: !notifications.error,
      timestamp: new Date().toISOString()
    }
  });
});

// Mobile BFF: Reduzierte Felder
app.get('/mobile/dashboard', async (req, res) => {
  const userId = req.query.userId;
  const [user, orders, notifications] = await Promise.all([
    userBreaker.fire(userId),
    orderBreaker.fire(userId),
    notificationBreaker.fire(userId)
  ]);

  // Mobile: Nur wesentliche Felder, flache Struktur
  res.json({
    userName: user.name || 'Unbekannt',
    orderCount: orders.orders ? orders.orders.length : 0,
    unreadCount: notifications.notifications
      ? notifications.notifications.filter(n => !n.read).length
      : 0
  });
});

// Web BFF: Volle Daten
app.get('/web/dashboard', async (req, res) => {
  const userId = req.query.userId;
  const [user, orders, notifications] = await Promise.all([
    userBreaker.fire(userId),
    orderBreaker.fire(userId),
    notificationBreaker.fire(userId)
  ]);

  // Web: Alle Felder, verschachtelte Struktur
  res.json({
    profile: user,
    recentOrders: orders.orders || [],
    allNotifications: notifications.notifications || [],
    _meta: {
      userAvailable: !user.error,
      ordersAvailable: !orders.error,
      notificationsAvailable: !notifications.error
    }
  });
});

app.listen(4000, () => {
  console.log('BFF listening on port 4000');
});

Detaillierte Informationen

BFF: Wann und wie viele?

Faustregel: Ein BFF pro Client-Typ, nicht pro Endgerät. Typische BFFs:

• Web-BFF: Browser-Apps (SPA, SSR)
• Mobile-BFF: iOS/Android-Apps
• B2B-BFF: Partner-Integrationen

Nicht empfohlen: Ein BFF pro Bildschirm oder pro Feature. Das führt zu BFF-Explosion und Wartungsaufwand.

Composition: Synchron vs. Asynchron

Die gezeigte Composition ist synchron (Client wartet auf Antwort). Für asynchrone Composition gibt es zwei Varianten:

• Request/Reply mit WebSocket: Client subscribt an Gateway, Gateway ruft Backends auf und pusht Ergebnisse sobald verfügbar.
• Event-Driven: Client sendet Anfrage, Gateway startet asynchrone Verarbeitung und gibt eine Korrelations-ID zurück. Client pollt oder subscribed für das Ergebnis.

Circuit Breaker Konfiguration

Wichtige Parameter:

• errorThresholdPercentage: Ab welchem Fehleranteil öffnet der Breaker? (typisch: 50%)
• resetTimeout: Wie lange bleibt der Breaker offen? (typisch: 30s)
• timeout: Wann gilt ein Call als fehlgeschlagen? (typisch: 2-5s)
• volumeThreshold: Mindestanzahl Calls, bevor Fehlerquote berechnet wird (typisch: 5)

Strangler Fig: Risiken und Gegenmaßnahmen

• Doppelte Logik: Während der Migration existiert Logik in alt und neu. Gegenmaßnahme: Shared Libraries für Geschäftslogik.
• Routing-Fehler: Das Gateway leitet an das falsche System. Gegenmaßnahme: Feature-Flags und canary Releases.
• Datenkonsistenz: Alt und neu nutzen dieselbe Datenbank oder verschiedene. Gegenmaßnahme: Klare Datenpartitionierung oder Read-Model-Synchronisation.

Transformation: JSONPath und Templates

Moderne API Gateways unterstützen Transformationen mit JSONPath oder Templates:

• JSONPath: $.user.first_name extrahiert ein Feld
• JQ: Komplexe Transformationen mit jq-Syntax
• Liquid Templates: Template-Engine für Response-Transformation (Azure API Management)
• Lua: Kong/OpenResty erlaubt Lua-Skripte für komplexe Transformationen

Anti-Patterns

• Gateway als Business Logic Layer: Das Gateway sollte keine Geschäftslogik enthalten. Transformation und Aggregation ja, aber keine fachlichen Berechnungen oder Validierungen.
• Zu viele BFFs: Jedes Team will ein eigenes BFF. Das führt zu Duplikation und Wartungsaufwand.
• Composition ohne Timeout: Wenn ein Backend langsam ist, wartet der Client ewig. Jeder Composition-Call braucht ein Timeout.
• Circuit Breaker ohne Fallback: Ohne Fallback bekommt der Client eine kryptische Fehlermeldung. Definiere sinnvolle Fallback-Antworten.

FAQ: API Gateway Patterns

Weiter im API Lernpfad

Der nächste Artikel behandelt API Dokumentation mit Swagger und OpenAPI — wie Du Deine APIs verständlich, maschinenlesbar und standardkonform dokumentierst.

Quellen und weitere Ressourcen

1. https://microservices.io/patterns/apigateway.html
2. https://samnewman.io/patterns/
3. https://docs.konghq.com/hub/
4. https://learn.microsoft.com/en-us/azure/api-management/
5. https://martinfowler.com/bliki/StranglerFigApplication.html

Buchempfehlungen zur API-Entwicklung

API-Entwicklung

Bücher über API-Design, REST, GraphQL, OpenAPI und API-Architektur

REST und HTTP: Entwicklung und Integration nach REST-Prinzipien von Stefan Tilkov

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

API-Design: Praxishandbuch für Java- und Webservice-Entwickler

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

Microservices: Grundlagen flexibler Softwarearchitekturen von Eberhard Wolff

Bei Amazon ansehen

Affiliate-Link: Bei einem Kauf erhalten wir möglicherweise eine Provision.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert