Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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.
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.
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.
Flow A voor de eerste paginaaanvraag van de mobiele client
De mobiele client verzendt een aanvraag voor een
GET
pagina1
, inclusief het OAuth 2.0-token in de autorisatieheader.De aanvraag bereikt de API Management-gateway, waarmee deze wordt onderschept en:
Controleert de autorisatiestatus. API Management implementeert diepgaande verdediging, zodat de geldigheid van het toegangstoken wordt gecontroleerd.
Streamt de aanvraagactiviteit als logboeken naar Azure Monitor. Details van de aanvraag worden vastgelegd voor controle en bewaking.
Het beleid wordt afgedwongen en vervolgens stuurt API Management de aanvraag door naar de mobiele BFF-service van de Azure-functie.
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.
Het antwoord wordt geretourneerd naar de client.
Flow B voor het eerste gecachete paginaverzoek van de mobiele cliënt
De mobiele client verzendt dezelfde
GET
aanvraag voor pagina1
opnieuw, inclusief het OAuth 2.0-token in de autorisatieheader.De API Management-gateway herkent dat deze aanvraag eerder is gedaan en:
De beleidsregels worden nageleefd. Vervolgens identificeert de gateway een antwoord in de cache dat overeenkomt met de aanvraagparameters.
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
De bureaubladclient verzendt een
GET
aanvraag voor de eerste keer, inclusief het OAuth 2.0-token in de autorisatieheader.De aanvraag bereikt de API Management-gateway, waar kruislingse problemen worden afgehandeld.
Machtiging: Tokenvalidatie is altijd vereist.
De aanvraagactiviteit streamen: Aanvraagdetails worden vastgelegd voor waarneembaarheid.
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