API-Gateway vs. BFF für Web- und Mobile-Clients: Vor- und Nachteile

Das Problem: ein Backend, viele Clients, unterschiedliche Bedürfnisse

Ein häufiger Anfang ist einfach: Ein Backend bietet eine Reihe von Endpunkten an, und sowohl die Web-App als auch die Mobile-App rufen sie auf. Das wirkt effizient, weil es einen Ort gibt, um Features hinzuzufügen, Bugs zu beheben und Regeln durchzusetzen.

Dann kommt die Realität. Die Web-Oberfläche braucht oft dichte Bildschirme, Filter, Exporte und Admin-Aktionen. Mobile braucht meist weniger Felder, schnellere Bildschirme, offline-freundliche Abläufe und bewusstes Verhalten bei Akku- und Datenverbrauch. Selbst wenn die Funktion „gleich“ heißt, ist die ideale API-Struktur für jeden Client selten identisch.

Mit der Zeit driftet die API. Ein Web-Team fügt zusätzliche Felder für eine neue Tabellenansicht hinzu. Mobile bittet darum, schwere Payloads zu entfernen und mehrere Aufrufe zu einem zu kombinieren. Jemand ergänzt einen Parameter „nur für iOS“. Eine andere Person verwendet einen internen Admin-Endpunkt in der öffentlichen App, weil er „schon da war“. Was als saubere API begann, wird zur Ansammlung von Kompromissen.

Die Risiken zeigen sich schnell:

• Breaks, wenn ein Client schneller ausrollt als der andere
• Langsamere Apps durch große Payloads oder zu viele Roundtrips
• Komplizierterer Backend-Code, weil jeder Endpunkt versucht, alle Clients zu bedienen
• Accidentelle Datenfreigabe, wenn interne Felder oder Aktionen in öffentliche APIs gelangen
• Schmerzhafte Versionierung, weil „kleine Änderungen" für ältere Clients nicht klein sind

Das ist die Kernspannung hinter der Diskussion API-Gateway vs. BFF. Sie wollen stabile öffentliche APIs, auf die sich Mobile und Web verlassen können, und gleichzeitig jedem Client Raum geben, sich in seinem Tempo zu entwickeln.

API-Gateway und BFF: was sie sind (und was nicht)

Ein API-Gateway ist die Eingangstür für Ihre APIs. Clients rufen das Gateway auf, und es routet Anfragen an die passenden Backend-Services. Es übernimmt oft gemeinsame Anliegen, die Sie nicht überall wiederholen wollen, wie Authentifizierungsprüfungen, Rate-Limits, Request-Logging und grundlegendes Request-Shaping.

Ein Backend-for-Frontend (BFF) ist ein kleines Backend, das für einen spezifischen Client oder eine Client-Gruppe gebaut ist, z. B. „Web“ und „Mobile“. Der Client ruft sein BFF an, und das BFF ruft die darunterliegenden Services. Die zentrale Idee ist Fokus: Das BFF darf die „Sprache“ des Clients sprechen (Screens, Abläufe, Payloads), auch wenn die Kern-Services generischer bleiben.

Was diese Muster nicht sind: Sie sind kein Ersatz für gut gestaltete Domain-Services oder ein sauberes Datenmodell. Ihre Kern-Services, Datenbanken und Geschäftsregeln sollten weiterhin die Quelle der Wahrheit sein. Ein Gateway oder BFF darf nicht zur Ansammlung von Geschäftslogik werden, die langsam Ihr eigentliches Backend ersetzt.

Kurz unterschieden:

• Gateway: ein Einstiegspunkt, gemeinsame Anliegen, Routing und Schutz
• BFF: client-spezifische APIs, die Client-Arbeit reduzieren und interne Komplexität verbergen

Sie können sie auch kombinieren. Ein übliches Setup ist ein Gateway an der öffentlichen Peripherie und dahinter getrennte BFFs für Web und Mobile. Das Gateway kümmert sich um äußere Sicherheit und Traffic-Regeln, während jedes BFF Endpunkte und Antworten für seinen Client formt.

Wie sich der Request-Pfad ändert

Der größte Unterschied zwischen einem API-Gateway und einem BFF ist, wo Sie die „Eingangstür“-Logik platzieren: Routing, Authentifizierungsprüfungen und Response-Shaping.

Beim API-Gateway spricht der Client in der Regel zu einem gemeinsamen Einstiegspunkt. Das Gateway leitet Anfragen an interne Services weiter und übernimmt Aufgaben wie Token-Validierung, Rate-Limits und Routing nach Pfad.

Bei einem BFF ruft jede Client-Art (Web, iOS, Android) ein Backend auf, das speziell für sie gebaut ist. Dieses BFF ruft dann interne Services und liefert eine Antwort, die an die jeweiligen Screens und Einschränkungen angepasst ist.

Anschaulich:

• API-Gateway-Pfad: Client -> Gateway -> Service(s) -> Response
• BFF-Pfad: Client -> BFF (Web oder Mobile) -> Service(s) -> Response

Auch die Ownership verschiebt sich oft. Ein Plattform- oder Infrastrukturteam besitzt typischerweise das Gateway, weil es alle Teams und Services betrifft. Ein Feature-Team besitzt oft ein BFF, weil es mit dem UI und dessen Release-Zyklus mitwandert.

Bei der Authentifizierung schickt der Client ein Token, die Edge-Schicht (Gateway oder BFF) validiert es oder leitet es an einen Auth-Service weiter und übergibt dann Identitätsdetails (User-ID, Rollen) an nachgelagerte Services. Der Unterschied liegt darin, wo Sie client-spezifische Regeln anwenden. Im Gateway sind Policies meist generisch und über Clients hinweg konsistent. Im BFF können Sie client-spezifisches Shaping hinzufügen, z. B. eine kleinere Payload für Mobile zurückgeben oder mehrere Service-Aufrufe zu einer Antwort kombinieren.

Genau dieses Shaping ist die Stärke von BFFs, aber es bedeutet auch mehr Bausteine zum Deployen und Konsistent-Halten.

Öffentliche vs. interne Endpunkte sicher trennen

Ein öffentlicher Endpunkt ist jede API-Route, die Ihre Web-App, Mobile-App, Partner oder Dritte erreichen können. Behandeln Sie sie standardmäßig als feindlich, weil Sie das Netzwerk oder den aufrufenden Client nicht kontrollieren.

Ein interner Endpunkt ist für Service-zu-Service-Verkehr innerhalb Ihres Systems gedacht. Er darf schneller geändert werden, mehr Kontext voraussetzen und reichhaltigere Daten offenlegen, aber er sollte niemals direkt aus dem öffentlichen Internet erreichbar sein.

Mit einem API-Gateway ist die Trennung oft physisch und leicht zu verstehen: Nur das Gateway ist exponiert und entscheidet, welche externen Routen existieren. Alles dahinter bleibt privat. So können Sie interne Service-APIs ausdrucksstark halten, während das Gateway eine kleinere, sicherere Oberfläche durchsetzt.

Beim Backend-for-Frontend-Muster ist die Trennung eher produktspezifisch. Jeder Client (Web, iOS, Android) spricht nur mit seinem BFF, und das BFF spricht mit internen Services. Dadurch können Sie interne Komplexität verbergen: Das BFF kann drei Services aufrufen, Ergebnisse zusammenführen und eine einfache Antwort liefern, die genau dem Client-Bedarf entspricht.

Die Trennung ist nur sicher, wenn Sie praktische Kontrollen einführen:

• Spezifische Autorisierung: Rollen und Scopes pro Route, nicht nur ein „eingeloggt“-Schalter
• Rate-Limits pro Nutzer, Token und IP für öffentliche Endpunkte
• Payload-Filtering: nur zurückgeben, was der Client braucht; interne IDs, Debug-Info und Admin-Felder entfernen
• Klare Allowlists: welche Endpunkte öffentlich sind, welche intern bleiben

Beispiel: Eine Mobile-App braucht eine „Meine Bestellungen“-Ansicht. Das BFF kann /orders mit nur Status und Summen ausliefern, während der interne Order-Service detaillierte Kostenaufstellungen und Fraud-Flags privat behält.

Versionierung: was einfacher wird und was nicht

Versionierungsprobleme treten meist auf, wenn Web und Mobile in unterschiedlichen Geschwindigkeiten voranschreiten. Ein Web-Team kann binnen Stunden ausrollen und zurückrollen. Eine Mobile-App braucht oft Tage oder Wochen wegen App-Store-Review und Nutzer, die nicht sofort updaten. Genau hier wird die Entscheidung praktisch relevant.

Mit einem API-Gateway können Sie die Versionierung an einer einzigen Tür platzieren (z. B. /v1/..., /v2/...). Das ist einfach zu erklären und zu routen. Der Nachteil: Das Gateway kann zur Versionen-Sammlung werden, wenn viele Clients und Partner alte Versionen weiterverwenden. Sie müssen lange alte Datenformen unterstützen.

Mit einem BFF ist Versionierung oft „pro Client“. Das Mobile-BFF kann auf einem älteren Vertrag bleiben, während das Web-BFF schneller vorankommt, selbst wenn beide dieselben internen Services nutzen. Das reduziert den Druck, öffentliche Versionen ewig am Leben zu halten. Der Tradeoff ist mehr Komplexität: Sie haben nun mehrere Versionierungsentscheidungen zu verwalten und zu deployen.

Versionierung innerhalb von Services ist ebenfalls möglich, drückt aber client-gesteuerte Änderungen tief ins System. Das kann internen Code schwerer lesbar machen, weil Logik sich nach Client-Versionen verzweigt.

Nicht-brechende Änderungen sind Ihr bester Freund: optionale Felder hinzufügen, neue Endpunkte hinzufügen oder zusätzliche Eingabefelder akzeptieren. Brechende Änderungen sind z. B. Feldumbenennung, Typwechsel (String zu Number) oder das Entfernen eines Endpunkts.

Deprecation funktioniert am besten geplant:

• Setzen Sie ein klares Auslaufdatum und kommunizieren Sie früh
• Verfolgen Sie die Nutzung der alten Version (Logs, Metriken) und suchen Sie nach Nachzüglern
• Rollout der Client-Updates zuerst (insbesondere Mobile), dann den alten Pfad entfernen
• Geben Sie eine klare Fehlermeldung zurück, wenn eine alte Version endgültig gesperrt wird

Performance: Latenz, Payload-Größe und Anzahl der Aufrufe

Performance ist bei API-Gateway vs. BFF meist ein Kompromiss: ein zusätzlicher Hop im System gegenüber weniger Hops über das Client-Netzwerk. Die schnellste Option reduziert oft langsame, unzuverlässige Client-Netzzeit, auch wenn sie einen kleinen serverseitigen Schritt hinzufügt.

Ein BFF gewinnt häufig, wenn der Client sonst viele Aufrufe machen würde. Statt dass Web und Mobile fünf Endpunkte aufrufen und Ergebnisse auf dem Gerät zusammenfügen, kann das BFF serverseitig holen und eine Antwort zurückgeben. Das senkt oft die Gesamtlatenz auf Mobilgeräten, weil Mobilnetze bei jedem Request Verzögerung hinzufügen.

Gängige Performance-Gewinne durch Gateway oder BFF:

• Aggregation: Daten aus mehreren Services in einer Antwort kombinieren
• Intelligenteres Caching: am Edge oder im BFF für leseschwere Screens
• Kleinere Payloads: nur die Felder zurückgeben, die der Screen braucht
• Weniger Roundtrips: chatty Client-Verhalten reduzieren
• Einheitliche Komprimierung und Timeouts: Defaults an einer Stelle durchsetzen

Das Muster kann aber auch schaden. Jede zusätzliche Schicht fügt CPU-Arbeit und weitere Wartepunkte hinzu. Wenn Sie dieselbe Aggregationslogik für Web und Mobile duplizieren, verdoppeln Sie vielleicht die Arbeit und erzeugen Inkonsistenzen. Over-Fetching ist ein häufiger Zugewinn: ein generischer Endpunkt, der jede Ansicht bedienen will, liefert große Payloads, die Zeit und Bandbreite verschwenden.

Mobile-Spezifika verschärfen diese Tradeoffs. Wackelige Netze bedeuten Retries und Timeouts, und jeder zusätzliche Aufruf kostet Akku. Cold-Starts sind wichtig: Wenn die App mehrere Anfragen braucht, bevor der erste Screen nutzbar ist, merken das Nutzer.

Praktische Regel: Optimieren Sie zuerst für weniger Client-Anfragen, dann optimieren Sie den zusätzlichen Hop.

Schnelle Bewertung einer Design-Entscheidung

Wenn ein Screen mehr als 2–3 sequentielle Aufrufe braucht, überlegen Sie Aggregation. Wenn Antworten groß sind und meist ungenutzt, denken Sie an Aufspaltung von Endpunkten oder ein client-spezifisches BFF.

Betrieb: Deployment, Monitoring und Skalierung

Die große operative Frage ist, wie viele bewegliche Teile Sie betreiben und unterstützen wollen. Ein Gateway wird oft zur gemeinsamen Infrastruktur für viele Teams. BFFs sind normalerweise kleine Services, aber Sie könnten eines pro Client (Web, iOS, Android, Partner) haben, was Release- und On-Call-Aufwand erhöht.

Beim Testen und Release kann ein Gateway sicherer sein, wenn Sie hauptsächlich Routing, Auth und Rate-Limits brauchen. Änderungen sind zentralisiert, deshalb kann ein Fehler alle betreffen. BFFs reduzieren die Blast Radius, weil eine Web-Änderung nur das Web-BFF betreffen kann. Der Tradeoff: mehr Pipelines und mehr Versionen gleichzeitig.

Für Observability müssen Sie eine einzelne Nutzeranfrage über die Schichten verfolgen können, besonders wenn ein mobiler Call mehrere Backend-Aufrufe auslöst.

• Verwenden Sie eine Korrelation-ID und geben Sie sie in Gateway, BFF und Backend-Logs weiter
• Erfassen Sie Traces, um zu sehen, wo Zeit verbracht wird (Gateway, BFF, Downstream-Service)
• Nutzen Sie strukturierte Logs (Client, Endpunkt, Statuscode, Latenz, Payload-Größe)
• Tracken Sie einige Schlüsselmetriken pro Endpunkt: Fehlerquote, p95-Latenz, Durchsatz

Skalierung sieht anders aus. Ein Gateway ist ein gemeinsamer Engpass: Es muss Spitzen und Hot-Endpunkte handhaben, ohne zum Flaschenhals zu werden. BFFs erlauben Skalierung pro Client, was hilft, wenn Web-Traffic während der Geschäftszeiten springt, während Mobile stabil bleibt.

In Incidents können Fehler sich je nach Pattern anders äußern. Beim Gateway zeigen sich Probleme oft als weitreichende 5xx- oder Auth-Fehler. Bei BFFs können Probleme auf eine Client-Funktion isoliert sein. Machen Sie Runbooks klar, wo zuerst zu schauen ist, und halten Sie Fallback-Verhalten einfach (z. B. reduzierte Antwort statt Timeout).

Wie entscheiden: ein einfacher Schritt-für-Schritt-Prozess

Die Wahl zwischen API-Gateway und BFF ist weniger Theorie als Praxis: Was brauchen Ihre Clients täglich?

Ein praktischer Entscheidungsfluss

1. Starten Sie bei Ihren Clients, nicht bei Ihren Servern. Schreiben Sie alle Clients auf (Web-App, iOS, Android, Partner-API, internes Admin) und listen Sie, was jeder wichtige Screen braucht. Wenn dieselbe „Kundendetails“-Ansicht unterschiedliche Felder und Call-Muster hat, ist das ein starkes Signal für client-spezifisches Shaping.

2. Kartieren Sie den Ist-Zustand. Markieren Sie Ihre aktuellen Endpunkte: Was ist geteilt (Kern-Domain-Operationen wie Bestellungen, Zahlungen, Nutzer) und was ist presentation-shaped (Dashboard-Summary, kombinierte „Home“-Payload). Geteilte Teile gehören ins Kern-Backend. Presentation-Shaped-Teile passen oft besser ins BFF.

3. Entscheiden Sie, wo Shaping und Regeln leben. Wenn Sie hauptsächlich Routing, Auth, Rate-Limits, Caching und sichere Exposition brauchen, ist ein Gateway der natürliche Ort. Wenn Sie echte Komposition brauchen (mehrere Services aufrufen, sechs Calls zu einem machen, unterschiedliche Payloads pro App), legen Sie diese Logik in BFF-Code, damit sie testbar und lesbar bleibt.

4. Wählen Sie eine Versionierungs- und Deprecation-Regel, die Sie einhalten können. Zum Beispiel: „Keine breaking changes ohne neue Version; jedes deprecated Feld bleibt 90 Tage.“ Mit Gateway-only versionieren Sie oft die öffentliche Oberfläche. Mit BFFs können Sie die Kern-APIs stabil halten und nur BFF-Endpunkte pro Client versionieren.

5. Planen Sie Rollout und messen Sie. Erfassen Sie vor Änderungen Basismetriken: p95-Latenz, Anzahl Calls pro Screen, Payload-Größen und Fehlerquoten. Rollen Sie zuerst für einen kleinen Prozentsatz aus, vergleichen Sie vorher/nachher und erweitern Sie dann.

Ein Beispiel: Wenn Ihre Mobile-App monatlich releast, Ihr Web-Portal aber täglich, kann ein kleines Mobile-BFF die App vor häufigen Backend-Änderungen schützen, während das Web-Client schnell weiterarbeitet.

Beispiel: Web-Portal + Mobile-App mit unterschiedlichen Release-Geschwindigkeiten

Stellen Sie sich eine Firma vor mit einem Kundenportal im Web und einer Field-App auf Mobile. Beide benötigen dieselben Kerndaten: Kunden, Jobs, Rechnungen und Nachrichten. Das Portal ändert sich wöchentlich. Die Mobile-App aktualisiert langsamer wegen App-Store-Review und muss mit schlechtem Empfang arbeiten.

Das Problem zeigt sich schnell. Mobile-Nutzer wollen kompakte Antworten, weniger Calls und Sync-Flows für Offline (z. B. heutige Jobs einmal herunterladen, später Änderungen synchronisieren). Das Web-Portal macht mehr Calls und lädt reichhaltigere Screens, weil es immer online ist und leichter zu aktualisieren.

Option A: API-Gateway vor stabilen Services

Die Gateway-first-Entscheidung lässt Ihre Backend-Services weitgehend unverändert. Das Gateway übernimmt Auth, Routing und kleine Anpassungen wie Header, Rate-Limits und einfaches Feldmapping.

Versionierung bleibt meist auf Service-Ebene — weniger bewegliche Teile. Das kann vorteilhaft sein, zwingt aber mobile-spezifische Änderungen oft zu großen Versionen wie /v2, weil die zugrunde liegenden Endpunkte geteilt sind.

Die Endpunkt-Exposition ist klarer, wenn Sie das Gateway als einzigen öffentlichen Zugang behandeln. Interne Endpunkte bleiben dahinter, aber Sie müssen strikt definieren, was das Gateway erreichen darf und was es veröffentlicht.

Option B: Ein Mobile-BFF, das „mobile spricht"

Mit einem Mobile-BFF spricht die Mobile-App Endpunkte, die für Mobile-Screens und Sync-Flows gestaltet sind. Das BFF kann Daten aggregieren (Job-Details + Kunde + letzte Nachricht), Felder kürzen und eine einzige Payload zurückgeben, die zur App passt.

Was sich ändert:

• Versionierung wird pro Client einfacher: das Mobile-BFF kann versioniert werden, ohne das Web-Portal mitzuziehen
• Performance verbessert sich oft für Mobile: weniger Roundtrips und kleinere Antworten
• Die Trennung öffentlich vs intern wird klarer: das BFF ist öffentlich, ruft aber interne Services, die nie exponiert werden müssen

Häufige Fehler und Fallen

Die größte Falle ist, das Gateway zum Mini-Backend zu machen. Gateways sind ideal für Routing, Auth, Rate-Limits und einfaches Shaping. Packen Sie Geschäftsregeln hinein, und Sie bekommen versteckte Logik, die schwer zu testen und leicht bei einer Config-Änderung zu brechen ist.

BFFs können in die andere Richtung schiefgehen: Teams bauen ein BFF pro Screen oder Feature, und der Wartungsaufwand explodiert. Ein BFF sollte normalerweise zu einem Client-Typ (Web, iOS, Android) oder einem klaren Produktbereich passen, nicht zu jeder UI-Ansicht. Sonst duplizieren Sie Regeln in vielen Orten und Versionierung wird zur Vollzeitaufgabe.

Versionierungsfehler entstehen oft durch Extreme. Wenn Sie am ersten Tag alles versionieren, frieren Sie Ihre API ein und halten alte Varianten ewig. Wenn Sie nie versionieren, liefern Sie irgendwann unbeabsichtigt breaking changes aus. Eine einfache Regel: versionieren Sie nicht für kleine additive Änderungen; versionieren Sie, wenn Sie etwas entfernen oder die Bedeutung ändern.

Die Exposition interner Endpunkte schadet Teams oft: Interne Services direkt dem Internet auszuliefern (auch „vorübergehend") macht jede interne Änderung potenziell zu einem Ausfall- oder Sicherheitsrisiko. Halten Sie eine klare Grenze: Nur Gateway oder BFF sind öffentlich, interne Services bleiben privat.

Performance-Probleme sind meist selbstverschuldet: zu große Payloads, zu viele Roundtrips und kein Latenz-Budget. Beispiel: Eine Mobile-App braucht nur Bestellstatus und Summen, bekommt aber das komplette Order-Objekt mit Line-Items und Audit-Feldern — auf Mobilfunk wird das langsam.

Warnzeichen:

• Gateway-Konfigurationen referenzieren Geschäftsbegriffe wie „Refund Eligibility" oder „VIP Rules"
• BFFs vermehren sich schneller als die Clients, die sie bedienen
• Sie können Ihre API-Versionierungsstrategie nicht in einem Satz erklären
• Interne Service-Endpunkte sind aus dem öffentlichen Internet erreichbar
• Antworten wachsen stetig, weil „es später nützlich sein könnte"

Kurze Checkliste und nächste Schritte

Wenn Sie bei der Entscheidung stecken, fokussieren Sie sich darauf, was in der Praxis zuerst bricht: Releases, Payloads und Sicherheitsgrenzen.

Kurze Checkliste

Wenn Sie mehrere dieser Fragen mit „nein" beantworten, wird Ihr aktuelles Setup wahrscheinlich problematisch, wenn Ihre Clients wachsen:

• Können Sie einen Backend-Service ändern, ohne alle Clients in derselben Woche zu zwingen, zu aktualisieren?
• Gibt es eine klare Grenze zwischen öffentlichen Endpunkten (sicher fürs Internet) und internen (nur vertrauenswürdige Systeme)?
• Bekommen Web und Mobile nur das, was sie brauchen (nicht eine riesige „Küchen-Spüle"-Antwort)?
• Können Sie Änderungen schrittweise ausrollen (kleiner Prozentsatz zuerst) und schnell Fehler, Latenz und ungewöhnlichen Traffic sehen?
• Wissen Sie, wer den Vertrag für jeden Endpunkt besitzt und wer breaking changes genehmigt?

Nächste Schritte

Machen Sie aus den Antworten einen Plan. Das Ziel ist keine perfekte Architektur, sondern weniger Überraschungen beim Ausliefern.

Formulieren Sie Ihre API-Verträge in einfacher Sprache (Inputs, Outputs, Fehlercodes, was sich ändern darf). Wählen Sie ein Ownership-Modell: Wer kümmert sich um Client-Bedürfnisse (Web/Mobile) und wer um Kern-Domain-Services. Entscheiden Sie, wo die Versionierung lebt (pro Client oder zentral) und setzen Sie eine Deprecation-Regel, an die Sie sich halten.

Fügen Sie Basis-Monitoring hinzu, bevor Sie große Refactors starten: Request-Rate, p95-Latenz, Fehlerquote und Top-Endpunkte nach Payload-Größe. Prototypen Sie die riskantesten Client-Flows zuerst.

Wenn Sie mit AppMaster (appmaster.io) bauen, ist ein praktischer Ansatz, die Kern-Geschäftslogik und Datenmodelle im generierten Backend zu halten und eine dünne Gateway- oder BFF-Schicht nur dort hinzuzufügen, wo ein Client wirklich anderes Shaping oder Release-Isolation braucht.

Wenn die Checkliste schwer zu beantworten ist, sehen Sie das als Signal: Vereinfachen Sie den Vertrag und ziehen Sie die Grenze zwischen öffentlich und intern schärfer, bevor Sie weitere Endpunkte hinzufügen.