„BFF vs. API Gateway“ ist eines der am häufigsten verwechselten Duelle in der Microservices-Architektur. Die beiden Muster sehen auf einem Diagramm ähnlich aus. Beide sitzen vor Ihren Diensten. Beide empfangen eine Client-Anfrage und leiten sie an Backends weiter. Daher gehen Teams davon aus, dass sie konkurrierende Optionen sind, wählen eine aus und weisen ihr am Ende die falschen Verantwortlichkeiten zu.
Sie sind keine Konkurrenten. Ein Backend for Frontend (BFF) und ein API-Gateway lösen unterschiedliche Probleme, werden von unterschiedlichen Teams verwaltet und laufen sehr oft zusammen im selben System. Das BFF sitzt hinter oder neben dem Gateway, nicht an seiner Stelle.
Dieser Leitfaden zieht die Grenze klar. Sie erfahren, was jedes Muster tatsächlich ist, wo sie sich überschneiden, wann man eines oder beide verwendet und welche Fehler durch ihre Vermischung entstehen. Durchgängig ist der API-Vertrag die Konstante: Ob eine Anfrage durch ein Gateway, ein BFF oder beides fließt, jede Schicht stellt eine API bereit, die Sie immer noch entwerfen, testen, simulieren und dokumentieren müssen.
Was ist ein API-Gateway?
Ein API-Gateway ist ein zentraler Einstiegspunkt, der zwischen Clients und Ihren Backend-Diensten sitzt. Jede Anfrage kommt über das Gateway herein, das eine konsistente Reihe von Querschnittsaufgaben anwendet, bevor es den Aufruf weiterleitet.
Diese Aufgaben sind für jeden Client und jeden Dienst gleich:
- Routing: Gleichen Sie einen eingehenden Pfad dem richtigen Upstream-Dienst zu.
- Authentifizierung und Autorisierung: Überprüfen Sie Token, lehnen Sie unbefugte Aufrufer ab.
- Ratenbegrenzung und Drosselung: Schützen Sie Backends vor Überlastung und Missbrauch.
- Observability: Protokollieren Sie Anfragen, geben Sie Metriken aus, verfolgen Sie Aufrufe über Dienste hinweg.
- TLS-Terminierung, Caching und Anfragetransformation: Erledigen Sie die Infrastruktur einmal, an einem Ort.
Das entscheidende Merkmal des Gateways ist, dass es universell einsetzbar und zentral verwaltet wird. Ein Plattform- oder Infrastrukturteam betreibt es, und es bedient alle Clients gleichermaßen. Es ist irrelevant, ob der Aufrufer eine mobile App, eine Web-SPA oder eine Partnerintegration ist; es wendet dieselben Richtlinien auf alle an.
Dies macht das Gateway zum natürlichen Ort für unternehmensweite Regeln. Wenn Sie möchten, dass jede Anfrage auf dieselbe Weise authentifiziert oder jede API konsistent ratenbegrenzt wird, erzwingt das Gateway dies, ohne dass jeder Dienst die Logik neu implementieren muss. Wie sich dies von breiteren Plattform-Tools unterscheidet, sehen Sie unter API-Management vs. API-Gateway.
Was ist ein Backend for Frontend (BFF)?
Ein Backend for Frontend, von Sam Newman eingeführt, dreht die Ausrichtung um. Anstatt eines allgemeinen Backends, das jeden Client bedient, bauen Sie ein Backend pro Benutzererfahrung. Die Web-App erhält ein Web-BFF. Die mobile App erhält ein mobiles BFF. Jedes BFF ist genau auf ein Frontend zugeschnitten. Das Muster entstand aus der Microservices-Arbeit, wo ein einziges geteiltes Backend, das viele Clients bedient, die gleiche Art von Engpass wird wie ein Monolith.
Newmans Faustregel lautet: „Eine Erfahrung, ein BFF.“ Deutlich unterschiedliche Frontends erhalten ihr eigenes BFF; ähnliche (eine iOS- und eine Android-App, die vom selben Team gepflegt werden) können sich eines teilen.
Das entscheidende Merkmal hier ist der Besitz und die Form. Ein BFF ist „eng an eine spezifische Benutzererfahrung gekoppelt und wird typischerweise vom selben Team wie die Benutzeroberfläche gepflegt“, in Newmans Worten. Das Frontend-Team besitzt sein BFF. Sie entwickeln den Client und sein Backend gemeinsam weiter, ohne auf ein separates Backend-Team warten zu müssen, um jede Änderung zu genehmigen.
Was macht ein BFF eigentlich? Es formt Daten für einen Client:
- Aggregation: Ein mobiler Bildschirm benötigt Daten von fünf Microservices. Das mobile BFF ruft alle fünf auf und gibt eine kombinierte Antwort zurück, sodass das Telefon einen einzigen Roundtrip anstelle von fünf durchführt.
- Trimmen und Umformen: Der mobile Client benötigt nur drei von vierzig Feldern. Das BFF entfernt den Rest, um Bandbreite zu sparen.
- Clientspezifische Formatierung: Die Desktop-App ruft mehrere Seiten gleichzeitig für eine umfassende Ansicht ab; die mobile App ruft eine Seite ab, um schlank zu bleiben. Jedes BFF bedient das Muster seines Clients.
Das BFF ist eine Art API-Aggregator mit Persönlichkeit: Es komponiert Downstream-Aufrufe, aber immer im Dienste eines spezifischen Frontends und nicht als neutrale, geteilte Schicht.
Wo sich BFF und API-Gateway überschneiden
Die Verwirrung ist verständlich, da die beiden Muster oberflächlich ähnliche Verhaltensweisen aufweisen. Beide fangen Client-Anfragen ab. Beide können an Backends weiterleiten. Beide können mehrere Dienste aufrufen und Ergebnisse kombinieren. Ein Diagramm beider sieht aus wie eine Box zwischen Clients und Diensten.
Die Überschneidung ist real, aber oberflächlich. Der Unterschied liegt in der Absicht und dem Besitz:
- Ein API-Gateway aggregiert und leitet generisch, für alle Clients, um Richtlinien zu zentralisieren.
- Ein BFF aggregiert und leitet spezifisch, für ein Frontend, um die Erfahrung dieses Clients zu optimieren.
Microsofts eigene Empfehlung ist unmissverständlich, welche Aufgaben wohin gehören. Querschnittsfunktionen wie Monitoring, Autorisierung und Ratenbegrenzung sollten aus dem BFF abstrahiert und separat durch Gateway-ähnliche Muster behandelt werden. Das BFF sollte nur client-spezifische Logik enthalten. Wenn Sie Authentifizierung und Drosselung in ein BFF integrieren, haben Sie gerade die Hälfte eines Gateways schlecht nachgebaut, und Sie müssen es in jedem BFF, das Sie schreiben, erneut tun.
Die praktische Grenze ist also diese: Wenn eine Verantwortung für jeden Client gleich ist, gehört sie in das Gateway. Wenn sie sich pro Frontend ändert, gehört sie in das BFF.
BFF und API-Gateway im Zusammenspiel
In realen Microservices-Systemen wählen Sie selten nur eines. Sie betreiben beide, geschichtet. Das Gateway sitzt am Rand. Die BFFs sitzen dahinter.
Ein typischer Anfrageablauf sieht wie folgt aus:
- Der mobile Client sendet eine Anfrage mit seinem Authentifizierungstoken.
- Das API-Gateway validiert das Token, erzwingt Ratenbegrenzungen, protokolliert die Anfrage zur Beobachtbarkeit und leitet sie dann an das mobile BFF weiter.
- Das mobile BFF ruft den Produktservice, den Inventarservice und den Preisservice auf, aggregiert die Ergebnisse, kürzt die Nutzlast auf das, was der mobile Bildschirm benötigt, und gibt eine einzige Antwort zurück.
- Das Gateway streamt die Antwort zurück an den Client.
Microsofts Referenzarchitektur für dieses Muster macht genau das: Ein API-Management-Gateway übernimmt Autorisierung, Monitoring, Caching und Routing und leitet dann an client-spezifische BFF-Dienste weiter, die als serverlose Funktionen laufen und die zugrunde liegenden Microservices aufrufen.
Jede Schicht tut, worin sie gut ist. Das Gateway besitzt die Richtlinien, die einheitlich sein müssen. Das BFF besitzt die Form, die spezifisch sein muss. Das Frontend-Team liefert Änderungen an seinem BFF aus, ohne die Gateway-Konfiguration zu berühren, und das Plattform-Team verschärft eine Ratenbegrenzung, ohne ein BFF neu zu deployen.
Diese Schichtbeziehung ähnelt der Art und Weise, wie ein Gateway mit anderer Infrastruktur koexistiert, anstatt sie zu ersetzen. Ein Gateway ist kein Lastausgleich (API-Gateway vs. Lastausgleich) und auch kein Service Mesh (Service Mesh vs. API-Gateway); jedes behandelt eine eigene Schicht des Anfragepfads, und ein BFF ist einfach eine weitere eigene Schicht. Es ist dasselbe Prinzip wie bei der API-gesteuerten Konnektivität: Jede Schicht erhält eine klare Aufgabe und soll nur diese erledigen.
Entscheidungstabelle: BFF vs. API-Gateway
| Frage | API-Gateway | BFF |
|---|---|---|
| Wem gehört es? | Plattform- / Infrastrukturteam | Dem Frontend-Team, das es konsumiert |
| Wem dient es? | Allen Clients, einheitlich | Einem spezifischen Frontend |
| Hauptaufgabe | Querschnittsaufgaben: Authentifizierung, Ratenbegrenzung, Routing, Observability | Clientspezifische Aggregation und Datenformung |
| Wie viele betreiben Sie? | Normalerweise eines (pro Edge) | Eines pro unterschiedlicher Benutzererfahrung |
| Kopplung | Lose, Client-agnostisch | Eng, Client-spezifisch von Natur aus |
| Änderungsfrequenz | Stabil, plattformgesteuert | Schnell, folgt der Roadmap des Frontends |
| Gehört hinein | Alles, was für jeden Client identisch ist | Alles, was für einen Client einzigartig ist |
Lesen Sie dies als eine Routing-Frage für Verantwortlichkeiten. Das Gleiche für alle gehört in das Gateway. Unterschiedliches pro Frontend gehört in das BFF. Wenn eine Verantwortung beides umfasst (Sie möchten eine zentrale Authentifizierung, aber auch eine client-spezifische Nutzlastformung), ist das Ihr Signal, beide Schichten zu betreiben, und nicht, sich für eine Seite zu entscheiden.
Wann was verwenden
Verwenden Sie ein API-Gateway, wenn Sie mehrere Dienste haben und einen einzigen, konsistenten Ort benötigen, um Authentifizierung, Ratenbegrenzung und Routing zu erzwingen. Fast jedes Microservices-System profitiert davon. Wenn Sie mehr als eine Handvoll Dienste für Clients exponieren, möchten Sie ein Gateway, bevor Sie etwas anderes möchten.
Verwenden Sie ein BFF, wenn verschiedene Clients wesentlich unterschiedliche Anforderungen an dasselbe Backend haben und eine gemeinsam genutzte allgemeine API zu einem Engpass geworden ist. Häufige Auslöser, gemäß Microsofts Empfehlung:
- Ein geteiltes Backend erfordert einen hohen Wartungsaufwand, da es konkurrierende Frontends bedient.
- Sie passen ein allgemeines Backend ständig an, um mehrere Schnittstellen zu unterstützen.
- Mobile und Web haben tatsächlich unterschiedliche Daten- und Leistungsanforderungen.
Verzichten Sie auf ein BFF, wenn alle Ihre Schnittstellen die gleichen oder ähnliche Anfragen stellen oder nur eine Schnittstelle mit dem Backend kommuniziert. Ein BFF fügt einen Netzwerk-Hop, mehr zu deployende Dienste und wahrscheinlich eine gewisse Code-Duplizierung über BFFs hinweg hinzu. Wenn eine einzige geteilte API jeden Client gut bedient, ist ein BFF ein Overhead, den Sie nicht benötigen. Microsoft bemerkt, dass eine GraphQL-Schicht mit pro-Frontend-Resolvern auch die Notwendigkeit eines separaten BFFs eliminieren kann, da Clients genau die Felder anfordern, die sie wünschen.
Verwenden Sie beides, wenn Sie Microservices in großem Maßstab betreiben: das Gateway für eine einheitliche Richtlinie am Rand, BFFs dahinter für client-spezifische Formung. Dies ist der übliche Endzustand, kein exotischer.
Häufige Fehler
Authentifizierung und Ratenbegrenzung ins BFF legen. Dies ist der Hauptfehler. Querschnittsaufgaben gehören ins Gateway. Duplizieren Sie sie über BFFs hinweg, und Sie erhalten Abweichungen: Das mobile BFF erzwingt eine Richtlinie, das Web-BFF eine andere, und Ihre Sicherheitslage ist nun zufällig inkonsistent.
Das BFF zu einem zweiten Monolithen werden lassen. Ein BFF soll klein und auf eine Erfahrung fokussiert sein. Wenn Teams gemeinsame Geschäftslogik hineinstopfen, wächst es wieder zu einem allgemeinen Backend heran, und Sie haben genau den Engpass wieder eingeführt, den das Muster beseitigen sollte.
Ein Gateway als BFF verwenden. Einige Teams fügen client-spezifische Anfragetransformationsregeln direkt in die Gateway-Konfiguration ein, um den Bau eines BFFs zu vermeiden. Dies funktioniert im kleinen Maßstab, aber das Gateway ist zentral verwaltet, sodass das Frontend-Team nun für jede client-spezifische Anpassung Tickets beim Plattformteam einreicht. Sie haben die falschen Teams gekoppelt.
Ein BFF bauen, wenn nur ein Client existiert. Wenn Sie eine einzelne Web-App haben und kein anderer Client in Sicht ist, ist ein BFF verfrüht. Stellen Sie die geteilte API bereit. Fügen Sie das BFF hinzu, wenn tatsächlich ein zweiter, abweichender Client auftaucht.
Den Vertrag vergessen. Jedes BFF und jede Gateway-Route exponiert eine API. Jede benötigt einen definierten Vertrag, Tests und Dokumente, genau wie jede andere API. Wenn Sie dies überspringen, wird Ihre „dünne“ BFF-Schicht zu einer undokumentierten Blackbox, gegen die niemand außerhalb des zuständigen Teams integrieren kann. Siehe was ist ein API-Vertrag, warum dies wichtig ist.
Wo Apidog passt
Ob eine Anfrage durch ein API-Gateway, ein BFF oder beides fließt, jede Schicht exponiert einen API-Vertrag. Apidog ist der Ort, an dem Sie diese Verträge entwerfen, testen, simulieren und dokumentieren. Es baut, hostet oder ersetzt kein Gateway oder BFF; es bietet Ihnen einen einzigen Arbeitsbereich für die API-Oberflächen, die sie exponieren.
Konkret:
- Design: Modellieren Sie die aggregierte Antwort des BFF oder die gerouteten Endpunkte des Gateways schema-first im visuellen Designer und generieren Sie dann OpenAPI, damit sowohl Ihr Frontend- als auch Ihr Backend-Team darauf aufbauen können.
- Simulieren: Starten Sie einen Smart Mock des BFF, damit das mobile Team seine Bildschirme entwickeln kann, bevor die Downstream-Dienste des BFF existieren. Dies ist der API-First-Workflow, der paralleles Frontend- und Backend-Arbeiten ermöglicht.
- Testen: Erstellen Sie automatisierte Testszenarien, die die über das Gateway zugänglichen Endpunkte genau wie ein echter Client ansprechen und Authentifizierung, Statuscodes und die Form der aggregierten Nutzlast validieren.
- Dokumentieren: Veröffentlichen Sie interaktive Dokumentationen für jedes BFF und jede Gateway-Route, damit jedes konsumierende Team den Vertrag kennt, ohne die Implementierung lesen zu müssen.
Das von Ihnen gewählte Muster ist eine Architektur-Entscheidung. Der Vertrag, den jede Schicht exponiert, ist eine Konstante. Apidog kümmert sich um die Konstante, sodass Ihre BFFs und Gateways entworfen, getestet, simuliert und dokumentiert bleiben, egal wie Sie sie verbinden.
Testen Sie Apidog kostenlos, um Ihre BFF- und Gateway-Verträge zu entwerfen und zu simulieren, bevor Sie eine Zeile Backend-Code schreiben.
FAQ
Ist ein BFF eine Art von API-Gateway? Nein. Sie überschneiden sich darin, dass beide routen und aggregieren können, aber ein BFF gehört einem Frontend-Team und ist auf eine Client-Erfahrung zugeschnitten, während ein API-Gateway zentral verwaltet wird und alle Clients einheitlich bedient. Ein BFF sitzt typischerweise hinter einem Gateway.
Kann ich ein BFF ohne API-Gateway verwenden? Ja, aber Sie sollten es in großem Maßstab in der Regel nicht tun. Ohne ein Gateway müsste jedes BFF Querschnittsaufgaben wie Authentifizierung und Ratenbegrenzung neu implementieren, was zu Inkonsistenzen führt. Das Gateway zentralisiert diese, sodass jedes BFF nur client-spezifische Formgebung übernimmt.
Wie viele BFFs sollte ich haben? Folgen Sie Sam Newmans Regel „eine Erfahrung, ein BFF.“ Erstellen Sie für jedes deutlich unterschiedliche Frontend ein separates BFF. Ähnliche Clients, die vom selben Team gepflegt werden, wie iOS- und Android-Apps, können sich ein BFF teilen.
Ersetzt ein BFF mein API-Gateway? Nein. Sie sind komplementäre Schichten. Das Gateway erzwingt eine einheitliche Richtlinie am Rand; das BFF formt Daten für einen spezifischen Client dahinter. Die meisten realen Microservices-Systeme betreiben beides.
Wann sollte ich kein BFF bauen? Verzichten Sie darauf, wenn alle Clients ähnliche Anfragen stellen, wenn nur ein Client existiert oder wenn eine GraphQL-Schicht mit pro-Frontend-Resolvern es Clients bereits ermöglicht, genau die Daten abzurufen, die sie benötigen.
Wo gehören Authentifizierung und Ratenbegrenzung hin, ins BFF oder ins Gateway? Ins Gateway. Dies sind Querschnittsaufgaben, die über alle Clients hinweg einheitlich sein sollten. Sie ins BFF zu legen, dupliziert die Logik über jedes BFF hinweg und führt zu Abweichungen in den Richtlinien.