Ontwikkelaarsportaal van de Nederlandse overheid
Kees Keulemans, kwartiermakersteam Nederlandse Digitale Dienst
Lang wisten we weinig over de Nederlandse Digitale Dienst (NLDD). Het bleef een in nevelen gehuld initiatief waarvan de verwachtingen hoog gespannen waren. Gelukkig waren wij aanwezig bij de meetup van Digilab in Utrecht, waar Kees Keulemans meer vertelde over waar het team nu staat, en hoe het van plan is te opereren.
Van een aanvraag voor een bouwvergunning tot de kaarten in je navigatiesysteem. De Basisregistratie Adressen en Gebouwen (BAG) is een enorme publieke gegevensbron die dagelijks meer dan tien miljoen keer wordt geraadpleegd. Dit gebeurt onder andere via de BAG-API van het Kadaster, inmiddels een van de meest gebruikte API's in het overheidsdomein.
In de eerste drie delen van deze serie hebben we GraphQL leren kennen als een getypeerde querytaal met een fundamenteel ander model dan REST (deel 1), zagen we dat de flexibele bevraging zowel de grote kracht als een serieuze beheeropgave is (deel 2) en liepen we zes ontwerpuitdagingen langs die in de praktijk bepalen hoeveel werk een GraphQL-API werkelijk kost (deel 3).
In dit slotdeel komen we bij de vraag waar het allemaal om draait: wanneer is GraphQL een passende keuze, en wanneer ben je met REST beter af? Er zijn omstandigheden waarin het ene model aantoonbaar beter past dan het andere.
Je bouwt aan een nieuwe applicatie, koppelt systemen via API's of werkt aan een voorziening voor de overheid. En ergens onderweg komt de vraag langs: welke open standaarden moet ik hier nu eigenlijk toepassen? Ze zijn niet vrijblijvend. Voor publieke organisaties zorgen open standaarden voor interoperabiliteit, leveranciersonafhankelijkheid, veiligheid, datakwaliteit en toegankelijkheid. Precies de dingen die bepalen of jouw software straks soepel samenwerkt met de rest van het overheidslandschap.
In deel 2 zagen we dat de flexibiliteit van GraphQL een beheeropgave met zich meebrengt. In dit deel kijken we naar de ontwerpkant. De rode draad: veel zaken die je in REST oplost met mechanismen van HTTP (headers, statuscodes, media types, middleware op routes) moeten in GraphQL expliciet gemodelleerd worden in het schema en de resolvers. Dat maakt schema's en queries complexer dan de voorbeelden uit deel 1 doen vermoeden. We behandelen zes uitdagingen die je in vrijwel elk GraphQL-project van enige omvang tegenkomt.
In het eerste deel van deze serie maakten we kennis met GraphQL: een getypeerde querytaal waarmee de client exact bepaalt welke data hij ontvangt. Die flexibiliteit is de belangrijkste reden om voor GraphQL te kiezen. In dit deel zetten we eerst de voordelen op een rij en kijken we daarna naar de keerzijde: wat betekent het voor de performance en beschikbaarheid van je API als elke client willekeurige queries kan samenstellen? En vooral: hoe stel je daar grenzen aan?
Spectral is een open source linter waarmee je regels voor API-documentatie vastlegt in een ruleset en die vervolgens automatisch controleert. Die tool ligt onder vuur. Er staan honderden issues en pull requests open, de VS Code-plugin loopt achter, en half juli kwam daar een supply chain-incident in een van de dependencies bovenop. Dat laatste was voor veel mensen de druppel. Omdat onze eigen tooling op Spectral draait en de API Design Rules ermee beschreven zijn, uitten veel mensen daar terecht hun zorgen over. Ons antwoord: we slopen Spectral er niet halsoverkop uit, want er zit juist beweging in de richting die we toch al op wilden. Hieronder leggen we uit waar we staan en wat we doen.
In gesprekken over API's binnen de overheid komt GraphQL regelmatig voorbij. Sommige organisaties experimenteren ermee, grote internationale platformen zoals GitHub en Shopify bieden er publieke API's mee aan, en tegelijkertijd is het binnen de Nederlandse overheid nog nauwelijks zichtbaar: het API-register op deze site is bewust REST-only, en de REST API Design Rules (ADR) zijn, de naam zegt het al, geschreven voor REST.
Reden genoeg om GraphQL eens grondig onder de loep te nemen. In een serie van vier blogposts verkennen we wat GraphQL is, wat het oplost, welke uitdagingen het met zich meebrengt en, als kernvraag, wanneer je het wel en wanneer je het beter niet kunt gebruiken.
Een goede API begint niet bij de controller, maar bij het contract. In de Bouw een API-tutorial laten we zien hoe je vanuit een gevalideerde OpenAPI Specification servercode genereert. Tot nu toe lag de nadruk daar vooral op een Express-template als demonstratie. Inmiddels hebben we de template-repository uitgebreid met meer runtimes en programmeertalen.
Dat klinkt misschien als een kleine toolingstap, maar het raakt een praktisch probleem dat veel teams herkennen: hoe kom je van een nette OAS naar een applicatie die dezelfde afspraken ook echt afdwingt?
"Human in the loop" is inmiddels het standaardantwoord op bijna elke zorg rond AI. Maar voor wie AI inzet om overheidssoftware te bouwen, is het verstandig om naast de mens ook tools in de loop houden: generators die het zware werk doen en validators die de regels bewaken. Zo verschuift het naleven van standaarden van de oplettendheid van een mens en de welwillendheid van AI naar tooling die je kunt vertrouwen. Hoe dat samenwerkt, en aan welk arsenaal aan skills, generators, validators en andere tools we werken, lees je in deze post.