De meeste ontwikkelaars hebben al gehoord van microservice-architectuur, maar micro-frontend is een veel minder bekende term. Zoals de naam al doet vermoeden, is micro-frontend qua concept vergelijkbaar met microservices. Het probeert veel van dezelfde problemen op te lossen als monolithische toepassingen. Ze zijn te groot, moeilijk om mee te werken, en moeilijk om aan te passen. Nieuwe mensen aannemen om eraan te werken kan lastig zijn. En als meerdere teams aan verschillende delen van de toepassing werken, moeten ze al hun wijzigingen op elkaar afstemmen.
Microservices helpen u de backend op te splitsen in meer onafhankelijke diensten. Dezelfde aanpak kan worden gebruikt om single page applications (SPA's) op te splitsen in kleinere apps, met de extra behoefte aan een "orchestrator" die verschillende onderdelen weer aan elkaar kan zetten zodat de gebruiker nog steeds SPA-gedrag ervaart.
Wat zijn de alternatieven voor een Micro-frontend-architectuur?
Natuurlijk zijn er andere manieren om met sommige van de ongewenste aspecten van enorme applicaties om te gaan, zoals het scheiden van een deel van de code in zijn eigen npm-pakket. Dat kan een deel van het probleem oplossen, zoals dat de repo te groot is. In Angular kun je bijvoorbeeld ook code scheiden in een module die lui geladen kan worden. Dit kan verticale splitsing van de toepassing tot op zekere hoogte mogelijk maken. Maar, het heeft ook zijn nadelen, zoals het moeten bouwen van het top-level project wanneer een van de afhankelijkheden wordt bijgewerkt. Ook is de ervaring van de ontwikkelaar niet zo geweldig. Als u een framework gebruikt, is het een goed idee om alles te upgraden naar dezelfde versie, maar het is een enorme onderneming waar niemand warm voor loopt. U hebt ook de mogelijkheid om meerdere apps samen te voegen via iframe. Het maakt ze onafhankelijk, maar ik zou zeggen misschien te onafhankelijk omdat inter-appcommunicatie een probleem is en ook het delen van code, stijlen, enz.
Zijn Micro-frontends de redding?
Micro-frontends zijn een combinatie van deze twee benaderingen. Elke micro-frontend is een aparte toepassing die in vergelijking staat met de SPA. Het wordt niet gecompileerd tot een index.html met gekoppelde script- en stijlbestanden, maar tot een JavaScript-module. In plaats van een iframe in de "hoofd"-app, definieert de code dat wanneer de URL overeenkomt met een bepaald patroon, de module dan lui wordt geladen en op een specifieke plaats wordt gezet. Dankzij dit kunnen we meerdere apps op dezelfde pagina hebben die met elkaar verbonden kunnen worden.
Als gevolg daarvan hoeven micro-frontends niet om te gaan met app lay-out- en basis CSS-regels die alleen in de hoofd-app kunnen worden afgehandeld. Even voordelig is het feit dat als ik meerdere micro-frontends heb die dezelfde versie van React gebruiken, dat ik ze dan de React-module kan laten delen. Het hoeft niet apart gedownload te worden voor elke micro-frontend. Het hebben van verschillende versies van een JS-module is ook geen probleem.
De grootste zorg met micro-frontends is om ervoor te zorgen dat hun stijlen niet overlopen naar andere delen van de applicatie. Gelukkig hebben de meeste veelgebruikte UI-frameworks tools om dat met gemak af te handelen.
Tooling voor Micro-frontend-architecturen
Je eigen code schrijven om micro-frontend-applicaties te laden zou een hele klus zijn. Gelukkig zijn er meerdere frameworks die orkestratie verzorgen en tooling bieden om apps geschreven in de meest populaire frameworks om te zetten naar het micro-frontend-formaat.
Bij Pure kiezen we voor single-spa. De belangrijkste voordelen die we hebben gevonden zijn dat het eenvoudig te begrijpen is, brede ondersteuning biedt voor JS-frameworks, en gedetailleerde documentatie heeft. Bovendien biedt single-spa meerdere soorten micro-frontends, elk geschikt voor iets andere taken.
Op dit moment gebruiken we alleen het "Application"-type omdat dat het makkelijkst te gebruiken is voor de overgang van SPA naar micro-frontends. Andere types vereisen ook een meer gedetailleerde micro-frontend-architectuur. Ook wordt "Application" door de auteurs van "single-spa" als standaard aanbevolen.
