Backend-for-Frontend-Pattern (BFF): Architekturdiagramm und Trade-offs

Dein Mobile-Team baut eine Produktseite. Die allgemeine API liefert Dutzende Felder, die das Telefon nie anzeigt, und Bewertungen, Lagerbestand und Wunschliste brauchen jeweils einen weiteren Aufruf. Jede Änderung an diesen Endpunkten wartet auf ein API-Team, das auch die Website und drei Partner bedient.

Ein Backend for Frontend (BFF) gibt jedem Client-Erlebnis eine eigene kleine serverseitige API, die dem Team gehört, das den Client baut. Dieser Beitrag behandelt den Ursprung des Patterns, was ein BFF leisten sollte, wie er sich zu API-Gateway und GraphQL verhält, wie er OAuth-Tokens aus dem Browser hält, seine Fallstricke und wie du ihn zeichnest.

Woher das Pattern kommt

SoundCloud hat dem Pattern seinen Namen gegeben. Phil Calçados Artikel von 2015 beschreibt Apps auf Basis der öffentlichen API, bei denen eine Profilseite /tracks/1234.json, /tracks/1234/related.json, /users/86762.json und /users/me.json aufrief und die Ergebnisse selbst zusammenführte. Als die Client-Teams ihre Backends selbst besaßen, verlegten sie das Zusammenführen dorthin, und die App fragte nur noch GET /user-profile/123.json ab. Der Web-Tech-Lead Nick Fisher prägte den Begriff. Calçado fasst es so zusammen: „Der BFF war Teil der Anwendung.“

Sam Newmans Artikel Backends For Frontends vom November 2015 verallgemeinerte das Pattern: ein Backend pro Nutzererlebnis, betreut vom Team, das diese Oberfläche baut.

Gesprächige Clients und Einheits-APIs

• Gesprächige Clients. Newmans Beispiel ist eine Wunschliste: Erst wird die Liste geholt, dann Namen, Preise und Lagerbestände ihrer Einträge. Das sind zwei abhängige Roundtrips; bei, sagen wir, je 150 ms im Mobilfunknetz vergehen 300 ms, bevor das Rendering beginnt. Mit einem BFF zahlt das Telefon einen Roundtrip, und die abhängigen Aufrufe laufen im Rechenzentrum, wo ein Hop höchstens ein paar Millisekunden kostet.
• Payloads für den größten Bildschirm. Das Telefon lädt Felder herunter, die es nie anzeigt.
• Ein gemeinsamer Engpass. Jedes Client-Team reiht Änderungen für ein einziges Deployable ein, das oft einem separaten Team gehört.

Wofür ein BFF zuständig ist

BFF vs. API-Gateway vs. GraphQL

Ein verbreitetes Setup stellt ein Gateway an den Rand und die BFFs dahinter, wie im Architekturdiagramm für ein API-Gateway. Ein gemeinsamer Graph kann BFFs pro Client ersetzen, und Microsofts Pattern-Leitfaden merkt an, dass separate BFFs bei frontendspezifischen Resolvern nichts bringen müssen. Der Preis ist die Teamgrenze: Jedes Client-Team verhandelt Änderungen an einem einzigen Schema.

Verantwortung und Teamgrenzen

Der BFF gehört dem Client-Team: Die Web-App und ihr BFF ändern sich in einem Pull Request und gehen in einem Release live. Newman weist darauf hin, dass ein Mobile-Team Logik sogar in seinen BFF verlagern kann, um ohne App-Store-Review auszuliefern.

Wie viele BFFs? Newman zitiert Stewart Gleadow: ein Erlebnis, ein BFF. REA Group betrieb getrennte BFFs für iOS und Android; SoundCloud teilte sich einen zwischen seinen iOS- und Android-Hörer-Apps, und seine Entwickler sagten Newman, sie könnten das überdenken. Pete Hodgsons Variante lautet, den Teamgrenzen zu folgen. Dein Engineering-Organigramm sollte pro BFF genau ein verantwortliches Team zeigen.

Ein Partner-BFF hält einen stabilen, versionierten Vertrag und bildet ihn auf die Services ab, während sich diese ändern, sodass interne Arbeiten Partner-Integrationen nicht brechen. Partner direkt auf versionierte Service-APIs zu routen funktioniert ebenfalls.

Der BFF als Token-Handler für Browser-Apps

Eine Single-Page-App, die OAuth selbst ausführt, hält Tokens im Browser, wo jedes eingeschleuste Skript sie stehlen kann. Der JWT-Leitfaden zeigt, wo eine Browser-App Tokens aufbewahren kann und welches Risiko jede Option hat. RFC 10017, OAuth 2.0 for Browser-Based Applications, wurde im August 2026 zur Best Current Practice (BCP 212). Er ordnet drei Architekturen nach absteigender Sicherheit:

Hier ist der BFF ein vertraulicher (confidential) OAuth-Client. Er führt den Authorization-Code-Flow mit PKCE aus, tauscht den Code mit eigenen Credentials ein, speichert die Tokens zur Session des Nutzers und hängt das Access-Token an jeden weitergeleiteten Aufruf. Der Browser hält nur ein Cookie; das OAuth-2.0-Flow-Diagramm erklärt den Code-Flow Schritt für Schritt.

Die wichtigsten Regeln des RFC:

• Cookie: Secure und HttpOnly sind Pflicht; empfohlen sind SameSite=Strict, Path=/, kein Domain und ein Namenspräfix wie __Host-Http-. Chrome und Firefox setzen dieses Präfix durch; Safari wendet zum Zeitpunkt des Schreibens (November 2026) nur den __Host--Teil an.
• CSRF: Eine Abwehr ist Pflicht. Ein statischer benutzerdefinierter Header bei jedem API-Aufruf erzwingt bei Cross-Origin-Anfragen einen CORS-Preflight.
• Proxy: nur an Hosts auf der Allowlist weiterleiten.
• Session-Zustand: ein serverseitiger Store, den der RFC nur bei kleinem Umfang empfiehlt, oder im Cookie verschlüsselte Tokens, innerhalb der 4.096 Bytes pro Cookie, die RFC 6265 von Browsern verlangt. Lass die Session so lange gelten wie das Refresh-Token.

Set-Cookie: __Host-Http-sid=3f9c...; Secure; HttpOnly; SameSite=Strict; Path=/

// Same-origin fetch sends the cookie by default.
await fetch("/bff/orders", {
  method: "POST",
  headers: { "Content-Type": "application/json", "X-CSRF": "1" },
  body: JSON.stringify(order),
});

Ein BFF verhindert kein Cross-Site-Scripting: Eingeschleuster Code kann den BFF weiter aufrufen, solange die Seite offen ist, also halte eine Content Security Policy bereit. Native Apps folgen stattdessen RFC 8252 und führen den Code-Flow mit PKCE im System-Browser aus, daher validiert ein Mobile-BFF meist nur ein Bearer-Token.

Fallstricke

• Duplizierte Logik. Newman bevorzugt etwas Duplikation gegenüber geteiltem Code, der BFFs koppelt. Taucht Logik ein drittes Mal auf, extrahiere sie: eine Bibliothek für technischen Code, einen Domain-Service für Geschäftslogik. SoundCloud baute einen UserProfileService, nachdem etwa fünf BFFs jeweils selbst Nutzerprofile zusammengesetzt hatten.
• Der BFF als Monolith. Warnzeichen: Er besitzt Domain-Daten oder Geschäftsregeln, andere BFFs rufen ihn auf, oder mehrere Teams committen darauf. Ein Rabatt, den der Web-BFF berechnet, der Mobile-BFF aber nicht, ist ein Bug, den ein Kunde findet.
• Fan-out-Latenz. Ruft ein BFF fünf Services parallel auf, beträgt die Wahrscheinlichkeit, dass mindestens einer langsamer antwortet als sein eigenes p99, 1 − 0,99^5 ≈ 4,9 %: Das p95 des BFF entspricht grob dem p99 der Services. Dean und Barrosos The Tail at Scale behandelt Gegenmaßnahmen.
• Ein weiterer Hop. Jeder BFF fügt Latenz, ein Deployment und eine Bereitschaftsrotation hinzu, und Services, die per IP-Adresse ratenbegrenzen, sehen nun nur noch die Adresse des BFF.

Timeouts, Teilantworten und Circuit Breaker

Setze pro Screen ein Deadline-Budget und teile es auf: Bei 800 ms im BFF lässt ein Timeout von 300 ms pro Aufruf Platz für einen Retry. Führe unabhängige Aufrufe parallel aus und gib die Deadline weiter.

Entscheide dann, welche Daten erforderlich sind. Newmans Wunschliste braucht die Liste, kann aber ohne Lagerbestände rendern. Gib zurück, was du hast, und markiere, was fehlt:

{
  "items": [{ "id": "sku-123", "name": "Trail shoe", "price": "$89.00" }],
  "stock": null,
  "errors": [{ "section": "stock", "reason": "timeout" }]
}

Gib jedem nachgelagerten Service einen eigenen Circuit Breaker und Connection-Pool, damit ein langsamer Service schnell fehlschlägt, statt jeden Worker festzuhalten; das Circuit-Breaker-Pattern behandelt Schwellenwerte und Fallbacks. Wiederhole nur idempotente Lesezugriffe, und zwar auf einer Ebene, und cache aggregierte Antworten nicht länger, als ihr frischester Teil erlaubt.

Das BFF-Architekturdiagramm

So liest du es:

• Eine Zeile pro Client-Erlebnis, eingefärbt nach dem verantwortlichen Team. Jeder Client ruft nur seinen eigenen BFF auf.
• Jeder BFF verteilt auf die gemeinsamen Services; sein Pfeil endet am Rahmen, weil er aufruft, welche Services seine Screens gerade brauchen.
• Gestrichelte Kanten gelten nur für die Anmeldung. Der Browser wird zum Identitätsanbieter umgeleitet, dann tauscht der Web-BFF den Code gegen Tokens – derselbe Schritt wie bei einer Anmeldung mit OpenID Connect.
• Tokens bleiben auf dem Server, im Session-Store unter einer Session-ID. Ein verschlüsseltes Cookie funktioniert auch, und RFC 10017 bevorzugt es jenseits kleiner Deployments.
• Der Markdown-Block listet die Cookie-Einstellungen und ein Beispielbudget pro Screen auf.

BFF-Diagramme übersichtlich zeichnen

• Gib jedem Client eine Zeile mit seinem BFF, beschriftet mit dem verantwortlichen Team.
• Beschrifte, was über jede Kante läuft: ein Session-Cookie, ein Bearer-Token oder Client-Credentials.
• Zeige, wo die Tokens liegen, in einem Store oder in einem verschlüsselten Cookie.
• Zeichne das Gateway separat. Eine Box für Gateway und BFFs verbirgt die Verantwortung.
• Achte auf den Hub. Eine BFF-Box, die mit jedem Client verbunden ist, ist ein Allzweck-Backend.
• Verzichte auf die Endpunktliste. Eine beschriftete Kante pro BFF zu einer Service-Grenze genügt; die Service-Seite behandelt ein Diagramm der Microservices hinter den BFFs.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und erstelle ein Diagramm.
2. Füge aus dem Paket C4-Modell je einen Container für die Web-App und die Mobile-App sowie ein Externes System für den Partner hinzu, jeweils eine pro Zeile.
3. Füge neben jedem Client einen Container für dessen BFF hinzu, mit Technologie und Beschreibung.
4. Füge aus dem Paket Basis einen Rahmen namens Shared services (domain teams) hinzu, der drei Container-Nodes enthält: catalog, orders und profile.
5. Füge über der Web-Zeile einen Identitätsanbieter aus dem Paket Sicherheit und einen Redis-Node aus dem Paket Daten als Session-Store hinzu.
6. Verbinde jeden Client mit seinem BFF und jeden BFF mit dem Rahmen, beschrifte die Kanten, strichele die beiden Anmelde-Kanten und färbe jede Zeile nach Team.
7. Füge einen Basis-Markdown-Block mit den Cookie-Einstellungen und dem Budget sowie Basis-Text-Beschriftungen für die Teams hinzu.

Wenn deine Services schon in einem Mermaid-Flowchart liegen, liefert dir der Mermaid-Konverter einen bearbeitbaren ersten Entwurf. Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist das Backend-for-Frontend-Pattern (BFF)? Eine serverseitige API, die für ein Client-Erlebnis gebaut ist, etwa eine Web-App, Mobile-App oder Partner-Integration, und dem Team dieses Clients gehört. Sie aggregiert Backend-Aufrufe und formt die Antworten.

Was ist der Unterschied zwischen einem BFF und einem API-Gateway? Ein Gateway bedient alle Clients und übernimmt Routing, Token-Prüfungen und Rate-Limits. Ein BFF bedient einen Client und ändert sich mit dessen Screens. Viele Systeme stellen ein Gateway vor mehrere BFFs.

Ersetzt GraphQL das BFF-Pattern? Es kann, weil Clients die Felder auswählen, die sie brauchen. Trotzdem muss jemand das Schema und die Query-Limits besitzen, und ein für einen Client gebauter GraphQL-Server ist selbst ein BFF.

Wie funktioniert die BFF-Authentifizierung? Der BFF ist ein vertraulicher OAuth-Client: Er führt den Authorization-Code-Flow mit PKCE aus, hält die Tokens auf dem Server und gibt dem Browser nur ein HttpOnly-Session-Cookie.

Wie viele BFFs sollte ich haben? Einen pro Nutzererlebnis, abgestimmt auf deine Teams. Zwei Apps mit demselben Erlebnis und demselben verantwortlichen Team können sich einen teilen.

Kostenlos starten — ein Seat, keine Kreditkarte.