Publish GraphQL blog series part 2

joostfarla · joostfarla · commit b9570958bb78 · 2026-07-30T15:19:52.000+02:00
diff --git a/.changeset/README.md b/.changeset/README.md
@@ -1,8 +1,11 @@
 # Changesets
 
-Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
-with multi-package repos, or single-package repos to help you version and publish your code. You can
-find the full documentation for it [in our repository](https://github.com/changesets/changesets).
+Hello and welcome! This folder has been automatically generated by
+`@changesets/cli`, a build tool that works with multi-package repos, or
+single-package repos to help you version and publish your code. You can find the
+full documentation for it
+[in our repository](https://github.com/changesets/changesets).
 
-We have a quick list of common questions to get you started engaging with this project in
+We have a quick list of common questions to get you started engaging with this
+project in
 [our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md).
diff --git a/.changeset/publish-graphql-deel-2.md b/.changeset/publish-graphql-deel-2.md
@@ -0,0 +1,5 @@
+---
+"@developer-overheid-nl/website": patch
+---
+
+Publish GraphQL blog series part 2
diff --git a/blog/2026/01/16-justid-start-met-api-expertiseteam.md b/blog/2026/01/16-justid-start-met-api-expertiseteam.md
@@ -12,16 +12,49 @@ description:
 
 ![Logo van Justid](./img/justid.png)
 
-Buiten de Rijksoverheid is het gebruik van (REST) APIs voor het ontsluiten van informatie al jaren gemeengoed. Binnen de Rijksoverheid en specifiek binnen [Justitie en Veiligheid](https://www.rijksoverheid.nl/ministeries/ministerie-van-justitie-en-veiligheid) neemt de inzet van (REST) API's de afgelopen jaren toe. Zo hebben we als [Justid](https://www.justid.nl) in 2024 de [Gouden API gewonnen voor onze CPA Register API](../../2024/12/11-gouden-api-award-voor-cpa-register-api.md) en in 2025 de Zilveren API voor de API van het Centraal Digitaal Depot (CDD+).
+Buiten de Rijksoverheid is het gebruik van (REST) APIs voor het ontsluiten van
+informatie al jaren gemeengoed. Binnen de Rijksoverheid en specifiek binnen
+[Justitie en Veiligheid](https://www.rijksoverheid.nl/ministeries/ministerie-van-justitie-en-veiligheid)
+neemt de inzet van (REST) API's de afgelopen jaren toe. Zo hebben we als
+[Justid](https://www.justid.nl) in 2024 de
+[Gouden API gewonnen voor onze CPA Register API](../../2024/12/11-gouden-api-award-voor-cpa-register-api.md)
+en in 2025 de Zilveren API voor de API van het Centraal Digitaal Depot (CDD+).
 
 <!-- truncate -->
 
-Binnen Justitie en Veiligheid hebben we met elkaar afgesproken om berichtuitwisseling via [JUBES](https://www.justid.nl/producten-en-dienstencatalogus/digitaal-uitwisselen/aansluiten-op-infrastructurele-systemen/aansluiten-op-jubes) (Justitie Berichten Service) te laten lopen. Ook op JUBES merken we de groei van (REST) API aansluitingen. Inmiddels is het merendeel van de nieuwe aansluitingen op JUBES een (REST) API aansluiting. Tegelijkertijd neemt ook het berichtenverkeer via ebMS nog steeds toe. ebMS is echter veel meer dan alleen een manier om informatie uit te wisselen. Zaken als zekerheid van berichtaflevering, betrouwbaarheid, berichtintegriteit en duidelijke afspraken over welke informatie wordt uitgewisseld, zijn ingebouwd in het ebMS protocol. Deze zaken zijn optioneel bij het gebruik van een (REST) API voor berichtuitwisseling.
-
-We krijgen binnen gegevensuitwisseling steeds vaker te maken met nieuwe applicaties die enkel nog informatie kunnen uitwisselen via een (REST) API of bestaande applicaties waarbij ondersteuning voor het ebMS protocol stopt. Daarnaast vraagt de inzet van (REST) API's meer aandacht voor zaken als autorisatie, authenticatie, schaalbaarheid en beheersbaarheid. Ook krijgen we vaker vragen zoals; hoe begin ik met het bouwen van een API en waar moet ik rekening mee houden?
-
-Daarom zijn we vanuit Justid (in opdracht van Directie Informatievoorziening en Inkoop) eind 2025 begonnen met een API-expertiseteam. Het API-expertiseteam bestaat uit collega's met expertise op het gebied van toegang, gegevensuitwisseling en semantiek. We werken daarbij ook samen met de collega's van het [Kennisplatform API's](../../../../communities/kennisplatform-apis).
-
-De ambities zijn onder andere om hier binnen Justitie en Veiligheid een voortrekkersrol te pakken, kennissessies te organiseren, vragen van ketenpartners te beantwoorden en te adviseren. Daarnaast zijn we bezig met opzetten van een API-expertiseportaal (met onder andere een beslisboom ebMS vs API, een F.A.Q en integratie van de reeds bestaande API-Catalogus Justitie en Veiligheid)
-
-Het API-expertiseteam is bereikbaar via [api-expertiseteam@justid.nl](mailto:api-expertiseteam@justid.nl).
+Binnen Justitie en Veiligheid hebben we met elkaar afgesproken om
+berichtuitwisseling via
+[JUBES](https://www.justid.nl/producten-en-dienstencatalogus/digitaal-uitwisselen/aansluiten-op-infrastructurele-systemen/aansluiten-op-jubes)
+(Justitie Berichten Service) te laten lopen. Ook op JUBES merken we de groei van
+(REST) API aansluitingen. Inmiddels is het merendeel van de nieuwe aansluitingen
+op JUBES een (REST) API aansluiting. Tegelijkertijd neemt ook het
+berichtenverkeer via ebMS nog steeds toe. ebMS is echter veel meer dan alleen
+een manier om informatie uit te wisselen. Zaken als zekerheid van
+berichtaflevering, betrouwbaarheid, berichtintegriteit en duidelijke afspraken
+over welke informatie wordt uitgewisseld, zijn ingebouwd in het ebMS protocol.
+Deze zaken zijn optioneel bij het gebruik van een (REST) API voor
+berichtuitwisseling.
+
+We krijgen binnen gegevensuitwisseling steeds vaker te maken met nieuwe
+applicaties die enkel nog informatie kunnen uitwisselen via een (REST) API of
+bestaande applicaties waarbij ondersteuning voor het ebMS protocol stopt.
+Daarnaast vraagt de inzet van (REST) API's meer aandacht voor zaken als
+autorisatie, authenticatie, schaalbaarheid en beheersbaarheid. Ook krijgen we
+vaker vragen zoals; hoe begin ik met het bouwen van een API en waar moet ik
+rekening mee houden?
+
+Daarom zijn we vanuit Justid (in opdracht van Directie Informatievoorziening en
+Inkoop) eind 2025 begonnen met een API-expertiseteam. Het API-expertiseteam
+bestaat uit collega's met expertise op het gebied van toegang,
+gegevensuitwisseling en semantiek. We werken daarbij ook samen met de collega's
+van het [Kennisplatform API's](../../../../communities/kennisplatform-apis).
+
+De ambities zijn onder andere om hier binnen Justitie en Veiligheid een
+voortrekkersrol te pakken, kennissessies te organiseren, vragen van
+ketenpartners te beantwoorden en te adviseren. Daarnaast zijn we bezig met
+opzetten van een API-expertiseportaal (met onder andere een beslisboom ebMS vs
+API, een F.A.Q en integratie van de reeds bestaande API-Catalogus Justitie en
+Veiligheid)
+
+Het API-expertiseteam is bereikbaar via
+[api-expertiseteam@justid.nl](mailto:api-expertiseteam@justid.nl).
diff --git a/blog/2026/02/11-oidc-voor-nederlanse-identiteitsdiensten.md b/blog/2026/02/11-oidc-voor-nederlanse-identiteitsdiensten.md
@@ -14,11 +14,11 @@ description: |
 Binnen de Nederlandse overheid zijn
 [DigiD](/kennisbank/security/authenticatie/digid),
 [eHerkenning](/kennisbank/security/authenticatie/eherkenning) en
-[eIDAS](/kennisbank/security/wetgeving-en-beleid/eidas) al jaren de ruggengraat van
-digitale identiteit en toegang. Ze zijn betrouwbaar, veilig, bewezen en breed
-ingezet door heel Nederland heen. Tegelijkertijd stoelen deze voorzieningen op
-een technische basis die steeds minder goed afgestemd is op hoe we vandaag
-digitale diensten bouwen: SAML 2.0.
+[eIDAS](/kennisbank/security/wetgeving-en-beleid/eidas) al jaren de ruggengraat
+van digitale identiteit en toegang. Ze zijn betrouwbaar, veilig, bewezen en
+breed ingezet door heel Nederland heen. Tegelijkertijd stoelen deze
+voorzieningen op een technische basis die steeds minder goed afgestemd is op hoe
+we vandaag digitale diensten bouwen: SAML 2.0.
 
 Eerlijk is eerlijk, SAML werkt. Het is veilig, veel klassieke webapplicaties
 zijn erop ingericht om het te ondersteunen en de techniek is door de experts
@@ -46,15 +46,15 @@ het API-first en kanaalonafhankelijk, in tegenstelling tot SAML welke echt
 browser-centrisch is; de wereld is dit echter niet meer. Daarnaast is de instap
 voor developers een stuk lager door de lichtgewicht aard van de berichtenstromen
 (JSON en REST i.p.v. XML, zie [OIDC](/kennisbank/security/authenticatie/oidc) en
-[SAML](/kennisbank/security/authenticatie/saml)) en de bekendheid van de techniek
-over de gehele wereld. Het is ook flexibel en toekomstvast; door OIDC flows als
-Authorization Code (met PKCE) voor web en apps en Device Code voor beperkte
-apparaten is OIDC veilig in te zetten voor vele gebruiksscenario’s, zonder
-protocoluitbreidingen of workarounds. Tot slot is er een sterkere aansluiting
-mogelijk op basis van “zero trust”, omdat elke aparte request in OIDC expliciet
-geautoriseerd is, tokens context afhankelijk en slechts van korte duur zijn, en
-er minder afhankelijkheid is van sessies. SAML is daar nooit voor ontworpen,
-OIDC wel.
+[SAML](/kennisbank/security/authenticatie/saml)) en de bekendheid van de
+techniek over de gehele wereld. Het is ook flexibel en toekomstvast; door OIDC
+flows als Authorization Code (met PKCE) voor web en apps en Device Code voor
+beperkte apparaten is OIDC veilig in te zetten voor vele gebruiksscenario’s,
+zonder protocoluitbreidingen of workarounds. Tot slot is er een sterkere
+aansluiting mogelijk op basis van “zero trust”, omdat elke aparte request in
+OIDC expliciet geautoriseerd is, tokens context afhankelijk en slechts van korte
+duur zijn, en er minder afhankelijkheid is van sessies. SAML is daar nooit voor
+ontworpen, OIDC wel.
 
 ## Voordelen van SAML
 
diff --git a/blog/2026/03/25-skills.md b/blog/2026/03/25-skills.md
@@ -67,9 +67,10 @@ DMARC- en DKIM-richtlijnen erbij. Je hoeft als developer niet eens te weten dat
 een bepaalde standaard bestaat.
 
 Meerdere skills vormen samen een plugin, en plugins zijn vindbaar via een
-marketplace. Het "Agent Skills" formaat is een [open standaard](https://agentskills.io/home)
-die inmiddels door meer dan dertig tools wordt ondersteund, waaronder Claude
-Code, Opencode, Cursor, GitHub Copilot en Gemini CLI.
+marketplace. Het "Agent Skills" formaat is een
+[open standaard](https://agentskills.io/home) die inmiddels door meer dan dertig
+tools wordt ondersteund, waaronder Claude Code, Opencode, Cursor, GitHub Copilot
+en Gemini CLI.
 
 ```mermaid
 flowchart TD
@@ -92,7 +93,9 @@ een opzet. Zonder skill krijg je een generieke API die niet voldoet aan de
 van Logius. Endpoints in camelCase in plaats van kebab-case, foutmeldingen als
 vrije tekst in plaats van `problem+json`, geen versienummer in het pad.
 
-Met de [`/ls-api`](https://github.com/developer-overheid-nl/skills-standaarden/blob/main/skills/ls-api/SKILL.md) skill zit dat er anders uit:
+Met de
+[`/ls-api`](https://github.com/developer-overheid-nl/skills-standaarden/blob/main/skills/ls-api/SKILL.md)
+skill zit dat er anders uit:
 
 **Prompt:**
 
diff --git a/blog/2026/04/24-we-gaan-samen-code-overheid-bouwen.md b/blog/2026/04/24-we-gaan-samen-code-overheid-bouwen.md
@@ -12,10 +12,11 @@ tags:
 # We gaan samen code.overheid.nl bouwen
 
 24 april was ik bij de softlaunch van code.overheid.nl. Het is een project dat
-bij veel developers en organisaties aanslaat omdat elke developer een gitomgeving nodig
-heeft om überhaupt samen te kunnen werken. Sinds er veel aandacht uit gaat naar
-digitale soevereiniteit is de roep om een gezamenlijke gitomgeving alleen maar
-gegroeid, het werd steeds minder voordehandliggend om op Github te blijven.
+bij veel developers en organisaties aanslaat omdat elke developer een
+gitomgeving nodig heeft om überhaupt samen te kunnen werken. Sinds er veel
+aandacht uit gaat naar digitale soevereiniteit is de roep om een gezamenlijke
+gitomgeving alleen maar gegroeid, het werd steeds minder voordehandliggend om op
+Github te blijven.
 
 Vanuit dit besef heeft OSPO BZK zich hard gemaakt voor de opzet van
 code.overheid.nl, in de vorm van een Forgejo instance.
diff --git a/blog/2026/06/05-asyncapi-2-use-cases.md b/blog/2026/06/05-asyncapi-2-use-cases.md
@@ -12,7 +12,9 @@ description: |
 
 # AsyncAPI: Wanneer wel? Wanneer niet?
 
-In een [eerdere blogpost](https://developer.overheid.nl/blog/2026/05/28/asyncapi-1-tot-nu-toe) zijn de eerste bevindingen van de werkgroep
+In een
+[eerdere blogpost](https://developer.overheid.nl/blog/2026/05/28/asyncapi-1-tot-nu-toe)
+zijn de eerste bevindingen van de werkgroep
 [AsyncAPI](https://www.asyncapi.com/en) gedeeld na het uitwerken van een tweetal
 use cases waarin asynchrone API’s van [OAS](https://www.openapis.org/) naar
 AsyncAPI werden omgezet. Daarbij werd duidelijk dat AsyncAPI op zichzelf geen
diff --git a/blog/2026/06/23-meetup-juni.md b/blog/2026/06/23-meetup-juni.md
@@ -73,8 +73,7 @@ en de
 <br/>
 <br/>
 
-!["Foto van het koffiemoment."](./img/pauze.jpg)
-_Foto van het koffiemoment._
+!["Foto van het koffiemoment."](./img/pauze.jpg) _Foto van het koffiemoment._
 
 ### Johan Groenen: code.overheid.nl
 
@@ -98,8 +97,8 @@ ontstaan bij VWS tijdens de coronacrisis en inmiddels gedragen door een actieve
 community. Met slimme plugins, de zogenoemde boefjes, breng je het
 aanvalsoppervlak van je organisatie feitelijk en forensisch geborgd in kaart.
 
-!["Jan Klopper tijdens zijn praatje over OpenKAT"](./img/jan.jpg)
-_Jan Klopper tijdens zijn praatje over OpenKAT._
+!["Jan Klopper tijdens zijn praatje over OpenKAT"](./img/jan.jpg) _Jan Klopper
+tijdens zijn praatje over OpenKAT._
 
 <Link href="https://openkat.nl/">
   Meer over OpenKAT
diff --git a/blog/2026/06/30-asyncapi-3-implementatie-met-cloudevents.md b/blog/2026/06/30-asyncapi-3-implementatie-met-cloudevents.md
@@ -25,22 +25,21 @@ uitgewisseld tussen systemen?
 
 <!-- truncate -->
 
-
 :::success[TL;DR]
 
-Na een wat theoretische behandeling van AsyncAPI is het tijd om naar de toekomst 
-te kijken. Cloudevents, een aangenomen standaard binnen de Nederlandse Overheid, 
-vult AsyncAPI aan in het beschrijven van events en het implementeren van Event Driven
-Architecture. Het doet dit door concreet in te vullen hoe asynchrone berichten eruit 
-zien, waar AsyncAPI alleen beschrijft wat voor soort berichten er verstuurd worden 
-en waar dat verkeer leeft. Met Cloudevents en AsyncAPI samen volgt er documentatie
-waar vervolgens met gemak op te ontwikkelen en implementeren valt. De werkgroep 
-AsyncAPI gaat zich richten op dit alles verder uitwerken; wie mee wil doen met de 
-discussie is meer dan welkom om aan te schuiven!
+Na een wat theoretische behandeling van AsyncAPI is het tijd om naar de toekomst
+te kijken. Cloudevents, een aangenomen standaard binnen de Nederlandse Overheid,
+vult AsyncAPI aan in het beschrijven van events en het implementeren van Event
+Driven Architecture. Het doet dit door concreet in te vullen hoe asynchrone
+berichten eruit zien, waar AsyncAPI alleen beschrijft wat voor soort berichten
+er verstuurd worden en waar dat verkeer leeft. Met Cloudevents en AsyncAPI samen
+volgt er documentatie waar vervolgens met gemak op te ontwikkelen en
+implementeren valt. De werkgroep AsyncAPI gaat zich richten op dit alles verder
+uitwerken; wie mee wil doen met de discussie is meer dan welkom om aan te
+schuiven!
 
 :::
 
-
 ## CloudEvents
 
 Waar AsyncAPI zich richt op het beschrijven van berichtenstromen, biedt het niet
diff --git a/blog/2026/07/1-cio-dag.md b/blog/2026/07/1-cio-dag.md
@@ -32,12 +32,12 @@ een voor een kwamen de uitdaging waar wij als land voor aan de lat staan naar
 voren. De groei van AI, en de uitwerking daarvan. De Cloud strategie, Digitale
 souvereiniteit, en veiligheid. Allemaal vragen waar het antwoord elke keer
 eenduidig was: Samen. Samen werken, samen doen en samen ontwikkelen. Dit werd
-ook beaamt door de `vreemde aap' in het gezelschap. Gedragswetenschapper
-Patrick van Veen welke het gedrag van door hem onderzochte apen als spiegel voor
-de aanwezigen hield om hen zo te laten zien wat 'samen werken' precies kan
+ook beaamt door de `vreemde aap' in het gezelschap. Gedragswetenschapper Patrick
+van Veen welke het gedrag van door hem onderzochte apen als spiegel voor de
+aanwezigen hield om hen zo te laten zien wat 'samen werken' precies kan
 betekenen.
 
-##  Druk bezochte talks, lege gangen.
+## Druk bezochte talks, lege gangen.
 
 Een van de dingen die opviel (in tegenstelling tot andere grotere events) is dat
 de wandelgangen en koffiehoekjes volstrekt uitgestorven waren tijdens de talks.
diff --git a/blog/2026/07/30-graphql-1-introductie.md b/blog/2026/07/30-graphql-1-introductie.md
@@ -256,15 +256,15 @@ caching, autorisatie en beheersing van de belasting.
 
 ## De rest van deze serie
 
-<!-- TODO: bij publicatie van deel 2, 3 en 4 hier telkens de link naar het
-verschenen deel toevoegen -->
+<!-- TODO: bij publicatie van deel 3 en 4 hier de link naar het verschenen
+deel toevoegen -->
 
 In de komende delen gaan we de diepte in:
 
-- **Deel 2** behandelt de kernbelofte van GraphQL (flexibel bevragen als
-  oplossing voor over- en underfetching) en de prijs die daar tegenover staat:
-  onvoorspelbare performance en een groter aanvalsoppervlak, en hoe je daar
-  limieten aan stelt.
+- **[Deel 2](/blog/2026/08/05/graphql-2-flexibiliteit-en-limieten)** behandelt
+  de kernbelofte van GraphQL (flexibel bevragen als oplossing voor over- en
+  underfetching) en de prijs die daar tegenover staat: onvoorspelbare
+  performance en een groter aanvalsoppervlak, en hoe je daar limieten aan stelt.
 - **Deel 3** duikt in de praktijk van schema-ontwerp: paginering, filtering,
   union types, custom scalars, autorisatie en content negotiation.
 - **Deel 4** brengt alles samen in een afwegingskader: wanneer is GraphQL een
diff --git a/blog/2026/08/05-graphql-2-flexibiliteit-en-limieten.md b/blog/2026/08/05-graphql-2-flexibiliteit-en-limieten.md
@@ -1,5 +1,5 @@
 ---
-draft: true
+
 authors: [joost-farla]
 tags:
   [
diff --git a/blog/draft/graphql-3-schema-ontwerp.md b/blog/draft/graphql-3-schema-ontwerp.md
@@ -16,26 +16,25 @@ description: |
 
 ![GraphQL onder de loep](/img/graphql-onder-de-loep.jpg)
 
-In [deel 2](/blog/draft/graphql-2-flexibiliteit-en-limieten) <!-- TODO: link
-bijwerken na publicatie --> 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 [deel 2](/blog/2026/08/05/graphql-2-flexibiliteit-en-limieten) 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.
 
 <!-- truncate -->
 
-<!-- TODO bij publicatie: link van deel 2 omzetten naar de definitieve URL;
-deel 4 linken zodra dat deel verschenen is -->
+<!-- TODO bij publicatie: deel 4 linken zodra dat deel verschenen is -->
 
 :::info[GraphQL onder de loep]
 
 Dit artikel is deel 3 van een vierdelige serie:
 
 1. [Een kennismaking](/blog/2026/07/30/graphql-1-introductie)
-2. [Flexibel bevragen, en wat dat kost](/blog/draft/graphql-2-flexibiliteit-en-limieten)
+2. [Flexibel bevragen, en wat dat kost](/blog/2026/08/05/graphql-2-flexibiliteit-en-limieten)
 3. Zes uitdagingen bij schema-ontwerp (dit deel)
 4. Wanneer wel, en wanneer niet? (volgt)
 
diff --git a/blog/draft/graphql-4-afwegingskader.md b/blog/draft/graphql-4-afwegingskader.md

-Original file line number
+Diff line change
@@ @@ -0,0 +1,5 @@ @@
 +---
 +"@developer-overheid-nl/website": patch
 +---
++
 +Publish GraphQL blog series part 2