Afzonderlijke back-endservices maken om te worden verbruikt door specifieke front-endtoepassingen of -interfaces. Dit patroon is handig om te voorkomen dat een eenmalige back-end voor meerdere interfaces wordt aangepast. Dit patroon werd voor het eerst beschreven door Sam Newman.
Context en probleem
Een toepassing kan in eerste instantie worden gericht op een bureaublad-webgebruikersinterface. Normaal gesproken wordt een back-endservice parallel ontwikkeld waarbij de functies worden geleverd die voor die gebruikersinterface nodig zijn. Wanneer de gebruikersgroep van de toepassing groter wordt, wordt er een mobiele toepassing ontwikkeld die met dezelfde back-end moet communiceren. De back-endservice wordt een algemene back-end die voldoet aan de vereisten van zowel de bureaublad- als mobiele interfaces.
Maar de mogelijkheden van een mobiel apparaat verschillen aanzienlijk van een desktopbrowser, wat betreft schermgrootte, prestaties en weergavebeperkingen. Daardoor verschillen de vereisten voor de back-end van mobiele toepassingen van die van de bureaublad-webgebruikersinterface.
Deze verschillen resulteren in concurrerende vereisten voor de back-end. Voor de back-end zijn normale en belangrijke wijzigingen nodig voor het uitvoeren van zowel de bureaublad-webgebruikersinterface als de mobiele toepassing. Vaak werken er verschillende interfaceteams aan elke front-end, waardoor de back-end een knelpunt in het ontwikkelingsproces wordt. Conflicterende updatevereisten en de noodzaak de service voor beide front-ends intact te houden, kunnen voor veel werk aan één implementeerbare resource zorgen.
Als de ontwikkelingsactiviteit is gericht op de back-endservice, kan er wellicht een afzonderlijk team worden opgezet om de back-end te beheren en onderhouden. Dit resulteert uiteindelijk in een scheiding tussen de ontwikkelteams voor interface en back-end, waardoor het back-endteam extra wordt belast om de concurrerende vereisten van de verschillende gebruikersinterfaceteams op elkaar af te stemmen. Als één interfaceteam wijzigingen aan de back-end verlangt, moeten deze wijzigingen worden gevalideerd met andere interfaceteams voordat ze in de back-end kunnen worden geïntegreerd.
Oplossing
Maak één back-end per gebruikersinterface. Verfijn het gedrag en de prestaties van elke back-end zodat deze het beste aansluit bij de behoeften van de front-endomgeving, zonder dat u zich zorgen hoeft te maken over het beïnvloeden van andere front-endervaringen.
Omdat elke back-end specifiek voor één interface is, kan deze back-end voor die interface worden geoptimaliseerd. Dat maakt de back-end kleiner, minder complex en waarschijnlijk sneller dan een algemene back-end die probeert te voldoen aan de vereisten voor alle interfaces. Elk interfaceteam kan zelfstandig beslissen over het beheer van hun eigen back-end en is niet afhankelijk van een gecentraliseerd back-endontwikkelteam. Dat biedt het interfaceteam de nodige flexibiliteit in het selecteren van de taal, de frequentie waarmee releases worden uitgebracht, de prioritering van workloads en de integratie van functies in hun back-end.
Zie Pattern: Backends For Frontends (Patroon: Back-ends voor front-ends) voor meer informatie.
Problemen en overwegingen
- Houd rekening met het aantal te implementeren back-ends.
- Als andere interfaces (zoals mobiele clients) dezelfde aanvragen indienen, denk er dan eens over na of het nodig is een back-end voor elke interface te implementeren, of dat kan worden volstaan met één back-end.
- Duplicatie van code tussen services zal zeer waarschijnlijk plaatsvinden bij het implementeren van dit patroon.
- Op de front-end gerichte back-endservices moeten alleen client-specifieke logica en werking bevatten. Algemene bedrijfslogica en andere algemene functies moeten elders in uw toepassing worden beheerd.
- Denk na over hoe dit patroon kan worden opgenomen in de verantwoordelijkheden van een ontwikkelteam.
- Denk er ook over na hoelang de implementatie van dit patroon gaat duren. Gaat het bouwen van de nieuwe back-ends gepaard met technische inspanningen, terwijl u de bestaande algemene back-end blijft ondersteunen?
Wanneer dit patroon gebruiken
Gebruik dit patroon wanneer:
- Een gedeelde of algemene back-endservice moet worden onderhouden met een aanzienlijke overhead wat betreft de ontwikkeling ervan.
- U wilt de back-end optimaliseren met het oog op de vereisten voor specifieke clientinterfaces.
- Aanpassingen worden uitgevoerd op een algemene back-end om meerdere interfaces te kunnen onderbrengen.
- 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 gelijksoortige aanvragen naar de back-end sturen.
- Wanneer er slechts één interface wordt gebruikt om met de back-end te communiceren.
Workloadontwerp
Een architect moet evalueren hoe het patroon Back-ends voor front-ends kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:
| Pijler | 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.
Volgende stappen
Verwante resources
- Gateway Aggregation pattern (Patroon Aggregatie van gateway)
- Gateway Offloading pattern (Patroon Offloading van gateway)
- Gateway Routing pattern (Patroon Routering van gateway)