Hoe mock service workers frontend en backend developers vlot laten samenwerken

Het Nederlandse netwerkbedrijf Alliander heeft miljoenen klanten die dagelijks op de organisatie vertrouwen om stroom binnen te krijgen. De technici van Qirion, een joint-venture die ze samen met de netbeheerder TenneT lanceerden, spelen daarin een cruciale rol. Om die technische experts te ondersteunen, ontwikkelde Qirion software waarmee ze het onderhoud en de bouw van de stations op het netwerk kunnen opvolgen.

‘Met die applicaties kunnen technici assets beheren tot op het diepste niveau’, zegt Thomas Brok. Als consultant van Axxes werkt hij aan het softwareproject bij Qirion, waarvan de code aanzienlijk verouderd was. ‘We hebben alles opnieuw gebouwd zodat de technici ook de komende jaren kunnen monitoren waar er bijvoorbeeld storingen op het netwerk zijn.’

Een virtuele backend

Net zoals in vrijwel ieder softwareteam heeft Thomas collega’s die op de backend en frontend werken, maar de samenwerking tussen de twee is niet altijd zo eenvoudig. Frontend developers kunnen pas iets ontwikkelen als de bijbehorende backend beschikbaar is. Wanneer die backend nog niet klaar is, onverwacht wijzigt of wegvalt kunnen de frontend developers niet verder met hun werk.

‘Om die afhankelijkheid tussen de frontend en backend terug te dringen, zijn we op mijn initiatief met mock service workers gaan werken’, zegt Thomas. Dat is een API mocking library die ontwikkelaars gebruiken om netwerkverzoeken te simuleren tijdens de ontwikkeling en het testen van webapplicaties. Je gaat, met andere woorden, je backend nabootsen in je browser.

‘Het doel van een service worker is om uitgaande HTTP-requests op te vangen. Die kijkt of er iets mee moet gebeuren of niet, en beantwoordt ze in de browser. In theorie zou je zo je hele backend kunnen nabootsen en je frontend offline ontwikkelen. Zo kunnen we testen hoe onze applicatie omgaat met verschillende API-responses, zoals succesvolle antwoorden, fouten of vertragingen’, vertelt Thomas.

De ideale manier om te testen

Door gebruik te maken van een mock service worker kunnen ontwikkelaars ook precies bepalen welke antwoorden ze van de API willen ontvangen, wat helpt bij het testen van specifieke scenario's en het debuggen van problemen. ‘In essentie moet je in je code zeggen dat de service worker gestart moet worden, en geef je in de request handlers alle definities mee van wat er moet gebeuren. Bij Alliander werken we met GraphQL en kunnen we specificeren wat we exact nodig hebben in de query die we sturen. De service worker zorgt ervoor dat de mapping van de velden nadien automatisch gebeurt’, klinkt het.

Het gebruik van mock service workers is niet gebonden aan een library of framework, de enige voorwaarde is dat er een JavaScript runtime is. Het kan dus zowel door de JavaScript-engine van een browser als door Node.js worden gebruikt. Bij Qirion werkt men ook met GraphQL Codegen, waarmee je TypeScript types kunt genereren op basis van GraphQL queries. Die documenten die daaruit voortkomen kun je ook meegeven met de mock service worker. Thomas: ‘Binnen een sprint kun je voortaan écht met fullstack stories werken, want je frontend en backend developers kunnen naast elkaar aan de slag gaan. We werken sneller en de kans op fouten is kleiner.’

Alles of niets

Doordat het project bij Qirion van een leeg blad begon, kon men vanuit een ideaal scenario met mock service workers aan de slag gaan. ‘Ons GraphQL schema is leidend en bevat altijd de waarheid. Sowieso is het best om de frontend en backend niet deels, maar volledig te ontkoppelen. Je moet het volledig integreren in je werkwijze, en niet een beetje, want dan haal je er niet het maximale voordeel uit.’