De applicatie VIPLive wordt dagelijks gebruikt door huisartsen en andere eerstelijnszorgverleners voor onder andere declaraties, verwijzingen en zorginhoudelijke processen. Door de jaren heen groeide het platform uit tot een omvangrijke monoliet. Nieuwe functionaliteiten toevoegen werd steeds complexer en teams werden afhankelijker van elkaar. 

Van monoliet naar micro front-ends 

Om die afhankelijkheden te doorbreken, kozen we ervoor om VIPLive stap voor stap op te knippen in micro front-ends. Daarbij blijft één centrale shell bestaan, terwijl afzonderlijke functionaliteiten als losse onderdelen worden ontwikkeld en uitgerold. 

Het grote voordeel is dat teams zelfstandiger kunnen werken. Nieuwe functionaliteiten kunnen worden ontwikkeld en gereleased zonder dat de volledige applicatie hoeft mee te veranderen. Dat zagen we ook terug in de praktijk. Toen er na een release een productie-issue ontstond, konden we binnen enkele minuten een fix uitrollen zonder impact op de rest van het platform. 

Maar tijdens deze transitie ontdekte ik dat techniek slechts een deel van de oplossing is. 

Meer vrijheid vraagt om minder afhankelijkheden 

Veel mensen denken dat micro front-ends automatisch zorgen voor autonomie. In werkelijkheid kun je een applicatie technisch opdelen en alsnog afhankelijk blijven van andere teams. 

Juist daarom houd ik mij als Front-end Architect bezig met de vraag hoe teams onafhankelijk kunnen werken zonder de samenhang te verliezen. Ik ondersteun teams bij architectuurkeuzes, nieuwe technieken en het opzetten van nieuwe functionaliteiten. Daarnaast bewaken we gezamenlijk de technische visie en consistentie binnen het platform. 

Dat speelt ook wanneer meerdere ontwikkelteams tegelijkertijd aan dezelfde applicatie werken. Hoe meer afhankelijkheden je deelt, hoe sneller je weer tegen dezelfde beperkingen aanloopt als bij een monoliet. 

Architectuur is meer dan techniek 

Een belangrijke les uit dit traject is dat je afhankelijkheden tussen micro front-ends en de shell zoveel mogelijk moet beperken. Sommige zaken, zoals het framework, deel je bewust met elkaar. Maar hoe minder onderlinge koppelingen er zijn, hoe meer vrijheid teams hebben om zelfstandig keuzes te maken en releases uit te voeren. 

Ook tooling speelt daarin een belangrijke rol. Waar veel implementaties gebruikmaken van Module Federation, zou ik tegenwoordig eerder kijken naar Native Federation. Daarmee maak je jezelf minder afhankelijk van specifieke tooling en houd je meer flexibiliteit richting de toekomst. 

De gouden tip 

Micro front-ends lossen niet automatisch je problemen op. Kijk daarom niet alleen naar de technische architectuur, maar vooral naar de afhankelijkheden tussen teams. Hoe minder teams op elkaar hoeven te wachten, hoe groter de voordelen van een micro front-endarchitectuur worden. 

Of zoals ik het zelf heb geleerd: het opsplitsen van een applicatie is relatief eenvoudig. De kunst is om daarna niet per ongeluk dezelfde monoliet terug te bouwen, maar dan verdeeld over tien repositories.