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.
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.
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.
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.
|
Applicatie |
Parcel |
Utility |
Routing |
Eén of meerdere routes |
Nee |
Nee |
API |
Declaratieve API |
Imperatieve API |
Exports interface |
UI |
Rendert UI |
Rendert UI |
Kan UI renderen |
Levenscyclus |
single-spa |
Eigen |
Externe module zonder levenscyclus |
Wanneer te gebruiken |
Basis building block |
Component die in verschillende frameworks kan worden gebruikt |
Delen van logica |
Op dit moment gebruiken we single-spa met een van onze grotere apps die op dit moment ongeveer vijf micro-frontends bevat. Soms werken andere teams aan deze micro-frontends dan de hoofdteams die de app ontwikkelen. Gelukkig hebben we in de laatste zes maanden, sinds we zijn overgestapt op micro-frontends, nul problemen gemeld gekregen. We zijn ook erg blij dat de hoofdapplicatie niet meer zo opgeblazen is als in het verleden en gemakkelijker kan worden geüpgraded. Bovendien hoeven we ons geen zorgen te maken over neveneffecten bij het toevoegen van nieuwe functionaliteit, aangezien dit meestal gebeurt met een micro-frontend. In de nabije toekomst willen we de frontends van andere grote apps die we bij Pure ontwikkelen opsplitsen, omdat de voordelen voor hen waarschijnlijk ook aanzienlijk zullen zijn. We raden aan om micro-frontends eens te proberen als je tegen dezelfde problemen aanloopt als wij.
Hebt u een vraag of opmerking over Pure-producten of certificeringen? Wij zijn er om te helpen.
Plan een livedemo in en zie zelf hoe Pure kan helpen om jouw data in krachtige resultaten om te zetten.
Bel ons: 31 (0) 20-201-49-65
Media: pr@purestorage.com
Pure Storage
Herikerbergweg 292
1101 CT . Amsterdam Zuidoost
The Netherlands