Gebruik jij al een micro frontend?

Gebruik jij al een micro frontend? – Artikel uit Frontmania magazine 2022

Een terugblik op het ontstaan van deze techniek.

De afgelopen paar jaar heb ik steeds vaker mogen werken aan een micro frontend, althans zo werden ze genoemd door de enterprise organisaties waar ik gewerkt heb. Als ontwikkelaar merkte ik echter niet heel veel verschil in mijn alledaagse werkzaamheden. Ik werkte nog steeds met een framework of library, zoals Angular, React of Vue en ik schreef nog steeds HTML, CSS en Java- of Typescript. Dus wat maakte het werken aan deze applicaties dan zó anders waardoor het een andere naam had gekregen? Waar komt de term vandaan en hoe is deze techniek eigenlijk ontstaan?

De term ‘micro frontend’ kwam in de Thoughtworks Technology Radar in 2016 voor het eerst naar boven in de ‘assess’-categorie. Dit is een categorie waarin er wordt gekeken of een bepaalde techniek of oplossing mogelijk interessant is voor ontwikkelaars en bedrijven. Het trok grote lijnen uit de destijds al geadopteerde microservice architectuur, waarbij een applicatie wordt opgeknipt in kleinere applicaties.

Hierdoor is het eenvoudiger om de verschillende functionaliteiten te onderhouden of uit te breiden en is het zelfs mogelijk om meerdere teams tegelijkertijd aan verschillende functionaliteiten te laten werken, iets dat een stuk lastiger was om voor elkaar te krijgen met de monoliet oplossing die voorheen redelijk de standaard was.

Deze splitsing in functionaliteiten kwam niet geheel uit het niets. In voorgaande jaren was het al een standaard geworden om in elk geval het UI-aspect uit verschillende enterprise-applicaties te halen en deze apart op te zetten. Voorbij waren de tijden van het integreren van je frontend in de PHP- of JSP-bestanden aan de backend, en voor ons frontend-ontwikkelaars begon toen het Web App of SPA-tijdperk waar we met behulp van REST APIs fantastische webapplicaties konden neerzetten!

Maar met deze nieuwe manier van denken, kwam ook een nieuw risico naar boven: de wel bekende ‘scope-creep’. Steeds vaker werden er functionaliteiten die we normaliter in de backend bouwde, ook in de frontend verwacht. Denk hierbij aan complexere dingen, zoals de benodigde formules en berekeningen voor bepaalde grafieken of tabellen. Maar ook aan de simpelere dingen, zoals validatie op gebruikersinvoer voordat het naar de backend wordt verstuurd.

In de frontend gingen we steeds vaker richting een probleem waar de backend al een oplossing voor had gevonden. De webapplicaties die we bouwden neigde steeds meer richting een monoliet die de informatie van verschillende microservices moest ophalen en verwerken. Maar als de backend hier al een oplossing voor had gevonden in de vorm van de microservice architectuur, zou dit mogelijk ook een oplossing kunnen zijn voor ons monoliet probleem in de frontend-applicaties.

Een van de eerste signalen richting een microservice architectuur die wij in de frontend zagen, was de toename in gebruik van eigen ontwikkelde en beheerde library’s. Deze library’s omvatte specifieke functionaliteiten die waren losgetrokken van de applicatie en die (vaak met behulp van een private NPM-registry) weer werden afgenomen door de frontend-applicatie waar de functionaliteit oorspronkelijk in verwerkt zat.

Op deze manier was het mogelijk om meerdere teams aan de verschillende functionaliteiten van een frontend-applicatie te laten werken zonder dat deze teams elkaar in de weg zaten.

De gedeelde functionaliteiten varieerden van specifieke applicatielogica tot volledige UI-componenten die voor een uniforme interactie zorgde, maar uiteindelijk zat het vaak allemaal nog in één frontend-applicatie. De logische volgende stap was dan ook proberen om deze ene frontend-applicatie op te knippen in verschillende losse applicaties, zodat deze ook individueel ontwikkeld, beheerd en gereleased konden worden.

Vanaf dit punt werd het concept van een micro-app geïntroduceerd. Een applicatie die één specifieke functionaliteit of domein van een grotere applicatie omvat. Denk bijvoorbeeld aan een verzekerings-applicatie, waarin je meerdere soorten verzekeringen kan beheren of afnemen. Waar je voorheen in één grote webapplicatie zowel het overzicht en de auto- en woonverzekering pagina’s had, kon je nu het overzicht en elke losse verzekering als individuele webapplicatie opzetten en gebruiken. Qua architectuur voor de frontend zaten we na deze laatste stap op vrijwel hetzelfde niveau als de microservice architectuur die al langer in de backend werd toegepast.

Deze signalen en veranderingen zagen wij voor het eerst rond het begin van 2018, ongeveer dezelfde tijd waarin de term ‘micro frontend’ verschoof van de ‘assess’-categorie naar de ‘trial’-categorie in de Thoughtworks Technology Radar. In de ‘trial’-categorie wordt het aangeraden aan enterprise organisaties om te experimenteren met een bepaalde techniek of oplossing, zoals wij in dit geval hebben kunnen zien met de micro frontend-techniek.

Inmiddels is het 2022 en zijn de beschikbare technologieën en tools dusdanig gegroeid, dat het eenvoudiger is dan ooit om te beginnen met de micro frontend-techniek. Dankzij de adoptie van patterns, zoals ‘Domain Driven Design’ en de opkomst van monorepos, is het steeds duidelijker waar de scheiding in functionaliteit zit en hoe deze gefaciliteerd kan worden voor de verschillende frontend-applicaties.

Er zijn, zoals altijd in de developerwereld, verschillende manieren om met micro frontends om te gaan. Denk aan het gebruik van losse applicaties die elk individueel van elkaar functioneren, of het samenvoegen van verschillende applicaties met behulp van een app-shell voor overkoepelende communicatie. De mogelijkheden zijn eindeloos.

Inmiddels komt de term ‘micro frontend’ ook niet meer voor in de Thoughtworks Technology Radar, dit omdat de term inmiddels is geadopteerd en een huis-tuin-en-keuken begrip is geworden voor de meeste ontwikkelaars. Dus, gebruik jij al een micro frontend?

BIO:

Dymion is een ervaren Software Engineer met een liefde voor architectuur en nieuwe technieken. Hij begon in 2010 als Android en iOS-developer tot hij in 2014 de switch maakte naar Fullstack developer met een focus op frontend. Sindsdien heeft hij meerdere enterprise organisaties geholpen met het ontwikkelen van hun applicaties en bekleedt hij sinds een paar jaar de rol van CTO. Programmeren is zijn passie en zijn rol als Software Engineer zal altijd voorop staan in zijn doen en laten. Want van een mooie code oplossing wordt elke developer gelukkig.