Was ist Backend for Frontend (BFF)

Ein Backend for Frontend (BFF) ist ein dedizierter Backend-Dienst, der für ein bestimmtes Frontend entwickelt wurde. Anstatt dass jeder Client (Web, iOS, Android, Drittanbieter) mit demselben Allzweck-Backend kommuniziert, erhält jeder seine eigene serverseitige Schicht, die Daten von Ihren Microservices aggregiert und so umformt, dass sie genau die Nutzlast liefern, die diese Schnittstelle benötigt.

Sam Newman benannte und popularisierte das Muster im Jahr 2015, basierend auf Arbeiten bei SoundCloud. Mehr als ein Jahrzehnt später ist das BFF-Muster immer noch ein Standardwerkzeug für Teams, die Microservices hinter mehreren Client-Apps betreiben, und Microsoft dokumentiert es als zentrales Cloud-Architekturmuster.

Das Problem, das ein BFF löst

Stellen Sie sich ein System vor, das mit einer einzigen Web-App und einem einzigen Backend begann. Das Backend stellte REST-Endpunkte bereit, die Web-App konsumierte sie, und das Leben war einfach. Dann lieferte das Unternehmen eine mobile App aus. Dann eine Partnerintegration. Dann ein Smartwatch-Widget. Plötzlich ziehen vier sehr unterschiedliche Clients alle vom selben Backend, und dieses Backend versucht, es allen gleichzeitig recht zu machen.

Dies führt zu zwei wiederkehrenden Problemen.

Über- und Unter-Abrufung (Over-fetching and under-fetching). Ein Allzweck-Endpunkt liefert eine feste Datenstruktur. Ein Desktop-Dashboard möchte möglicherweise den vollständigen Kundenstamm mit Bestellhistorie, Empfehlungen und Kontoeinstellungen in einer Antwort. Eine mobile App mit einer wackeligen Mobilfunkverbindung möchte drei Felder und nichts mehr. Wenn beide denselben Endpunkt ansprechen, erhält einer von beiden die falsche Datenmenge. Der mobile Client lädt entweder eine überladene Nutzlast herunter, die er verwerfen muss (Over-fetching), oder muss mehrere zusätzliche Roundtrips unternehmen, um das Benötigte zusammenzustellen (Under-fetching).

Schwatzhafte Clients (Chatty clients). Wenn ein Backend nicht auf einen Bildschirm zugeschnitten ist, kompensiert der Client dies, indem er viele Aufrufe tätigt. Ein mobiler Startbildschirm, der Profildaten, eine Benachrichtigungsanzahl und einen Feed benötigt, kann drei oder vier separate Anfragen an drei oder vier Microservices senden und die Ergebnisse dann auf dem Gerät zusammenfügen. Jeder zusätzliche Roundtrip kostet Latenz und Akkulaufzeit, und die Orchestrierungslogik gelangt in den Client, wo sie schwer zu testen und zu versionieren ist.

Die zugrundeliegende Spannung ist ebenso organisatorischer wie technischer Natur. Ein gemeinsam genutztes Backend hat konkurrierende Anforderungen von jedem Frontend-Team. Eine Änderung eines Teams muss vor der Auslieferung gegen die Anforderungen jedes anderen Teams validiert werden, was das Backend zu einem Engpass und einer Quelle für teamübergreifende Reibung macht.

Wie das BFF-Muster funktioniert

Das BFF-Muster führt eine dünne serverseitige Schicht ein, die zwischen einem Frontend und Ihren nachgeschalteten Diensten sitzt. Jede Schnittstelle erhält ihr eigenes Backend.

[ Web app ]    --->  [ Web BFF ]    ---\
[ iOS app ]    --->  [ iOS BFF ]    -----> [ Microservices ]
[ Android app] --->  [ Android BFF ] ---/

Jedes BFF erfüllt drei Aufgaben für seinen Client:

1. Aggregieren. Es ruft die nachgeschalteten Microservices auf, die der Bildschirm benötigt, und kombiniert deren Antworten, sodass der Client nur eine Anfrage statt fünf stellt. Dies ist API-Aggregation, angewendet auf ein einzelnes Benutzererlebnis. Wenn Sie die allgemeine Version dieser Idee wünschen, lesen Sie unsere Erläuterung zum Muster des API-Aggregators.
2. Umformen (Reshape). Es kürzt Felder, benennt Dinge in clientfreundliche Begriffe um, glättet verschachtelte Strukturen und formatiert Werte so, wie die Schnittstelle es erwartet. Das mobile BFF liefert schlanke Nutzlasten; das Desktop-BFF liefert reichhaltige.
3. Übersetzen (Translate). Es behandelt clientspezifische Anliegen wie Paginierungsstrategie, auf den Client abgestimmtes Response-Caching und Protokollentscheidungen, ohne diese Entscheidungen den darunter liegenden gemeinsam genutzten Diensten aufzuzwingen.

Die nachgeschalteten Microservices bleiben allgemein gehalten und frontend-agnostisch. Sie bieten saubere, wiederverwendbare Funktionen. Das BFF ist der Ort, an dem die clientspezifische Gestaltung angesiedelt ist, wodurch diese Logik sowohl aus den Microservices als auch aus der Client-App herausgehalten wird. Wenn Sie neu in der darunter liegenden Dienstschicht sind, geben unsere Übersichten über Microservices im Vergleich zu APIs und der Übergang von einem Monolithen zu Microservices den Kontext vor.

Ein BFF pro Client-Erlebnis

Newmans Kernanleitung ist kurz: ein Erlebnis, ein BFF. Wenn Ihre iOS- und Android-Apps sich bedeutsam voneinander unterscheiden, geben Sie jeder ein eigenes BFF. Wenn eine Web-App und eine mobile App auseinanderdriften, gilt dieselbe Regel.

Der Sinn der Regel ist es, jedes BFF fokussiert zu halten. Sobald ein einziges BFF versucht, zwei Clients mit unterschiedlichen Bedürfnissen zu bedienen, beginnt es, bedingte Logik anzuhäufen ("wenn mobil, gib dies zurück; wenn Web, gib das zurück"), und Sie sind wieder bei einem Allzweck-Backend mit all denselben Koordinationsproblemen. Ein fokussiertes BFF bleibt klein, was die Eigenschaft ist, die das gesamte Muster rentabel macht.

Es gibt eine vernünftige Ausnahme, die Newman selbst von SoundCloud ableitet: Wenn ein Team zwei ähnliche Clients besitzt, wie z.B. iOS- und Android-Apps, die fast das gleiche Erlebnis teilen, kann es sinnvoll sein, ein einziges mobiles BFF zwischen ihnen zu teilen. Der entscheidende Faktor ist Besitz und Ähnlichkeit, nicht Plattformnamen. Die Regel ist eine Standardeinstellung, kein Gesetz.

Die Verantwortung liegt beim Frontend-Team

Ein BFF ist keine Schicht, die das Plattformteam erstellt und übergibt. Das Frontend-Team, das den Client besitzt, besitzt auch sein BFF. Dies ist die zweite Hälfte dessen, was das Muster zum Funktionieren bringt.

Wenn das Frontend-Team das BFF besitzt, kontrolliert es dessen Release-Kadenz, wählt dessen Sprache und Laufzeitumgebung, priorisiert dessen Backlog und liefert Änderungen am Client und seinem unterstützenden Dienst gemeinsam aus. Eine UI-Änderung, die einen neuen aggregierten Endpunkt erfordert, erfordert kein Ticket bei einem separaten Backend-Team und kein Warten, bis dieses Team seine Warteschlange abgearbeitet hat. Das Team, das den Schmerz spürt, besitzt die Lösung.

Diese Autonomie ist der wahre Gewinn. Das BFF verschiebt die Grenze so, dass clientspezifische Entscheidungen von den Personen getroffen werden, die für den Client verantwortlich sind, was genau dem entspricht, wo das Denken der API-gesteuerten Konnektivität die "Erlebnisebene" ansiedelt.

BFF vs. API-Gateway

Dies ist der Vergleich, an dem die meisten Teams stolpern, denn ein BFF und ein API-Gateway sehen auf einem Diagramm ähnlich aus. Beide sitzen zwischen Clients und Diensten. Beide können routen und aggregieren. Aber sie beantworten unterschiedliche Fragen.

Ein API-Gateway ist ein allgemeiner Einstiegspunkt, der übergreifende Anliegen für den gesamten Traffic handhabt: Authentifizierung, Ratenbegrenzung, Routing, TLS-Terminierung und Request-Logging. Es wird von einem Plattform- oder Infrastrukturteam betrieben und ist bewusst client-agnostisch. Ein Gateway bedient alle auf die gleiche Weise.

Ein BFF ist das Gegenteil. Es ist von Natur aus clientspezifisch, gehört einem Frontend-Team, und sein ganzer Zweck ist es, für jede Schnittstelle anders zu sein. Es ist der Ort, an dem die Nutzlastgestaltung eines Clients angesiedelt ist, kein gemeinsamer Engpass.

Die beiden sind keine Rivalen. In einer gängigen Produktionsumgebung sitzt ein API-Gateway davor, das Authentifizierung, Ratenbegrenzung und Überwachung für den gesamten Traffic handhabt, und leitet dann jeden Client zu seinem dedizierten BFF hinter dem Gateway weiter. Microsofts Referenzarchitektur zeigt genau dies: ein Gateway, das übergreifende Anliegen verwaltet, mit einem serverlosen BFF pro Client dahinter. Nutzen Sie das Gateway für das, was clientübergreifend gleich ist, und ein BFF für das, was unterschiedlich ist. (Die tiefere Version dieses Kontrasts behandeln wir in einem separaten Artikel; hier genügt es zu wissen, dass sie auf verschiedenen Ebenen sitzen und unterschiedliche Bedürfnisse beantworten.)

Für die umgebende Gateway-Landschaft helfen diese veröffentlichten Vergleiche: API-Management vs. API-Gateway, API-Gateway vs. Load Balancer und Service Mesh vs. API-Gateway.

Wann ein BFF verwendet werden sollte

Das Muster zahlt sich aus, wenn folgende Bedingungen erfüllt sind:

• Sie haben mehrere, tatsächlich unterschiedliche Clients. Web plus Mobil plus eine Partnerintegration, jeder mit unterschiedlichen Datenanforderungen. Je stärker die Erlebnisse divergieren, desto mehr hilft ein BFF.
• Ein gemeinsam genutztes Backend ist zu einem Engpass geworden. Wenn jede Frontend-Änderung eine teamübergreifende Verhandlung erzwingt, beseitigt die Aufteilung der clientspezifischen Gestaltung in teamweise BFFs den Koordinationsaufwand.
• Sie möchten client-optimierte Nutzlasten. Mobil benötigt schlanke Antworten und aggressives Caching; Desktop möchte reichhaltige aggregierte Daten. Ein BFF ermöglicht es Ihnen, beides kompromisslos zu optimieren.
• Eine Sprache passt besser zu einem Frontend. Ein Team kann sein BFF in der Laufzeitumgebung erstellen, die zu seinem Client passt, unabhängig davon, welche die anderen BFFs verwenden.

Wann ein BFF nicht verwendet werden sollte

Das Muster ist nicht kostenlos, und es gibt klare Fälle, in denen es Kosten ohne Nutzen verursacht:

• Sie haben nur einen Client. Bei einer einzelnen Schnittstelle ist ein BFF nur ein zusätzlicher Sprung. Erstellen Sie ein normales Backend.
• Ihre Clients stellen dieselben Anfragen. Wenn Web und Mobil nahezu identische Daten in derselben Form wünschen, führen separate BFFs zu doppelter Arbeit ohne Vorteil. Konsolidieren Sie stattdessen.
• GraphQL löst bereits Ihr Gestaltungsproblem. Mit GraphQL fragt jeder Client genau die Felder ab, die er von einem einzigen Endpunkt benötigt, was einen Großteil dessen abdeckt, was ein BFF für die Nutzlastgestaltung leistet. Wenn Sie eine GraphQL-Schicht mit frontend-spezifischen Resolvern haben, bringt eine separate BFF-Ebene oft keinen Mehrwert. Sehen Sie sich an, was GraphQL ist, um zu beurteilen, ob es passt, bevor Sie eine BFF-Ebene hinzufügen.
• Ein Gateway plus Microservices ist ausreichend. Für einfachere Systeme kann ein API-Gateway vor gut konzipierten Microservices akzeptable Ergebnisse liefern, ohne eine dedizierte clientbezogene Ebene.

Die ehrlichen Nachteile

Auch wenn ein BFF die richtige Wahl ist, entstehen echte Kosten. Mit offenen Augen an die Sache heranzugehen, ist Teil der guten Nutzung des Musters.

Code-Duplikation. Dies ist der Haupthandelsplatz, und Microsofts Dokumentation weist direkt darauf hin. Wenn drei BFFs alle dieselbe Authentifizierungsprüfung aufrufen oder dasselbe Datum auf dieselbe Weise formatieren müssen, wird diese Logik tendenziell dreimal geschrieben. Sie tauschen Duplikation gegen Anpassung. Die Lösung ist Disziplin: Halten Sie tatsächlich gemeinsam genutzte Logik in Bibliotheken, die die BFFs importieren, und reservieren Sie das BFF selbst für clientspezifische Gestaltung. Verlagern Sie echte übergreifende Anliegen (Auth, Ratenbegrenzung, Überwachung) auf das Gateway, anstatt sie pro BFF neu zu implementieren.

Mehr Dienste zu betreiben. Jedes BFF ist eine weitere deploybare Einheit mit eigenem Lebenszyklus, Pipeline, Bereitschaftsdienst und Sicherheitsangriffsfläche. Mehr Dienste bedeuten mehr Betriebsaufwand.

Ein zusätzlicher Netzwerk-Hop. Clients kommunizieren nicht mehr direkt mit den Diensten. Das BFF fügt einen Hop hinzu, und das kann Latenz verursachen. Es ist normalerweise ein lohnender Kompromiss, da das BFF mehrere Client-Roundtrips durch eine Client-zu-BFF-Anfrage ersetzt und das BFF Dienste parallel nahe an ihnen aufrufen lässt, aber es ist ein Kostenfaktor, der gemessen und nicht angenommen werden sollte.

Risiko der Aufblähung des BFF. Wenn ein BFF beginnt, mehrere Clients zu bedienen oder Geschäftslogik aufzunehmen, die in die Microservices gehört, driftet es wieder in Richtung des Allzweck-Backends, dem Sie entfliehen wollten. Halten Sie es schlank.

BFF-Verträge mit Apidog synchron halten

Der schwierigste Teil beim Betrieb von BFFs in der Praxis sind die Verträge. Jedes BFF stellt seine eigene clientseitige API bereit und hängt auch von den Verträgen der darunter liegenden Microservices ab. Das sind viele sich bewegende Schnittstellen über Teams hinweg, die unterschiedliche Schichten besitzen, und Abweichungen zwischen ihnen sind die Ursache für Fehler und defekte Clients.

Hier kommt Apidog ins Spiel. Apidog ist eine Plattform für API-Design, -Tests, -Mocking und -Dokumentation, sodass der API-Vertrag jedes BFFs ein einziges Zuhause hat, an dem sowohl Frontend- als auch Backend-Teams arbeiten können:

• Vertrag zuerst entwerfen. Definieren Sie jeden BFF-Endpunkt und sein Anfrage- und Antwortschema in Apidogs visuellem Designer mit OpenAPI als Basis, sodass die clientseitige Form vor dem Schreiben von Code vereinbart wird. Dies ist der Contract-First-Ansatz, angewendet auf die BFF-Schicht, und er hält den API-Vertrag explizit.
• Mocken, bevor es existiert. Das Frontend-Team kann am Tag der Vertragsvereinbarung mit dem Aufbau gegen einen Apidog Smart Mock des BFF beginnen, ohne darauf zu warten, dass das BFF oder seine nachgeschalteten Dienste bereit sind.
• Den Vertrag testen. Apidogs automatisierte Tests und Zusicherungen überprüfen, ob jedes BFF die aggregierte, umgeformte Nutzlast zurückgibt, die sein Client erwartet, und sie passen in CI, sodass eine nachgeschaltete Änderung, die eine BFF-Antwort unterbricht, frühzeitig erkannt wird.
• Dokumentieren für beide Seiten. Apidog generiert automatisch interaktive Dokumentationen aus dem Vertrag, sodass das Frontend-Team, das die API des BFF liest, und das Backend-Team, das die darunter liegenden Dienste besitzt, eine einzige Quelle der Wahrheit teilen.

Um den Umfang klarzustellen: Apidog erstellt, hostet oder betreibt Ihr BFF nicht, und es ist kein API-Gateway. Es ist der Ort, an dem Sie den API-Vertrag entwerfen, mocken, testen und dokumentieren, hinter dem jedes BFF steht, was Frontend- und Backend-Teams synchron hält, während sich die BFFs entwickeln. Jedes BFF als Produkt mit einem stabilen, gut dokumentierten Vertrag zu behandeln, macht das Muster nachhaltig.

FAQ

Ist ein BFF ein Microservice? Ein BFF ist ein serverseitiger Dienst und wird in einer Microservices-Umgebung normalerweise als solcher ausgeführt. Aber seine Aufgabe unterscheidet sich von einem typischen Microservice. Ein Microservice besitzt eine Geschäftsfunktion und bleibt client-agnostisch; ein BFF besitzt das Erlebnis eines Clients und existiert, um diese Microservices für diesen Client zu aggregieren und umzuformen. Es ist ein Dienst auf der Erfahrungsebene, kein Dienst für Geschäftsfunktionen.

Wie viele BFFs sollte ich haben? Standardmäßig ist es eines pro eindeutigem Client-Erlebnis: eines für Web, eines für iOS, eines für Android und so weiter. Kombinieren Sie zwei nur, wenn ein einzelnes Team Clients mit nahezu identischen Bedürfnissen besitzt. Teilen Sie weiter auf, wenn ein BFF anfängt, pro-Client bedingte Logik anzuhäufen.

Ersetzt GraphQL das BFF-Muster? Es kann, für den Teil der Nutzlastgestaltung. GraphQL ermöglicht es jedem Client, genau die Felder von einem Endpunkt anzufordern, die er benötigt, was Über- und Unter-Abrufung ohne ein clientbezogenes Backend abdeckt. Wenn Sie GraphQL mit frontend-spezifischen Resolvern haben, bringt eine separate BFF-Ebene oft wenig Mehrwert. BFFs helfen immer noch, wenn Sie pro-Client-Orchestrierung, Protokollübersetzung oder Laufzeitentscheidungen benötigen, die ein gemeinsamer GraphQL-Server nicht einfach bereitstellen kann.

Kann ich ein BFF und ein API-Gateway zusammen verwenden? Ja, und das ist üblich. Das API-Gateway kümmert sich um alle Clients betreffende Belange wie Authentifizierung, Ratenbegrenzung und Überwachung und leitet den Traffic an das richtige BFF weiter. Jedes BFF kümmert sich um das, was für seinen Client spezifisch ist. Sie befinden sich auf unterschiedlichen Ebenen und erfüllen unterschiedliche Aufgaben.

Wer sollte das BFF besitzen? Das Frontend-Team, das den Client besitzt. Diese Verantwortlichkeit ist zentral für das Muster. Sie ermöglicht es dem Team, UI-Änderungen und die unterstützenden Endpunkte gemeinsam auszuliefern, seine eigene Laufzeitumgebung zu wählen und sich zu bewegen, ohne auf die Warteschlange eines separaten Backend-Teams warten zu müssen.

Fügt ein BFF Latenz hinzu? Es fügt einen Netzwerk-Hop hinzu, was Kosten verursacht. In der Praxis reduziert es jedoch normalerweise die gesamte Client-Latenz, da es mehrere Client-zu-Dienst-Roundtrips durch eine Client-zu-BFF-Anfrage ersetzt und es dem BFF ermöglicht, Dienste parallel in ihrer Nähe aufzurufen. Messen Sie es für Ihre Arbeitslast, anstatt es einfach anzunehmen.