developer.overheid.nl

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.

Om maar in de zelfde stroming te blijven als de Pitch voor het event zelf: Er staat een nieuwe wind in het digitale landschap. Een wind aangewakkerd door internationale incidenten, uitspraken, maar toch ook door een kritische blik op 'hoe zijn we hier gekomen'. Digitale souvereiniteit is de veilige haven waar we op koersen, en de vloot is ondertussen onomkeerbaar in beweging gekomen.

In de voorgaande blogposts hebben we gekeken naar wat AsyncAPI is, hoe het zich in de praktijk gedraagt en in welke situaties het daadwerkelijk waarde toevoegt (of juist niet). Daarmee staat er een grove leidraad voor wanneer AsyncAPI te implementeren, en is de kernvraag van de werkgroep in zekere mate beantwoord. Dit is natuurlijk niet voldoende. Los van dat de kernvraag van de werkgroep nog een lopende discussie is lijkt het logische vervolg om te gaan kijken naar hoe dit alles daadwerkelijk geïmplementeerd kan/moet worden. In deze blogpost heb ik gepoogd om vast een stukje vooruit te kijken, met als kern de vraag: hoe zorg je ervoor dat events niet alleen goed beschreven zijn, maar ook consistent en interoperabel worden uitgewisseld tussen systemen?

Hij zit er weer op, de tweede editie van onze meetup! Wat een mooie middag: een volle zaal met developers, scherpe vragen, goede gesprekken en ook nog een gezellige borrel bij Ruig achteraf. Graag delen we een korte terugblik met je van de sessies.

Frank Terpstra opende de API-track plenair.

Op 9 en 10 juni stonden wij twee dagen op FOST Amsterdam met onze eigen NL Gov-track. FOST (Future of Software Technologies) begon ooit als de wereldbekende API Days-conferentie, maar groeide uit tot een wereldwijd paraplu-event waaronder verschillende miniconferenties vallen; oprichter Mehdi Medjaoui maakte gekscherend de vergelijking van monoliet naar microservices. Naast API Days zelf vallen daar onder meer de conferenties van OpenAPI, JSON Schema, AsyncAPI, Green IO en deze editie dus ook wijzelf onder. Ons goedbezochte event bestond uit twee onderdelen: een API-track en een open source-track. Van ons eigen developer.overheid.nl-team betraden Dimitri, Tom, Frank, Floris en Joost het podium, samen met andere collega's uit binnen- en buitenland. Een terugblik op twee inspirerende dagen.

In een eerdere blogpost zijn de eerste bevindingen van de werkgroep AsyncAPI gedeeld na het uitwerken van een tweetal use cases waarin asynchrone API’s van OAS naar AsyncAPI werden omgezet. Daarbij werd duidelijk dat AsyncAPI op zichzelf geen wondermiddel is, maar vooral een krachtig instrument dat helpt om asynchrone communicatie inzichtelijk en beheersbaar te maken. De overkoepelende vraag is nog echter niet behandeld: wanneer gaan we het dan wel, en wanneer niet gebruiken? In deze blog ga ik dieper in op de situaties waarin AsyncAPI wel geschikt lijkt, en in welke situaties het van weinig toegevoegde waarde lijkt te zijn.