Back-ends voor front-ends-patroon

In dit patroon wordt beschreven hoe u back-endservices loskoppelt van front-end-implementaties om ervaringen voor verschillende clientinterfaces aan te passen. Dit patroon is handig als u wilt voorkomen dat u een back-end kunt aanpassen die meerdere interfaces gebruikt. Dit patroon is gebaseerd op het patroon Back-ends voor front-ends door Sam Newman.

Context en probleem

Overweeg een toepassing die in eerste instantie is ontworpen met een bureaubladwebgebruikersinterface en een bijbehorende back-endservice. Naarmate de bedrijfsvereisten na verloop van tijd veranderen, wordt er een mobiele interface toegevoegd. Beide interfaces communiceren met dezelfde back-endservice. Maar de mogelijkheden van een mobiel apparaat verschillen aanzienlijk van een desktopbrowser in termen van schermgrootte, prestaties en weergavebeperkingen.

Het diagram heeft twee secties: de back-endservice en de desktopclient en de mobiele client. Twee dubbelzijdige pijlen wijzen van de back-endservice naar zowel de desktopclient als de mobiele client.

Een back-endservice ondervindt vaak concurrerende eisen van meerdere front-endsystemen. Deze eisen leiden tot frequente updates en potentiële knelpunten voor ontwikkeling. Conflicterende updates en de noodzaak om compatibiliteit te behouden, leiden tot overmatige vraag op één implementeerbare resource.

Het hebben van een afzonderlijk team om de backend-service te beheren, kan een kloof creëren tussen frontend- en backendteams. Deze scheiding kan vertragingen veroorzaken bij het verkrijgen van consensus en het in balans brengen van vereisten. Wijzigingen die door één front-endteam worden aangevraagd, moeten bijvoorbeeld worden gevalideerd met andere front-endteams vóór de integratie.

Oplossing

Introduceer een nieuwe laag die alleen de vereisten afhandelt die specifiek zijn voor de interface. Deze laag, ook wel de BFF-service (backend-for-frontend) genoemd, bevindt zich tussen de front-endclient en de back-endservice. Als de toepassing meerdere interfaces ondersteunt, zoals een webinterface en een mobiele app, maakt u een BFF-service voor elke interface.

Dit patroon past de clientervaring voor een specifieke interface aan zonder dat dit van invloed is op andere interfaces. Het optimaliseert ook de prestaties om te voldoen aan de behoeften van de front-endomgeving. Omdat elke BFF-service kleiner en minder complex is dan een gedeelde back-endservice, kan de toepassing eenvoudiger worden beheerd.

Front-endteams beheren onafhankelijk hun eigen BFF-service, waardoor ze controle hebben over taalselectie, releasefrequentie, prioriteitstelling van workloads en functieintegratie. Dankzij deze autonomie kunnen ze efficiënt werken zonder dat ze afhankelijk zijn van een gecentraliseerd back-endontwikkelingsteam.

Veel BFF-services waren traditioneel afhankelijk van REST API's, maar GraphQL-implementaties komen op als alternatief. Met GraphQL elimineert het querymechanisme de noodzaak van een afzonderlijke BFF-laag, omdat clients hiermee de gegevens kunnen aanvragen die ze nodig hebben zonder dat ze afhankelijk zijn van vooraf gedefinieerde eindpunten.

In het diagram ziet u drie secties. De eerste sectie bestaat uit de desktopclient en de mobiele client. De tweede sectie bestaat uit de BFF-service van de desktopclient en de BFF-service voor mobiele clients. De bureaubladclient heeft een vaste pijl die verwijst naar de BFF-dienst van de bureaubladclient. De mobiele client heeft een dikke pijl die verwijst naar de BFF-service van de mobiele client. Elke BFF-service heeft een stippellijn die verwijst naar de back-endservicesectie.

Voor meer informatie, zie Backends voor Frontends-patroon door Sam Newman.

Problemen en overwegingen

• Evalueer uw optimale aantal services, afhankelijk van de bijbehorende kosten. Het onderhouden en implementeren van meer services betekent een verhoogde operationele overhead. Elke afzonderlijke service heeft zijn eigen levenscyclus, implementatie- en onderhoudsvereisten en beveiligingsbehoeften.

• Controleer de serviceniveaudoelstellingen wanneer u een nieuwe service toevoegt. Er kan een verhoogde latentie optreden omdat clients geen rechtstreeks contact opnemen met uw services en de nieuwe service een extra netwerkhop introduceert.

• Wanneer verschillende interfaces dezelfde aanvragen indienen, evalueert u of de aanvragen kunnen worden samengevoegd in één BFF-service. Het delen van één BFF-service tussen meerdere interfaces kan leiden tot verschillende vereisten voor elke client, wat de groei en ondersteuning van de BFF-service kan bemoeilijken.

  Codeduplicatie is een waarschijnlijk resultaat van dit patroon. Evalueer de afweging tussen codeduplicatie en een beter op maat gemaakte ervaring voor elke client.

• De BFF-service mag alleen clientspecifieke logica verwerken die betrekking heeft op een specifieke gebruikerservaring. Overkoepelende functies, zoals bewaking en autorisatie, zouden moeten worden geabstraheerd om de efficiëntie te behouden. Typische functies die in de BFF-service kunnen optreden, worden afzonderlijk afgehandeld met de gatekeeping-, snelheidsbeperkings- en routeringspatronen .

• Bedenk hoe het leren en implementeren van dit patroon van invloed is op het ontwikkelteam. Het ontwikkelen van nieuwe back-endsystemen vereist tijd en moeite, wat kan leiden tot technische schulden. Het onderhouden van de bestaande back-endservice voegt deze uitdaging toe.

• Evalueer of u dit patroon nodig hebt. Als uw organisatie bijvoorbeeld GraphQL gebruikt met front-endspecifieke resolvers, voegen BFF-services mogelijk geen waarde toe aan uw toepassingen.

  Een ander scenario is een toepassing die een API-gateway combineert met microservices. Deze benadering kan voldoende zijn voor sommige scenario's waarbij BFF-services doorgaans worden aanbevolen.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• Een gedeelde of algemene back-endservice vereist aanzienlijke ontwikkelingsoverhead om te onderhouden.

• U wilt de back-end optimaliseren voor de vereisten van specifieke clientinterfaces.

• U kunt aanpassingen aanbrengen in een back-end voor algemeen gebruik voor meerdere interfaces.

• Een programmeertaal is beter geschikt voor de back-end van een specifieke gebruikersinterface, maar niet voor alle gebruikersinterfaces.

Dit patroon is mogelijk niet geschikt wanneer:

• Interfaces maken dezelfde of vergelijkbare aanvragen voor de back-end.

• Slechts één interface communiceert met de back-end.

Werklastontwerp

Evalueer hoe u het Backends for Frontends-patroon in het ontwerp van een workload kunt gebruiken om de doelstellingen en principes te behandelen die worden besproken in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pilaar	Hoe dit patroon ondersteuning biedt voor pijlerdoelen
betrouwbaarheid ontwerpbeslissingen helpen uw workload tolerant te worden defect te raken en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een storing is opgetreden.	Wanneer u services isoleert tot een specifieke frontendinterface, beperkt u storingen. De beschikbaarheid van één client heeft geen invloed op de beschikbaarheid van de toegang van een andere client. Wanneer u verschillende clients verschillend behandelt, kunt u prioriteit geven aan betrouwbaarheidsinspanningen op basis van verwachte clienttoegangspatronen. - RE:02 Kritieke stromen - RE:07 Zelfbehoud
Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen.	Dankzij de servicescheiding die in dit patroon is geïntroduceerd, kunnen beveiliging en autorisatie in de servicelaag worden aangepast voor de specifieke behoeften van elke client. Deze aanpak kan het oppervlakgebied van de API verminderen en laterale verplaatsing tussen back-ends beperken die verschillende mogelijkheden mogelijk beschikbaar maken. - SE:04 Segmentatie - SE:08 Versterking van middelen
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code.	Met de scheiding van de back-end kunt u optimaliseren op manieren die mogelijk niet mogelijk zijn met een gedeelde servicelaag. Wanneer u afzonderlijke clients anders verwerkt, kunt u de prestaties optimaliseren voor de beperkingen en functionaliteit van een specifieke client. - PE:02 Capaciteitsplanning - PE:09 Kritieke stromen

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Voorbeeld

In dit voorbeeld ziet u een use-case voor het patroon waarin twee afzonderlijke clienttoepassingen, een mobiele app en een bureaubladtoepassing, communiceren met Azure API Management (gegevensvlakgateway). Deze gateway fungeert als een abstractielaag en beheert veelvoorkomende kruislingse problemen, zoals:

• Autorisatie. Zorgt ervoor dat alleen geverifieerde identiteiten met de juiste toegangstokens beveiligde resources kunnen aanroepen met BEHULP van API Management met Microsoft Entra ID.

• Toezicht. Legt aanvraag- en antwoordgegevens vast en verzendt deze naar Azure Monitor voor waarneembaarheidsdoeleinden.

• Caching aanvragen. Optimaliseert herhaalde aanvragen door reacties uit de cache te leveren door ingebouwde functies van API Management.

• Routing en aggregatie. Stuurt binnenkomende aanvragen door naar de juiste BFF-services.

Elke client heeft een toegewezen BFF-service die wordt uitgevoerd als een Azure-functie die fungeert als intermediair tussen de gateway en de onderliggende microservices. Deze clientspecifieke BFF-services zorgen voor een op maat gemaakte ervaring voor paginering en andere functionaliteiten. De mobiele app geeft prioriteit aan bandbreedte-efficiëntie en maakt gebruik van caching om de prestaties te verbeteren. De bureaubladtoepassing haalt daarentegen meerdere pagina's op in één aanvraag, waardoor een meer meeslepende gebruikerservaring ontstaat.

Het diagram is gestructureerd in vier secties die de stroom van aanvragen, verificatie, bewaking en clientspecifieke verwerking illustreren. Twee clientapparaten initiëren aanvragen: een mobiele toepassing die is geoptimaliseerd voor een gebruikerservaring die efficiënt is met bandbreedte en een webbrowser die een volledig functionele interface biedt. Pijlen lopen van beide apparaten naar het centrale toegangspunt, de API Management-gateway, om aan te geven dat alle aanvragen via deze laag moeten worden doorgegeven. In de tweede sectie, tussen een rechthoek met stippellijn, wordt de architectuur onderverdeeld in twee horizontale groepen. De linkergroep vertegenwoordigt de API Management die binnenkomende aanvragen verwerkt en bepaalt hoe deze moeten worden verwerkt. Twee pijlen breiden zich uit vanaf deze gegevensvlakgateway. Eén pijl omhoog naar Microsoft Entra ID, waarmee de autorisatie wordt beheerd. Een andere pijl wijst omlaag naar Azure Monitor, die verantwoordelijk is voor logboekregistratie en waarneembaarheid. Een pijl loopt terug van de gateway naar de mobiele client, die een reactie in de cache vertegenwoordigt wanneer een identieke aanvraag wordt herhaald, waardoor onnodige verwerking wordt verminderd. De rechter groep binnen de stippellijnrechthoek richt zich op het aanpassen van backend-antwoorden op basis van het type cliënt dat de aanvraag plaatst. Het bevat twee afzonderlijke back-end-for-front-end-clients, beide gehost met behulp van Azure Functions voor serverloze computing. De ene is toegewezen aan de mobiele client en de andere aan de desktopclient. Twee pijlen strekken zich uit van de gateway naar deze back-end-for-front-end-clients en illustreren dat elke binnenkomende aanvraag afhankelijk van de client, wordt doorgestuurd naar de juiste service. Voorbij deze laag breiden gestreepte pijlen zich uit en verbinden de backend-voor-frontend-clients met verschillende microservices, die de werkelijke bedrijfslogica verwerken. In de afbeelding ziet u een stroom van links naar rechts waarin clientaanvragen van mobiele en webclients naar de gateway worden verplaatst. Deze gateway verwerkt elke aanvraag tijdens het delegeren van verificatie naar de id-provider en het naar beneden vastleggen van de bewakingsservice. Van daaruit worden aanvragen gerouteerd naar de juiste back-end-for-front-endclient op basis van of de aanvraag afkomstig is van een mobiele client of desktopclient. Ten slotte stuurt elke back-end-for-front-endclient de aanvraag door naar gespecialiseerde microservices, die de vereiste bedrijfslogica uitvoeren en het benodigde antwoord retourneren. Als er een reactie in de cache beschikbaar is, onderschept de gateway de aanvraag en verzendt de opgeslagen reactie rechtstreeks naar de mobiele client, waardoor redundante verwerking wordt voorkomen.

Flow A voor de eerste paginaaanvraag van de mobiele client

1. De mobiele client verzendt een aanvraag voor een GET pagina 1, inclusief het OAuth 2.0-token in de autorisatieheader.

2. De aanvraag bereikt de API Management-gateway, waarmee deze wordt onderschept en:

   1. Controleert de autorisatiestatus. API Management implementeert diepgaande verdediging, zodat de geldigheid van het toegangstoken wordt gecontroleerd.

   2. Streamt de aanvraagactiviteit als logboeken naar Azure Monitor. Details van de aanvraag worden vastgelegd voor controle en bewaking.

3. Het beleid wordt afgedwongen en vervolgens stuurt API Management de aanvraag door naar de mobiele BFF-service van de Azure-functie.

4. De mobiele BFF-service van de Azure-functie communiceert vervolgens met de benodigde microservices om één pagina op te halen en de aangevraagde gegevens te verwerken om een lichtgewicht ervaring te bieden.

5. Het antwoord wordt geretourneerd naar de client.

Flow B voor het eerste gecachete paginaverzoek van de mobiele cliënt

1. De mobiele client verzendt dezelfde GET aanvraag voor pagina 1 opnieuw, inclusief het OAuth 2.0-token in de autorisatieheader.

2. De API Management-gateway herkent dat deze aanvraag eerder is gedaan en:

   1. De beleidsregels worden nageleefd. Vervolgens identificeert de gateway een antwoord in de cache dat overeenkomt met de aanvraagparameters.

   2. Retourneert onmiddellijk het antwoord in de cache. Deze snelle reactie elimineert de noodzaak om de aanvraag door te sturen naar de mobiele BFF-service van de Azure-functie.

Flow C voor de eerste aanvraag van de desktop-client

1. De bureaubladclient verzendt een GET aanvraag voor de eerste keer, inclusief het OAuth 2.0-token in de autorisatieheader.

2. De aanvraag bereikt de API Management-gateway, waar kruislingse problemen worden afgehandeld.

   1. Machtiging: Tokenvalidatie is altijd vereist.

   2. De aanvraagactiviteit streamen: Aanvraagdetails worden vastgelegd voor waarneembaarheid.

3. Nadat alle beleidsregels zijn toegepast, stuurt API Management de aanvraag door naar de Azure Function Desktop BFF-service, die de gegevensintensieve toepassingsverwerking afhandelt. De desktop BFF-service verzamelt meerdere aanvragen door gebruik te maken van onderliggende microservices-aanroepen, voordat het antwoord geeft aan de client met een respons die meerdere pagina's beslaat.

Ontwerpen

• Microsoft Entra ID fungeert als de identiteitsprovider in de cloud. Het biedt op maat gemaakte doelgroepclaims voor zowel mobiele als desktopclients. Deze claims worden vervolgens gebruikt voor autorisatie.

• API Management fungeert als een proxy tussen de clients en hun BFF-services, waarmee een perimeter tot stand wordt gebracht. API Management is geconfigureerd met beleid om de JSON-webtokens te valideren en aanvragen te weigeren die geen token hebben of ongeldige claims bevatten voor de beoogde BFF-service. Ook worden alle activiteitenlogboeken naar Azure Monitor gestreamd.

• Azure Monitor fungeert als gecentraliseerde bewakingsoplossing. Alle activiteitenlogboeken worden samengevoegd om een uitgebreide end-to-end waarneembaarheid te garanderen.

• Azure Functions is een serverloze oplossing die BFF-servicelogica efficiënt beschikbaar maakt voor meerdere eindpunten, wat de ontwikkeling vereenvoudigt. Azure Functions minimaliseert ook de overhead van de infrastructuur en helpt de operationele kosten te verlagen.

Volgende stappen

• "Backends for Frontends"-patroon door Sam Newman
• Verificatie en autorisatie voor API's in API Management
• API Management integreren met Application Insights

Verwante middelen

• Gateway Aggregation pattern (Patroon Aggregatie van gateway)
• Gateway Offloading pattern (Patroon Offloading van gateway)
• Gateway Routing pattern (Patroon Routering van gateway)
• referentiearchitectuur voor serverloze webtoepassingen