Zum Hauptinhalt springen

Gateway Aggregation / Backend-for-Frontends (BFF)

Einleitung​

Backend-for-Frontends (BFF) ist ein Pattern, bei dem pro Client-Typ ein dedizierter Backend-Endpunkt bereitgestellt wird.

Ziel ist nicht zentrale Governance –
sondern Client-Optimierung.

Web, Mobile oder Partner-Clients erhalten APIs, die exakt auf ihre Bedürfnisse zugeschnitten sind.

Einordnung

BFF ist ein Meso-Pattern an der Edge eines Systems.

Es sitzt:

Frontend ↔ BFF ↔ Backend-Services

Wichtig:

  • Ein API Gateway standardisiert Policies.
  • Ein BFF optimiert für einen konkreten Client.

BFF gehört zur Integrations- und API-Ebene, nicht zur Domänenebene.

Grundprinzip

Kernaussage:

  • Jeder Client erhält sein eigenes optimiertes Backend.
  • Backend-Services bleiben generisch und fachlich stabil.
  • Client-spezifische Logik bleibt clientnah.

Zielsetzung

BFF adressiert:

  • unterschiedliche Payload-Anforderungen
  • unterschiedliche Auth-Modelle
  • unterschiedliche Latenz-Anforderungen
  • unterschiedliche Aggregationsbedürfnisse

Es verhindert:

dass Backend-Services zu UI-getriebenen APIs degenerieren.

Charakteristika

1️⃣ Client-spezifische APIs​

  • Web braucht breite Payloads
  • Mobile braucht schlanke Responses
  • Partner brauchen stabile, versionierte Schnittstellen

Der BFF kapselt diese Unterschiede.

2️⃣ Aggregation​

Ein BFF:

  • ruft mehrere Services auf
  • kombiniert Ergebnisse
  • reduziert Roundtrips

Er ist Orchestrator, nicht Domäneninhaber.

3️⃣ Ownership beim Frontend-Team​

Best Practice:

  • Frontend-Team besitzt seinen BFF
  • Backend-Teams liefern stabile Fach-APIs

So bleiben Prioritäten aligned.

4️⃣ Eigene Deployments​

  • Skalierbar pro Client
  • Versionierbar unabhängig
  • Rollouts client-spezifisch möglich

Vorteile

  • Optimierte APIs pro Client
  • Schnellere Frontend-Iteration
  • Geringere Netzwerk-Last
  • Entkopplung von UI und Backend-Design

Risiken / typische Fallstricke

1️⃣ BFF wird Mini-Monolith​

Wenn Fachlogik hineinwächst, wird der BFF zum zweiten Backend.

2️⃣ Code-Duplikation​

Mehrere BFFs können:

  • Mapping-Logik duplizieren
  • ähnliche Aggregationen wiederholen

3️⃣ Verwechslung mit API Gateway​

Ein API Gateway:

  • macht Auth
  • macht Rate Limits
  • macht Routing

Ein BFF:

  • kennt Client-Bedürfnisse
  • aggregiert Daten
  • optimiert Payload

4️⃣ Überengineering​

Ein einzelner SPA mit stabilen Anforderungen braucht oft keinen dedizierten BFF.

Wann sinnvoll?

  • Mehrere Clients mit stark unterschiedlichen Anforderungen
  • Mobile-Optimierung wichtig
  • Teams sind client-orientiert organisiert
  • Microservices erzeugen viele Roundtrips

Wann unnötig?

  • Nur ein Client existiert
  • Backend-APIs bereits gut passen
  • System klein und stabil ist

Vergleich: API Gateway vs BFF

API GatewayBFF
EbeneEdge-InfrastrukturClient-Integration
FokusPolicies & RoutingClient-Optimierung
Kennt Client?NeinJa
Fachlogik?NeinMinimal
OwnershipPlattform-TeamFrontend-Team

Strategische Perspektive

BFF ist kein Skalierungs-Pattern. Es ist ein Produktivitäts-Pattern.

Es schützt Backend-Services vor UI-getriebener Erosion und schützt Frontends vor Backend-Komplexität.

Fazit

Backend-for-Frontends ist sinnvoll, wenn:

  • mehrere Clients existieren
  • Anforderungen divergieren
  • Teamstruktur client-orientiert ist

Er ist kein Pflichtbaustein jeder Microservices-Architektur, sondern ein gezieltes Integrationsmuster.