Koppel back-endservices los van de 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 patroon: back-ends voor front-ends beschreven door Sam Newman.
Context en probleem
Overweeg een toepassing die oorspronkelijk is ontworpen met een bureaubladwebgebruikersinterface en een bijbehorende back-endservice. Naarmate de bedrijfsvereisten na verloop van tijd zijn gewijzigd, is er een mobiele interface toegevoegd. Beide interfaces communiceren met dezelfde back-endservice, maar de mogelijkheden van een mobiel apparaat verschillen aanzienlijk van een desktopbrowser, wat betreft schermgrootte, prestaties en weergavebeperkingen.
De back-endservice heeft vaak te maken met concurrerende eisen van verschillende front-ends, wat leidt tot frequente wijzigingen en potentiële knelpunten in het ontwikkelingsproces. Conflicterende updates en de noodzaak om compatibiliteit te behouden leiden tot overmatig werk aan één implementeerbare resource.
Door een afzonderlijk team de back-endservice te beheren, kan de verbinding tussen front-end- en back-endteams worden verbroken, wat vertragingen veroorzaakt bij het verkrijgen van consensus- en evenwichtsvereisten. 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 interfacespecifieke vereisten afhandelt. Deze laag heet de BFF-service (backend-for-frontend), bevindt zich tussen de front-endclient en de back-endservice. Als de toepassing meerdere interfaces ondersteunt, maakt u voor elke interface een BFF-service. Als u bijvoorbeeld een webinterface en een mobiele app hebt, maakt u afzonderlijke BFF-services voor elke app.
Dit patroon past de clientervaring aan voor een specifieke interface, zonder dat dit van invloed is op andere interfaces. Daarnaast worden de prestaties nauwkeurig afgestemd op de behoeften van de front-endomgeving. Omdat elke BFF-service kleiner en minder complex is, kan de toepassing tot een bepaalde mate optimalisatievoordelen ervaren.
Front-endteams hebben autonomie ten opzichte van hun eigen BFF-service, waardoor flexibiliteit in taalselectie, releasefrequentie, prioriteitstelling van werkbelastingen en functieintegratie mogelijk is zonder afhankelijk te zijn van een gecentraliseerd back-endontwikkelingsteam.
Hoewel veel BFF's afhankelijk zijn van REST API's, worden GraphQL-implementaties een alternatief, waardoor de behoefte aan de BFF-laag wordt verwijderd omdat het querymechanisme geen afzonderlijk eindpunt vereist.
Zie patroon: back-ends voor front-endsvoor meer informatie.
Problemen en overwegingen
Evalueer wat het optimale aantal services voor u is, omdat dit kosten met zich meebrengt. 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 (SLO's) bij het toevoegen van een nieuwe service. 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. Geavanceerde functies, zoals bewaking en autorisatie, moeten worden geabstraheerd om BFF-servicelicht te houden. Typische functies die in de BFF-service kunnen optreden, worden afzonderlijk afgehandeld met Gatekeeping, rate limiting, Routingen andere.
Houd rekening met de impact op het ontwikkelteam bij het leren en implementeren van dit patroon. Voor het bouwen van nieuwe back-ends is tijd en moeite vereist, waardoor mogelijk technische schulden worden gemaakt terwijl de bestaande back-endservice behouden blijft.
Evalueer of u dit patroon helemaal nodig hebt. Als uw organisatie bijvoorbeeld GraphQL gebruikt met front-endspecifieke resolvers, voegt BFF mogelijk geen waarde toe aan uw toepassingen.
Een ander voorbeeld is een toepassing die API Gateway- combineert met microservices. Deze aanpak kan voldoende zijn voor sommige gevallen waarin BFF's eerder werden aanbevolen.
Wanneer gebruikt u dit patroon?
Gebruik dit patroon wanneer:
Een gedeelde of algemene back-endservice moet worden onderhouden met aanzienlijke ontwikkelingsoverhead.
U wilt de back-end optimaliseren voor de vereisten van specifieke clientinterfaces.
Aanpassingen worden aangebracht 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 in de volgende gevallen:
Wanneer interfaces dezelfde of vergelijkbare aanvragen voor de back-end maken.
Wanneer slechts één interface wordt gebruikt om te communiceren met de back-end.
Workloadontwerp
Een architect moet evalueren hoe het patroon Back-ends voor front-ends kan worden gebruikt in het ontwerp van de workload om de doelstellingen en principes van de Azure Well-Architected Framework-pijlersaan te pakken. Voorbeeld:
| Pilaar | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Beslissingen over betrouwbaarheidsontwerp helpen uw workload bestand te worden tegen storingen en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een fout is opgetreden. | Het hebben van afzonderlijke services die exclusief zijn voor een specifieke front-endinterface bevat storingen, zodat de beschikbaarheid van een client mogelijk niet van invloed is op de beschikbaarheid van de toegang van een andere client. Wanneer u verschillende clients verschillend behandelt, kunt u ook 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. | Vanwege servicescheiding die in dit patroon is geïntroduceerd, kan de beveiliging en autorisatie in de servicelaag die ondersteuning biedt voor één client, worden afgestemd op de functionaliteit die door die client is vereist, waardoor het oppervlak van een API en laterale verplaatsing tussen verschillende back-ends kan worden verminderd die verschillende mogelijkheden mogelijk beschikbaar maken. - SE:04 Segmentatie - SE:08 Hardening resources |
| Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door optimalisaties in schalen, gegevens, 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 |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.
Voorbeeld
In dit voorbeeld ziet u een use-case voor het patroon waarin u twee verschillende clienttoepassingen hebt: een mobiele app en een bureaubladtoepassing. Beide clients communiceren met een Azure API Management (gegevensvlakgateway), die fungeert als een abstractielaag, waarmee veelvoorkomende problemen worden verwerkt, zoals:
Autorisatie: ervoor zorgen dat alleen geverifieerde identiteiten met de juiste toegangstokens beveiligde resources kunnen aanroepen met behulp van de Azure API Management (APIM) met Microsoft Entra-id.
Bewaking: het vastleggen en verzenden van aanvraag- en antwoorddetails voor waarneembaarheidsdoeleinden naar Azure Monitor.
caching van aanvragen: herhaalde aanvragen optimaliseren door antwoorden uit de cache te leveren met behulp van ingebouwde APIM-functies.
Routing & Aggregation: binnenkomende aanvragen doorsturen naar de juiste back-end voor BFF-services (Frontend).
Elke client heeft een toegewezen BFF-service die wordt uitgevoerd als een Azure-functie die als intermediair tussen de gateway en de onderliggende microservices fungeert. Deze clientspecifieke BFF zorgt voor een op maat gemaakte ervaring voor paginering en andere functionaliteiten. Hoewel de mobiele app meer bandbreedtebewust is en caching de prestaties verbetert, worden meerdere pagina's in één aanvraag samengevoegd, waardoor de prestaties worden geoptimaliseerd voor een rijkere gebruikerservaring.
Het diagram is gestructureerd in vier afzonderlijke secties, die de stroom van aanvragen, verificatie, bewaking en clientspecifieke verwerking illustreren. Aan de linkerkant initiëren twee clientapparaten aanvragen: een mobiele toepassing die is geoptimaliseerd voor een bandbreedte-efficiënte gebruikerservaring en een webbrowser die een volledig functionele interface biedt. Pijlen lopen van beide apparaten naar het centrale toegangspunt, de Azure API Management-gateway, waarmee wordt aangegeven dat alle aanvragen via deze laag moeten worden doorgegeven. Binnen de tweede sectie, tussen een rechthoek met stippellijn, wordt de architectuur onderverdeeld in twee horizontale groepen. De linkergroep vertegenwoordigt de Azure API Management, die verantwoordelijk is voor het verwerken van binnenkomende aanvragen en het bepalen hoe ze moeten worden verwerkt. Twee pijlen breiden zich uit vanaf deze gegevensvlakgateway: één die omhoog wijst naar Microsoft Entra-id, waarmee de autorisatie wordt beheerd en een andere die omlaag wijst naar Azure Monitor, die verantwoordelijk is voor logboekregistratie en waarneembaarheid. Bovendien loopt een pijl terug van de gateway naar de mobiele client, die een antwoord in de cache vertegenwoordigt wanneer een identieke aanvraag wordt herhaald, waardoor onnodige verwerking wordt verminderd. De juiste groep in de rechthoek met streepjes richt zich op het aanpassen van back-endantwoorden op basis van het type client dat de aanvraag indient. Het bevat twee afzonderlijke back-end-for-front-end-clients, beide gehost met Behulp van Azure Functions voor serverloze computing, één die is toegewezen aan de mobiele client en de andere voor de desktopclient. Twee pijlen van de gateway naar deze back-end-for-front-endclients, waarin wordt aangegeven dat elke binnenkomende aanvraag wordt doorgestuurd naar de juiste service, afhankelijk van het clienttype. Voorbij deze laag worden onderbroken pijlen verder naar rechts uitgebreid en worden de back-end-for-front-endclients verbonden met verschillende microservices, die de werkelijke bedrijfslogica verwerken. Als u dit diagram wilt visualiseren, stelt u zich een van links naar rechtse stroom voor waarbij 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: Mobiele client – aanvraag eerste pagina
- De mobiele client verzendt een
GETaanvraag voor de pagina1inclusief het OAuth 2.0-token in de autorisatieheader. - De aanvraag bereikt de Azure APIM-gateway, waarmee deze wordt onderschept en:
- Controleert de autorisatiestatus: APIM implementeert diepgaande verdediging, zodat de geldigheid van het toegangstoken wordt gecontroleerd.
- Stream de aanvraagactiviteit als logboeken naar Azure Monitor: details van de aanvraag worden vastgelegd voor controle en bewaking.
- Het beleid wordt afgedwongen en vervolgens stuurt Azure APIM de aanvraag naar de Azure Function Mobile BFF.
- De Azure Function Mobile BFF communiceert vervolgens met de benodigde microservices om één pagina op te halen en de aangevraagde gegevens te verwerken om een lichtgewicht ervaring te bieden.
- Het antwoord wordt geretourneerd naar de client.
Stroom B: Mobiele client : aanvraag in cache op de eerste pagina
- De mobiele client verzendt dezelfde
GETaanvraag voor de pagina1opnieuw inclusief het OAuth 2.0-token in de autorisatieheader. - De Azure APIM Gateway herkent dat deze aanvraag eerder is ingediend en:
- Het beleid wordt afgedwongen en daarna wordt een antwoord in de cache geïdentificeerd dat overeenkomt met de aanvraagparameters.
- Retourneert onmiddellijk het antwoord in de cache, waardoor de aanvraag niet meer naar de Azure Function Mobile BFF hoeft te worden doorgestuurd.
Flow C: Desktop-client – eerste aanvraag
- De desktopclient verzendt een
GETaanvraag voor de eerste keer, inclusief het OAuth 2.0-token in de autorisatieheader. - De aanvraag bereikt de Azure APIM Gateway, waarbij vergelijkbare cross-cutting problemen worden afgehandeld:
- Autorisatie: tokenvalidatie is altijd vereist.
- Stream de aanvraagactiviteit: aanvraagdetails worden vastgelegd voor waarneembaarheid.
- Zodra alle beleidsregels zijn afgedwongen, stuurt Azure APIM de aanvraag naar de Azure Function Desktop BFF, die verantwoordelijk is voor het verwerken van gegevensverwerking van toepassingen. Het bureaublad-BFF voegt meerdere aanvragen samen met behulp van onderliggende microservices-aanroepen voordat ze reageren op de client met een antwoord op meerdere pagina's.
Ontwerpen
Microsoft Entra ID fungeert als identiteitsprovider in de cloud, waarbij op maat gemaakte doelgroepclaims worden uitgegeven voor zowel mobiele als desktopclients, die vervolgens worden gebruikt voor autorisatie.
Azure API Management- fungeert als proxy tussen de clients en hun BBF's die een perimeter toevoegen. Deze is geconfigureerd met beleid om de JSON-webtokens (JWT's) te te valideren, aanvragen te weigeren die zonder token binnenkomen of de claims zijn niet geldig voor de beoogde BFF. Daarnaast worden alle activiteitenlogboeken naar Azure Monitor gestreamd.
Azure Monitor fungeert als gecentraliseerde bewakingsoplossing, waarbij alle activiteitenlogboeken worden samengevoegd om een uitgebreide end-to-end waarneembaarheid te garanderen.
Azure Functions is een serverloze oplossing die Naadloos BFF-logica beschikbaar maakt voor meerdere eindpunten, waardoor gestroomlijnde ontwikkeling mogelijk is, de overhead van de infrastructuur wordt verminderd en de operationele kosten worden verlaagd.