Backend for Frontend
Ein BFF übersetzt zwischen einer Clientfamilie und fachlichen APIs.
- ClientfamilieTeilt Interaktion, Netzbedingungen und Releasezyklus.
- AdapterFormt und aggregiert Daten für genau diese Familie.
- FachgrenzeLässt Preise, Bestand und Zahlung beim zuständigen Modul.
Einordnung
Warum das wichtig ist
Es lohnt sich bei messbar verschiedenen Clientbedürfnissen und klarer Eigentumsgrenze.
Die mobile App und ihr BFF sind hypothetisch; der aktuelle Shop hat eine Weboberfläche und sieben Module.
Aufgaben am Client-Rand
Der heutige Shop besitzt sieben Module und eine Weboberfläche im modularen Monolithen. Eine hypothetische mobile App benötigt kleinere Produktbilder, eine kompakte Bestellübersicht und weniger Roundtrips; ein Mobile-BFF aggregiert dafür Katalog und Bestellung. Die Weboberfläche nutzt weiterhin ihren vorhandenen serverseitigen Adapter. Preise, Reservierung und Zahlungsstatus werden ausschließlich von den zuständigen Modulen entschieden. Das Team misst Payloadgröße, Aufrufzahl und Änderungsrate, bevor es den zusätzlichen Dienst dauerhaft betreibt.
So liest du das Bild
- Clientfamilie Mobile getrennt von Web
- Adapter Clientvertrag statt interne APIs
- Fachgrenze Keine Regelkopie im BFF
| Vergleich | Aufgabe | BFF | Fachmodul |
|---|---|---|---|
| Antwortform | Clientgerechte Felder und Bildgrößen | Ja | Liefert maßgebliche Rohdaten |
| Aggregation | Weniger Client-Roundtrips | Ja | Bleibt einzeln verantwortlich |
| Preisentscheidung | Fachregel und Rundung | Nein | Katalog bestimmt den Preis |
Nutzen & Grenzen
Hilft, wenn
- Clients unterscheiden sich deutlich in Interaktion oder Netzbedingungen.
- Getrennte Teams und Releasezyklen brauchen unabhängige Clientverträge.
- Aggregation reduziert nachweisbar Roundtrips oder Payload.
Grenzen
- Ein BFF pro kleinem Client erzeugt unnötige Dienste und Betriebsaufwand.
- Duplizierte Fachregeln driften zwischen BFFs auseinander.
- Gemeinsame Authentifizierung und Rate Limits müssen konsistent am Rand bleiben.
In der Praxis
- Vergleiche die Bestellübersicht für Web und Mobile. Ordne jedes verdichtete Feld einer bestehenden Fachzuständigkeit zu, damit der BFF keine zweite Geschäftsregel erfindet.
- Ändere die mobile Antwortform und prüfe, dass die Weboberfläche davon unabhängig bleibt. Beobachte, ob gemeinsame Änderungen trotzdem an einer zentralen API landen.
- Prüfe, ob unterschiedliche Clientbedürfnisse einen eigenen BFF rechtfertigen. Berücksichtige zusätzliche Deployments, Identitätsprüfung und das Risiko duplizierter Fachlogik.
Ausführliche Erklärung lesen
Mobile App, Weboberfläche oder Partnerportal können unterschiedliche Roundtrips, Datenmengen und Releasezyklen haben. Ein eigenes BFF bündelt diese Unterschiede und hält interne Schnittstellen aus dem Client heraus.
Ein BFF wird problematisch, wenn es Entscheidungen über Preis, Zahlung oder Bestand kopiert. Dann entstehen mehrere Wahrheiten und koordinierte Releases; clientnahe Formatierung, Aggregation und Zugriffskontrolle bleiben dagegen passende Aufgaben.
API Gateway bildet den gemeinsamen externen Eintritt. API-Verträge halten die fachlichen Anbietergrenzen stabil, die jedes BFF nutzt.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Aufgabe gehört typisch ins BFF?
Lösung mit Begründung ansehen
Clientgerechte Aggregation und Antwortform.
AnwendenAuf eine neue Lage übertragen
Was bleibt im Katalogmodul?
Lösung mit Begründung ansehen
Preisregeln und die maßgebliche Produktinformation.
BewertenEine Alternative abwägen
Wann ist ein weiteres BFF unnötig?
Lösung mit Begründung ansehen
Wenn Clients denselben Vertrag und ähnliche Netz- sowie Releasebedingungen haben.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.