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.

Standaarden zijn vaak technisch van aard. Ze zorgen voor interoperabele oplossingen die technisch op elkaar kunnen aansluiten. Als we kijken naar adoptie van standaarden, dan is dat vaak een soft verhaal: "Wat heb ik hieraan?", "Is het verplicht?", "Doen anderen het ook?". Dit soort vragen worden door verschillende persona's gesteld en elke persona vereist een andere aanpak om te overtuigen van het nut van een standaard.

Bij het bevorderen van adoptie van standaarden is het van groot belang dat de softe kant op orde is. De keuze om een standaard te implementeren heeft een grotere impact als een bestuurder die maakt, dan één individuele developer. Zelf doe ik mee aan de werkgroep "Adoptie van standaarden" binnen het Federatief Datastelsel (FDS), om te analyseren welke activiteiten nuttig zijn om adoptie te bevorderen.