Patroon Back-ends voor front-ends

  • Artikel
  • 3 minuten om te lezen

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.

De mogelijkheden van een mobiel apparaat verschillen echter aanzienlijk van die van een desktopbrowser, wat betreft de 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.

Context- en probleemdiagram van het patroon Back-ends voor front-enden

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. Het gedrag en de prestaties van elke back-end afstemmen op de behoeften van de front-endomgeving, zonder dat u zich zorgen hoeft te maken over de gevolgen voor andere front-end-ervaringen.

Diagram van het patroon Back-enden voor front-enden

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 andere taal is beter geschikt voor de back-end van een andere gebruikersinterface.

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.

Volgende stappen