Back-Ends für Frontends-Muster

Dieses Muster beschreibt, wie Back-End-Dienste von Frontend-Implementierungen entkoppelt werden, um Oberflächen für verschiedene Clientschnittstellen anzupassen. Dieses Muster ist nützlich, wenn Sie vermeiden möchten, ein Back-End anzupassen, das mehrere Schnittstellen bedient. Dieses Muster basiert auf den Back-Ends für Frontends-Muster von Sam Newman.

Kontext und Problem

Betrachten Sie eine Anwendung, die ursprünglich mit einer Desktopweb-UI und einem entsprechenden Back-End-Dienst entworfen wurde. Wenn sich die Geschäftsanforderungen im Laufe der Zeit ändern, wird eine mobile Schnittstelle hinzugefügt. Beide Schnittstellen interagieren mit demselben Back-End-Dienst. Die Funktionen eines mobilen Geräts unterscheiden sich jedoch erheblich von einem Desktopbrowser hinsichtlich Bildschirmgröße, Leistung und Anzeigeeinschränkungen.

Das Diagramm enthält zwei Abschnitte: den Back-End-Dienst und den Desktopclient und den mobilen Client. Zwei doppelseitige Pfeile zeigen vom Back-End-Dienst auf den Desktopclient und den mobilen Client.

Ein Back-End-Dienst trifft häufig auf konkurrierende Anforderungen von mehreren Frontend-Systemen. Diese Anforderungen führen zu häufigen Updates und potenziellen Entwicklungsengpässen. Widersprüchliche Updates und die Notwendigkeit der Kompatibilität führen zu übermäßigem Bedarf an einer einzelnen bereitstellungsfähigen Ressource.

Wenn ein separates Team den Backend-Dienst verwaltet, kann es zu einer Trennung zwischen Frontend- und Backend-Teams kommen. Diese Trennung kann zu Verzögerungen bei der Gewinnung von Konsens- und Ausgleichsanforderungen führen. Beispielsweise müssen änderungen, die von einem Frontend-Team angefordert werden, vor der Integration mit anderen Frontend-Teams überprüft werden.

Lösung

Führen Sie eine neue Ebene ein, die nur die Anforderungen behandelt, die für die Schnittstelle spezifisch sind. Diese Ebene, die als Back-End-for-Frontend-Dienst (BFF) bezeichnet wird, befindet sich zwischen dem Frontend-Client und dem Back-End-Dienst. Wenn die Anwendung mehrere Schnittstellen unterstützt, z. B. eine Webschnittstelle und eine mobile App, erstellen Sie einen BFF-Dienst für jede Schnittstelle.

Dieses Muster passt die Clientumgebung für eine bestimmte Schnittstelle an, ohne dass sich dies auf andere Schnittstellen auswirkt. Außerdem optimiert sie die Leistung, um die Anforderungen der Frontend-Umgebung zu erfüllen. Da jeder BFF-Dienst kleiner und weniger komplex ist als ein gemeinsamer Back-End-Dienst, kann die Anwendung einfacher verwaltet werden.

Frontend-Teams verwalten unabhängig ihren eigenen BFF-Dienst, der ihnen die Kontrolle über die Sprachauswahl, freigabeintervalle, Workloadpriorisierung und Featureintegration ermöglicht. Diese Eigenständigkeit ermöglicht es ihnen, effizient zu arbeiten, ohne von einem zentralen Backend-Entwicklungsteam abhängig zu sein.

Viele BFF-Dienste basieren traditionell auf REST-APIs, aber GraphQL-Implementierungen werden als Alternative entwickelt. Mit GraphQL beseitigt der Abfragemechanismus die Notwendigkeit einer separaten BFF-Ebene, da Clients die benötigten Daten anfordern können, ohne sich auf vordefinierte Endpunkte zu verlassen.

Das Diagramm zeigt drei Abschnitte. Der erste Abschnitt besteht aus dem Desktopclient und dem mobilen Client. Der zweite Abschnitt besteht aus dem BFF-Dienst des Desktopclients und dem mobilen Client-BFF-Dienst. Der Desktopclient weist einen einfarbigen Pfeil auf, der auf den BFF-Dienst des Desktopclients verweist. Der mobile Client weist einen soliden Pfeil auf, der auf den BFF-Dienst des mobilen Clients verweist. Jeder BFF-Dienst weist einen gepunkteten Pfeil auf, der auf den Back-End-Dienstabschnitt verweist.

Weitere Informationen finden Sie unter Back-Ends für Frontends-Muster von Sam Newman.

Probleme und Überlegungen

• Bewerten Sie Ihre optimale Anzahl von Diensten abhängig von den zugehörigen Kosten. Die Wartung und Bereitstellung weiterer Dienste bedeutet einen erhöhten Betriebsaufwand. Jeder einzelne Dienst verfügt über einen eigenen Lebenszyklus, Bereitstellungs- und Wartungsanforderungen und Sicherheitsanforderungen.

• Überprüfen Sie die Ziele auf Dienstebene, wenn Sie einen neuen Dienst hinzufügen. Es kann zu einer erhöhten Latenz kommen, da Clients Ihre Dienste nicht direkt kontaktieren, und der neue Dienst zu einer zusätzlichen Netzwerkweiterleitung führt.

• Wenn unterschiedliche Schnittstellen dieselben Anforderungen stellen, bewerten Sie, ob die Anforderungen in einen einzigen BFF-Dienst konsolidiert werden können. Die Gemeinsame Nutzung eines einzelnen BFF-Diensts zwischen mehreren Schnittstellen kann zu unterschiedlichen Anforderungen für jeden Client führen, was das Wachstum und die Unterstützung des BFF-Diensts erschweren kann.

  Die Codeduplizierung ist ein wahrscheinliches Ergebnis dieses Musters. Bewerten Sie den Kompromiss zwischen Codeduplizierung und einer besser angepassten Erfahrung für jeden Client.

• Der BFF-Dienst sollte nur clientspezifische Logik im Zusammenhang mit einer bestimmten Benutzeroberfläche verarbeiten. Querschnittsfeatures wie Überwachung und Autorisierung sollten abstrahiert werden, um die Effizienz aufrechtzuerhalten. Typische Funktionen, die im BFF-Dienst auftreten können, werden separat mit den Mustern Gatekeeping, Rate Limiting und Routing behandelt.

• Überlegen Sie, wie sich das Erlernen und Implementieren dieses Musters auf das Entwicklungsteam auswirkt. Die Entwicklung neuer Back-End-Systeme erfordert Zeit und Aufwand, was zu technischen Schulden führen kann. Die Aufrechterhaltung des vorhandenen Back-End-Diensts führt zu dieser Herausforderung.

• Bewerten Sie, ob Sie dieses Muster benötigen. Wenn Ihre Organisation beispielsweise GraphQL mit frontendspezifischen Resolvern verwendet, können BFF-Dienste Ihren Anwendungen möglicherweise keinen Mehrwert hinzufügen.

  Ein weiteres Szenario ist eine Anwendung, die ein API-Gateway mit Microservices kombiniert. Dieser Ansatz kann für einige Szenarien ausreichen, in denen BFF-Dienste in der Regel empfohlen werden.

Wann dieses Muster verwendet werden soll

Verwenden Sie dieses Muster in folgenden Fällen:

• Ein gemeinsam genutzter oder allgemeiner Back-End-Dienst erfordert einen erheblichen Entwicklungsaufwand für die Wartung.

• Sie möchten das Back-End für die Anforderungen bestimmter Clientschnittstellen optimieren.

• Sie nehmen Anpassungen an einem allgemeinen Back-End vor, um mehrere Schnittstellen zu berücksichtigen.

• Eine Programmiersprache eignet sich besser für das Back-End einer bestimmten Benutzeroberfläche, aber nicht für alle Benutzeroberflächen.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Schnittstellen stellen die gleichen oder ähnliche Anforderungen an das Back-End vor.

• Nur eine Schnittstelle interagiert mit dem Back-End.

Workloadentwurf

Bewerten Sie, wie Sie das Back-End-Muster für Frontends im Entwurf einer Workload verwenden, um die in den Azure Well-Architected Framework-Säulen behandelten Ziele und Prinzipien zu erfüllen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Säule	So unterstützt dieses Muster die Säulenziele
Zuverlässigkeitsentwurfsentscheidungen helfen Ihrer Arbeitsauslastung, ausfallsicher zu werden und sicherzustellen, dass sie nach auftreten eines Fehlers wieder in einen voll funktionsfähigen Zustand versetzt wird.	Wenn Sie Dienste auf eine bestimmte Frontend-Schnittstelle isolieren, enthalten Sie Fehlfunktionen. Die Verfügbarkeit eines Clients wirkt sich nicht auf die Verfügbarkeit des Zugriffs eines anderen Clients aus. Wenn Sie verschiedene Clients unterschiedlich behandeln, können Sie Zuverlässigkeitsbemühungen basierend auf erwarteten Clientzugriffsmustern priorisieren. - RE:02 Kritische Flows - RE:07 Selbsterhaltung
Sicherheitsdesignentscheidungen tragen dazu bei, die Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Systeme Ihrer Workload sicherzustellen.	Die in diesem Muster eingeführte Diensttrennung ermöglicht die Anpassung der Sicherheit und Autorisierung auf der Dienstebene für die spezifischen Anforderungen jedes Clients. Dieser Ansatz kann die Schnittstellenfläche der API reduzieren und die seitliche Bewegung zwischen Backend-Systemen einschränken, die unterschiedliche Funktionen bereitstellen können. - SE:04 Segmentierung - SE:08 Härtungsressourcen
Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen .	Die Back-End-Trennung ermöglicht es Ihnen, auf Arten zu optimieren, die möglicherweise nicht mit einer Ebene gemeinsam genutzter Dienste möglich sind. Wenn Sie einzelne Clients unterschiedlich behandeln, können Sie die Leistung für die Einschränkungen und Funktionen eines bestimmten Clients optimieren. - PE:02 Kapazitätsplanung - PE:09 Kritische Flows

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Beispiel

In diesem Beispiel wird ein Anwendungsfall für das Muster veranschaulicht, in dem zwei unterschiedliche Clientanwendungen, eine mobile App und eine Desktopanwendung, mit Azure API Management (Datenebenengateway) interagieren. Dieses Gateway dient als Abstraktionsebene und verwaltet häufige querschneidende Bedenken wie:

• Autorisierung Stellt sicher, dass nur überprüfte Identitäten mit den richtigen Zugriffstoken geschützte Ressourcen mithilfe der API-Verwaltung mit Microsoft Entra ID aufrufen können.

• Überwachung. Erfasst und sendet Anforderungs- und Antwortdetails zu Observability-Zwecken an Azure Monitor.

• Zwischenspeicherung anfordern. Optimiert wiederholte Anforderungen durch die Bereitstellung von Antworten aus dem Cache durch integrierte Features der API-Verwaltung.

• Routing und Aggregation. Leitet eingehende Anforderungen an die entsprechenden BFF-Dienste weiter.

Jeder Client verfügt über einen dedizierten BFF-Dienst, der als Azure-Funktion ausgeführt wird, die als Vermittler zwischen dem Gateway und den zugrunde liegenden Microservices dient. Diese clientspezifischen BFF-Dienste sorgen für eine maßgeschneiderte Benutzeroberfläche für Paginierung und andere Funktionen. Die mobile App priorisiert die Bandbreiteneffizienz und nutzt die Zwischenspeicherung, um die Leistung zu verbessern. Im Gegensatz dazu ruft die Desktopanwendung mehrere Seiten in einer einzigen Anforderung ab, wodurch eine immersivere Benutzererfahrung entsteht.

Das Diagramm ist in vier Abschnitte strukturiert, die den Fluss von Anforderungen, Authentifizierung, Überwachung und clientspezifischer Verarbeitung veranschaulichen. Zwei Clientgeräte initiieren Anforderungen: eine mobile Anwendung, die für eine bandbreiteneffiziente Benutzeroberfläche optimiert ist, und einen Webbrowser, der eine voll funktionsfähige Schnittstelle bereitstellt. Pfeile reichen von beiden Geräten bis zum zentralen Einstiegspunkt, der das API-Verwaltungsgateway ist, um anzugeben, dass alle Anforderungen diese Ebene durchlaufen müssen. Im zweiten Abschnitt, eingeschlossen in ein gestricheltes Linienrechteck, wird die Architektur in zwei horizontale Gruppen unterteilt. Die linke Gruppe stellt die API-Verwaltung dar, die eingehende Anforderungen verarbeitet und bestimmt, wie sie verarbeitet werden. Zwei Pfeile erstrecken sich von diesem Datenverkehrs-Gateway nach außen. Ein Pfeil zeigt aufwärts auf die Microsoft Entra-ID, die die Autorisierung verwaltet. Ein weiterer Pfeil zeigt nach unten auf Azure Monitor, der für die Protokollierung und Observierbarkeit verantwortlich ist. Ein Pfeil läuft vom Gateway zum mobilen Client zurück, der eine zwischengespeicherte Antwort darstellt, wenn eine identische Anforderung wiederholt wird, wodurch unnötige Verarbeitungen reduziert werden. Die richtige Gruppe innerhalb des gestrichelten Rechtecks konzentriert sich auf das Anpassen von Back-End-Antworten basierend auf dem Typ des Clients, der die Anforderung vorgibt. Es verfügt über zwei separate Back-End-für-Frontend-Clients, die beide mithilfe von Azure Functions für serverloses Computing gehostet werden. Einer ist dem mobilen Client und dem anderen dem Desktopclient gewidmet. Zwei Pfeile reichen vom Gateway bis zu diesen Back-End-for-Frontend-Clients, was veranschaulicht, dass jede eingehende Anforderung je nach Clienttyp an den entsprechenden Dienst weitergeleitet wird. Über diese Ebene hinaus verbinden gestrichelte Pfeile die Backend-for-Frontend-Clients mit verschiedenen Microservices, die die eigentliche Geschäftslogik abwickeln. Die Abbildung zeigt einen Fluss von links nach rechts, bei dem Clientanforderungen von mobilen und Webclients zum Gateway wechseln. Dieses Gateway verarbeitet jede Anforderung, während die Authentifizierung nach oben an den Identitätsanbieter delegiert und sich nach unten an den Überwachungsdienst anmeldet. Von dort aus leitet sie Anforderungen an den entsprechenden Back-End-for-Frontend-Client weiter, je nachdem, ob die Anforderung von einem Mobilen oder Desktopclient stammt. Schließlich leitet jeder Back-end-for-Frontend-Client die Anforderung an spezialisierte Microservices weiter, die die erforderliche Geschäftslogik ausführt und die erforderliche Antwort zurückgibt. Wenn eine zwischengespeicherte Antwort verfügbar ist, fängt das Gateway die Anforderung ab und sendet die gespeicherte Antwort direkt an den mobilen Client, wodurch eine redundante Verarbeitung verhindert wird.

Ablauf A für die erste Seitenanforderung vom mobilen Client

1. Der mobile Client sendet eine GET-Anfrage für Seite 1, einschließlich eines OAuth 2.0-Tokens im Autorisierungsheader.

2. Die Anforderung erreicht das API-Management-Gateway, das sie abfängt und:

   1. Überprüft den Autorisierungsstatus. Die API-Verwaltung implementiert die Verteidigung im Detail, sodass sie die Gültigkeit des Zugriffstokens überprüft.

   2. Streamt die Anfrageaktivität als Protokolle an Azure Monitor. Details der Anforderung werden zur Prüfung und Überwachung aufgezeichnet.

3. Die Richtlinien werden durchgesetzt, dann leitet API Management die Anforderung an den mobilen BFF-Dienst der Azure-Funktion weiter.

4. Der mobile BFF-Dienst der Azure-Funktion interagiert dann mit den erforderlichen Microservices, um eine einzelne Seite abzurufen und die angeforderten Daten zu verarbeiten, um eine einfache Erfahrung zu bieten.

5. Die Antwort wird an den Client zurückgegeben.

Flow B für die zwischengespeicherte Anforderung der ersten Seite vom mobilen Client

1. Der mobile Client sendet die gleiche GET Anforderung für die Seite 1 erneut, einschließlich des OAuth 2.0-Tokens im Autorisierungsheader.

2. Das API-Verwaltungsgateway erkennt, dass diese Anforderung bereits zuvor gestellt wurde.

   1. Die Richtlinien werden durchgesetzt. Anschließend identifiziert das Gateway eine zwischengespeicherte Antwort, die den Anforderungsparametern entspricht.

   2. Gibt die zwischengespeicherte Antwort sofort zurück. Diese schnelle Antwort eliminiert die Notwendigkeit, die Anfrage an den Azure function mobilen BFF-Dienst weiterzuleiten.

Ablauf C für die erste Anforderung vom Desktop-Client

1. Der Desktopclient sendet eine GET Anforderung zum ersten Mal, einschließlich des OAuth 2.0-Tokens im Autorisierungsheader.

2. Die Anforderung erreicht das API-Verwaltungsgateway, bei dem übergreifende Bedenken behandelt werden.

   1. Ermächtigung: Die Tokenüberprüfung ist immer erforderlich.

   2. Streamen Sie die Anforderungsaktivität: Anforderungsdetails werden aufgezeichnet, um die Beobachtbarkeit zu gewährleisten.

3. Nachdem alle Richtlinien umgesetzt wurden, leitet die API-Verwaltung die Anforderung an den Azure Function Desktop BFF-Dienst weiter, der datenintensive Anwendungsprozesse bearbeitet. Der Desktop-BFF-Dienst aggregiert mehrere Anforderungen mithilfe zugrunde liegender Microservices-Aufrufe, bevor er mit einer Mehrseitenantwort auf den Client reagiert.

Entwurf

• Microsoft Entra ID dient als cloudbasierter Identitätsanbieter. Sie bietet maßgeschneiderte Zielgruppenansprüche sowohl für mobile als auch für Desktopclients. Diese Ansprüche werden dann für die Autorisierung verwendet.

• DIE API-Verwaltung dient als Proxy zwischen den Clients und ihren BFF-Diensten, die einen Umkreis einrichten. Die API-Verwaltung ist mit Richtlinien konfiguriert, um die JSON-Webtoken zu überprüfen und Anforderungen zurückzuweisen, die kein Token besitzen oder ungültige Ansprüche für den zielbasierten BFF-Dienst enthalten. Außerdem werden alle Aktivitätsprotokolle an Azure Monitor gestreamt.

• Azure Monitor fungiert als zentrale Überwachungslösung. Es aggregiert alle Aktivitätsprotokolle, um eine umfassende End-to-End-Observierbarkeit sicherzustellen.

• Azure Functions ist eine serverlose Lösung, die BFF-Dienstlogik effizient über mehrere Endpunkte hinweg verfügbar macht, was die Entwicklung vereinfacht. Azure Functions minimiert außerdem den Infrastrukturaufwand und trägt dazu bei, die Betriebskosten zu senken.

Nächste Schritte

• Backends für Frontends Architekturmuster von Sam Newman
• Authentifizierung und Autorisierung für APIs in API Management
• So integrieren Sie die API-Verwaltung in Application Insights

Verwandte Ressourcen

• Muster „Gatewayaggregation“
• Muster „Gatewayabladung“
• Muster „Gatewayrouting“
• Serverless-Webanwendungsreferenzarchitektur