Back-Ends für Frontends-Muster

Decouple Back-End-Dienste von den Frontend-Implementierungen, 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 Pattern: Back-Ends for Frontends beschrieben 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. Da sich die Geschäftlichen Anforderungen im Laufe der Zeit geändert haben, wurde eine mobile Schnittstelle hinzugefügt. Beide Schnittstellen interagieren mit demselben Back-End-Dienst, aber die Funktionen eines mobilen Geräts unterscheiden sich erheblich von einem Desktopbrowser in Bezug auf Bildschirmgröße, Leistung und Anzeigeeinschränkungen.

Der Back-End-Dienst steht häufig vor konkurrierenden Anforderungen verschiedener Frontends, was zu häufigen Änderungen und potenziellen Engpässen im Entwicklungsprozess führt. Widersprüchliche Updates und die Notwendigkeit der Kompatibilität führen zu übermäßiger Arbeit an einer einzelnen bereitstellungsfähigen Ressource.

Wenn ein separates Team den Back-End-Dienst verwaltet, kann eine Verbindung zwischen Frontend- und Back-End-Teams erstellt werden, was zu Verzögerungen bei der Gewinnung von Konsens- und Ausgleichsanforderungen führt. 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 schnittstellenspezifischen Anforderungen behandelt. 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, erstellen Sie einen BFF-Dienst für jede Schnittstelle. Wenn Sie beispielsweise über eine Webschnittstelle und eine mobile App verfügen, erstellen Sie jeweils separate BFF-Dienste.For example, if you have a web interface and a mobile app, you would create separate BFF services for each.

Dieses Muster passt die Clientumgebung auf eine bestimmte Schnittstelle an, ohne dass sich dies auf andere Schnittstellen auswirkt. Außerdem wird die Leistung optimal auf die Anforderungen der Front-End-Umgebung abgestimmt. Da jeder BFF-Dienst kleiner und weniger komplex ist, kann die Anwendung zu Optimierungsvorteilen in einem bestimmten Grad führen.

Front-End-Teams haben Autonomie gegenüber ihrem eigenen BFF-Dienst, sodass Flexibilität bei der Sprachauswahl, Der Veröffentlichungsrhythmen, der Workloadpriorisierung und der Featureintegration ermöglicht wird, ohne sich auf ein zentrales Back-End-Entwicklungsteam zu verlassen.

Während viele BFFs auf REST-APIs angewiesen sind, werden GraphQL-Implementierungen zu einer Alternative, wodurch die Notwendigkeit der BFF-Ebene entfernt wird, da der Abfragemechanismus keinen separaten Endpunkt erfordert.

Weitere Informationen finden Sie unter Pattern: Back-Ends for Frontends.

Probleme und Überlegungen

• Bewerten Sie, was die optimale Anzahl von Diensten für Sie ist, da dies kostenaufwendte. 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 beim Hinzufügen eines neuen Diensts die Ziele auf Dienstebene (Service Level Objectives, SLOs). Es kann zu einer erhöhten Latenz kommen, da Clients ihre Dienste nicht direkt kontaktieren, und der neue Dienst führt einen zusätzlichen Netzwerkhüpfpunkt ein.

• 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 BFF Service Light zu halten. Typische Features, die im BFF-Dienst möglicherweise separat mit Gatekeeping, Rate Limiting, Routingund anderen behandelt werden.

• Berücksichtigen Sie beim Erlernen und Implementieren dieses Musters die Auswirkungen auf das Entwicklungsteam. Das Erstellen neuer Back-Ends erfordert Zeit und Aufwand, was möglicherweise technische Schulden verursacht, während der bestehende Back-End-Dienst beibehalten wird.

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

  Ein weiteres Beispiel ist die Anwendung, die API-Gateway- mit Microservices kombiniert. Dieser Ansatz kann für einige Fälle ausreichen, in denen BFFs zuvor empfohlen wurden.

Wann dieses Muster verwendet werden soll

Verwenden Sie dieses Muster in folgenden Fällen:

• Ein gemeinsam genutzter oder allgemeiner Back-End-Dienst muss mit erheblichem Entwicklungsaufwand verwaltet werden.

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

• Anpassungen werden an einem allgemeinen Back-End vorgenommen, 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 in folgenden Fällen unter Umständen nicht geeignet:

• Wenn Schnittstellen dieselben oder ähnliche Anforderungen an das Back-End stellen.

• Wenn nur eine Schnittstelle für die Interaktion mit dem Back-End verwendet wird.

Workloadentwurf

Ein Architekt sollte bewerten, wie das Back-Ends für Frontends-Muster im Design ihrer Workload verwendet werden kann, um die Ziele und Prinzipien zu erfüllen, die in den Azure Well-Architected Framework-Säulenbehandelt werden. Beispiel:

Berücksichtigen Sie wie bei jeder Designentscheidung alle Kompromisse im Hinblick auf die Ziele der anderen Säulen, die mit diesem Muster eingeführt werden könnten.

Beispiel

Dieses Beispiel zeigt einen Anwendungsfall für das Muster, in dem Sie über zwei unterschiedliche Clientanwendungen verfügen: eine mobile App und eine Desktopanwendung. Beide Clients interagieren mit einem Azure-API-Management (Datenebenengateway), das als Abstraktionsebene fungiert und häufig auftretende Probleme wie:

• Autorisierungs- – Sicherstellen, dass nur überprüfte Identitäten mit den richtigen Zugriffstoken geschützte Ressourcen mithilfe der Azure API Management (APIM) mit Microsoft Entra ID aufrufen können.

• Monitoring – Erfassen und Senden von Anforderungs- und Antwortdetails für Observability-Zwecke an Azure Monitor.

• Anforderungszwischenspeicherung – Optimieren wiederholter Anforderungen durch Die Bereitstellung von Antworten aus dem Cache mithilfe integrierter APIM-Features.

• Routing & Aggregation – Weiterleiten eingehender Anforderungen an das entsprechende Back-End für BFF-Dienste (Frontend).

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 sorgen für eine maßgeschneiderte Benutzeroberfläche für die Paginierung unter anderen Funktionen. Während die mobile App mehr bandbreitenbewusste Apps ist und die Leistung verbessert, aggregiert der Desktop mehrere Seiten in einer einzigen Anforderung, um eine umfassendere Benutzererfahrung zu erzielen.

Ablauf A: Mobiler Client – Anforderung der ersten Seite

1. Der mobile Client sendet eine GET Anforderung für die Seite 1 einschließlich des OAuth 2.0-Tokens im Autorisierungsheader.
2. Die Anforderung erreicht das Azure APIM-Gateway, das es abfangen und:
   1. Überprüft den Autorisierungsstatus – APIM implementiert die Verteidigung im Detail, sodass sie die Gültigkeit des Zugriffstokens überprüft.
   2. Streamen Sie die Anforderungsaktivität als Protokolle an Azure Monitor – Details der Anforderung werden zur Überwachung und Überwachung aufgezeichnet.
3. Die Richtlinien werden erzwungen, dann leitet Azure APIM die Anforderung an azure Function Mobile BFF weiter.
4. Der Azure Function Mobile BFF 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.

Ablauf B: Mobiler Client – Zwischengespeicherte Anforderung der ersten Seite

1. Der mobile Client sendet dieselbe GET Anforderung für die Seite 1 erneut, einschließlich des OAuth 2.0-Tokens im Autorisierungsheader.
2. Das Azure APIM-Gateway erkennt, dass diese Anforderung vor und:
   1. Die Richtlinien werden erzwungen, und danach wird eine zwischengespeicherte Antwort identifiziert, die den Anforderungsparametern entspricht.
   2. Gibt die zwischengespeicherte Antwort sofort zurück, ohne dass die Anforderung an azure Function Mobile BFF weitergeleitet werden muss.

Flow C: Desktopclient – erste Anforderung

1. Der Desktopclient sendet eine GET Anforderung zum ersten Mal, einschließlich des OAuth 2.0-Tokens im Autorisierungsheader.
2. Die Anforderung erreicht das Azure APIM-Gateway, bei dem ähnliche grenzüberschreitende Bedenken behandelt werden:
   1. Autorisierung – Tokenüberprüfung ist immer erforderlich.
   2. Streamen Sie die Anforderungsaktivität – Anforderungsdetails werden zur Observability aufgezeichnet.
3. Nachdem alle Richtlinien erzwungen wurden, leitet Azure APIM die Anforderung an den Azure Function Desktop BFF weiter, der für die Verarbeitung von datenintensiver Anwendungsverarbeitung verantwortlich ist. Der Desktop BFF aggregiert mehrere Anforderungen mithilfe zugrunde liegenden Microservices-Aufrufe, bevor er mit einer Antwort auf mehrere Seiten auf den Client reagiert.

Entwurf

• Microsoft Entra ID dient als cloudbasierter Identitätsanbieter, der maßgeschneiderte Zielgruppenansprüche sowohl für mobile als auch für Desktopclients ausgibt, die anschließend zur Autorisierung genutzt werden.

• Azure API Management fungiert als Proxy zwischen den Clients und ihren BBFs, die einen Umkreis hinzufügen. Es ist mit Richtlinien konfiguriert, um die JSON-Webtoken (JWTs) zu validieren, wobei Anforderungen abgelehnt werden, die ohne ein Token eingehen oder die Ansprüche für den zielbasierten BFF nicht gültig sind. Darüber hinaus werden alle Aktivitätsprotokolle an Azure Monitor gestreamt.

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

• Azure Functions ist eine serverlose Lösung, die BFF-Logik nahtlos über mehrere Endpunkte verfügbar macht, wodurch eine optimierte Entwicklung ermöglicht wird, der Infrastrukturaufwand reduziert und die Betriebskosten gesenkt werden.

Nächste Schritte

• Muster: Back-Ends für Frontends

Verwandte Ressourcen

• Gatewayaggregationsmuster
• Gateway offloading pattern
• Gatewayroutingmuster
• Authentifizierung und Autorisierung für APIs in Azure API Management
• Vorgehensweise beim Integrieren von Azure API Management in Azure Application Insights
• Serverless-Webanwendungsreferenzarchitektur