tech deep dive.

Micro front end architectuur met Web Components

Wat zijn Web Components?

(waarschuwing; dit artikel bevat diverse woorden die niet bestaan in het Nederlands maar die wij – developers – prima begrijpen)

Laten we bij het begin beginnen. Bijna elke webpagina bestaat tenminste uit HTML, CSS en Javascript. Bij een simpele webpagina zijn dit vaak korte stukjes code die logica beschrijven en die op één plek worden gebruikt. Naarmate de webpagina groter en geavanceerder wordt, is dit meestal ook terug te zien aan de hoeveelheid en (gebrek aan) structuur van de code. Als ontwikkelaar wil je graag code kunnen hergebruiken en niet opnieuw hoeven te schrijven of te kopiëren en te plakken voor iedere pagina. Dit wordt op den duur namelijk niet meer onderhoudbaar, leesbaar en/of testbaar. Daarnaast wil je niet dat bij elke kleine aanpassing van je webapplicatie de gehele website een tijdje down is. Een server heeft over het algemeen wat tijd nodig om de huidige versie van de webapplicatie af te sluiten en de nieuwe versie van de webapplicatie op te starten. Dit proces kan ervoor zorgen dat je webapplicatie voor een (zeer) korte tijd niet bereikbaar is. Dit zijn de twee belangrijkste problemen die Web Components verhelpen.

Wat is de beste timing voor innovatie

Whyellow nieuwsbrief

Nooit meer iets missen van Whyellow? Schrijf je dan in voor onze nieuwsbrief.

Frontend code herbruikbaar maken

Laten we beginnen bij het herbruikbaar maken van je frontend code. Web Components zorgen ervoor dat je custom elementen – stukjes frontend die zowel de logica als het uiterlijk bevatten – kunt genereren. Deze custom elementen worden samengebundeld in een Javascript bestand die je vervolgens via een link kan injecteren in de head van je HTML, waardoor je deze custom elementen overal kan aanroepen. Dit maakt het mogelijk om je frontend op te delen in kleine geïsoleerde componenten die je kunt hergebruiken. Hierdoor blijft je code onderhoudbaar en leesbaar. Daarnaast zorgen de geïsoleerde componenten er ook voor dat je code beter testbaar is. Dit komt doordat je componenten loosely coupled zijn en het de SRP (Single Responsability Principle) volgt wat inhoudt dat de componenten onafhankelijk zijn en één taak hebben waardoor je makkelijker betere tests kunt schrijven.

Downtime beperken

Naast de mogelijkheid om frontend componenten te hergebruiken, zijn Web Components ook een oplossing voor de downtime van je webapplicatie. Omdat je componenten gebundeld zitten in een Javascript bestand, kun je dit Javascript bestand op een server hosten die los staat van je overkoepelende webapplicatie. Wanneer je een aanpassing wilt maken in één van je componenten doe je dit door het Javascript bestand opnieuw te genereren en opnieuw aan te bieden aan de server waar je het op host. Aangezien de server van je overkoepelende webapplicatie los staat van de server waar het Javascript bestand op staat, ervaart deze geen downtime. Wanneer je componenten zijn ge-update, krijgt je overkoepelende webapplicatie de aanpassingen gelijk door, omdat die een link naar het Javascript bestand heeft geïnjecteerd in de header van de HTML. Je overkoepelende webapplicatie heeft dus geen nieuwe release nodig om aangepast te worden!

De techniek van Web Components

Web Components bestaan uit drie verschillende technologieën:

  • Custom elements: dit zijn je eigen gemaakte elementen die in principe niks anders zijn dan een regulier HTML element zoals <div> of <p>. Deze custom elements bevatten elk hun eigen logica en weergave. Tip: custom elements zijn compatibel over verschillende frameworks en browsers. Je kunt dus een custom element maken in Angular met Angular Elements en gebruiken in je Vue.js applicatie!
  • Shadow DOM: is een ingekapselde versie van de DOM van het element en werkt ongeveer zoals een <iframe>. Hierbij is de inhoud gescheiden van de DOM van de webpagina die het injecteert en dus op zichzelf staand en wordt los van het DOM gerenderd.
  • HTML Templates: wordt gebruikt om herbruikbare stukjes HTML te maken die niet direct worden getoond. Deze templates worden pas getoond wanneer een script gebruik maakt van het template en vertelt wat het moet doen.

Hoe gebruiken wij Web Components?

Wij maken regelmatig gebruik van Web Components. Over het algemeen gebruiken wij het Angular framework, wat een Web Components library – genaamd Angular Elements – bevat. Deze library maakt het mogelijk om een Angular component om te zetten naar een custom element.

De webapplicatie hebben we opgedeeld in verschillende domeinen en een overkoepelende webapplicatie die de verschillende domeinen injecteert. Elk domein bevat zijn eigen custom elementen behorend tot dat domein. Op deze manier kunnen we een aanpassing maken in één van de domeinen, dit opleveren en op de server zetten. Onze overkoepelende webapplicatie en de andere domeinen hebben op dat moment geen down time. Dit wordt ook wel gezien als een micro frontend architectuur. Daarnaast is het voor ons op deze manier ook mogelijk om developers te laten werken aan één van de domeinen zonder dat ze gedetailleerde kennis hebben over alle andere domeinen. Doordat de domeinen het SRP volgen en loosely coupled zijn, kunnen de developers ook gemakkelijk testen schrijven voor de domeinen waar zij verantwoordelijk voor zijn. Een verandering in domein A zorgt er namelijk niet voor dat de testen in domein B opnieuw geschreven hoeven te worden en ook voor het schrijven van de testen hoeft er geen domein overkoepelende kennis te zijn.

To Web Components, or not to Web Components?

Persoonlijk zie ik heel veel voordeel in het volgen van het SRP en je code loosely coupled te schrijven in combinatie met de micro frontend architectuur. Om dit te bereiken in je webapplicatie is Web Components een erg handige tool. Echter Web Components is niet iets wat als standaard gebruikt wordt, en de web developers community is nogal verdeeld over het nut van Web Components of de manier waarop het toegepast zou moeten worden. Er zitten namelijk wat haken en ogen aan het gebruik ervan. Zo moet je als developer diepgaande kennis van het web ecosysteem en javascript hebben, is de documentatie vrij beperkt en moet je polyfills gebruiken om het aan te kunnen bieden bij alle browsers. Wegen de voordelen dan op tegen de nadelen? Naar mijn inzicht zeker. Wanneer je het eenmaal goed hebt opgezet is het makkelijk om er verder op door te bouwen en geeft het je alle voordelen die hierboven beschreven staan. Om je alvast een beetje op weg te helpen, sluiten we hieronder af met drie belangrijke tips die wij als developers binnen Whyellow als essentieel zien voor een goede start in de ontwikkeling van je webapplicatie met Web Components.

Drie belangrijke tips:

  1. Deel je applicatie op in logische domeinen die met zo min mogelijk informatie vanuit andere domeinen hun logica kunnen uitvoeren.
  2. Als je frontend communiceert met een API, zorg er dan voor dat deze API opgedeeld is op dezelfde manier als je frontend. Hierdoor bouw je compleet losstaande producten die niet van elkaar afhankelijk zijn.
  3. Zorg ervoor dat je naast de losse domeinen ook een gedeeld domein hebt waar de basis voor alle domeinen in staat, denk hierbij aan database modellen en gedeelde logica.

Deze blog is geschreven door Merik Westerveld, full-stack developer bij Whyellow.

Meer weten over hoe jij Web Components kan inzetten? Neem dan contact op met mij of een van de andere Whyellow-collega’s!

Merik developer over ons Whyellow

Unieke uitdaging zoekt betrouwbare IT-partner?  Zet de eerste stap en neem contact met ons op.

Neem contact op