Das Frontend lädt träge, die Mobile-App bekommt zu viele Daten und die Web-Entwickler rufen nach einem API-Änderungswunsch: das ist die Szene, in der die Idee eines Backend-for-Frontend geboren wird, einer kleinen, spezifischen Backend-Schicht, die genau die Daten und Formate liefert, die eine Oberfläche braucht.
Warum jetzt
Single-Page-Apps, native Mobile-Apps und Microservices haben die Anforderungen an APIs auseinandergezogen: verschiedene Oberflächen brauchen unterschiedliche Datenmengen, Latenz wird sicht- und spürbar und Teams sollen unabhängig liefern; das macht generische, einheitliche APIs oft zum Flaschenhals.
Was ein BFF leistet
Ein BFF formt, aggregiert und filtert Daten gezielt für eine Oberfläche, übersetzt Protokolle, verwaltet Authentifizierung und Cache und kann komplexe Orchestrierung an einer klaren Stelle bündeln; das reduziert Overfetching und beschleunigt Frontend-Rendering, schafft aber zusätzlichen Code, der gepflegt und versioniert werden muss.
Die wirtschaftliche Rechnung
Kurzfristig kostet ein BFF Entwicklung und Betrieb; langfristig spart es Zeit in Frontend-Iterationen, erhöht Conversion durch bessere Performance und verkleinert mobile Datenpakete; für Unternehmen heißt das: Investition versus Time-to-Market und Betriebskosten sorgfältig abwägen.
Ein Shop-Startup
Ein kleines E‑Commerce-Team setzte zwei BFFs ein: eins für die SPA und eins für die mobile App; das mobile BFF bündelte Produktdaten und reduzierte Antwortgrößen um 60 Prozent, wodurch die Ladezeit sank und die Kaufabbrüche sanken, während die SPA frei experimentieren konnte.
Eine öffentliche Verwaltungsplattform
Bei einer Behördenplattform diente ein BFF als Sicherheits- und Feature-Grenze zum alten Monolithen; das Team konnte neue Oberflächen unabhängig ausrollen, Zugriffsregeln zentralisieren und schrittweise APIs modernisieren, ohne den Kern der Plattform sofort umzubauen.
Risiken und Kompromisse
Die Pattern-Frage lautet nicht nur 'BFF oder nicht', sondern 'wie viele BFFs und wer pflegt sie': Mehrere spezialisierte Backends helfen dem Frontend, sorgen aber für Duplikation, inkonsistente Geschäftslogik und erhöhten Testaufwand; klare Schnittstellen, Shared Libraries und Observability sind deshalb Pflicht.
Strategie für Teams
Die beste Praxis ist pragmatisch: BFFs dort einsetzen, wo unterschiedliche Frontends wirklich unterschiedliche Anforderungen haben, gemeinsame Geschäftsregeln zentral halten und Cross-Team-Governance etablieren; Solution-Architekt, Software-Architekt und Entwickler müssen gemeinsam API-Grenzen, Deployment-Strategien und Monitoring festlegen.
