API Ontwerp
Het Einde van Over- en Under-fetching
In de afgelopen tien jaar is REST (Representational State Transfer) de de-facto standaard geweest voor het ontwerpen van web-API’s. REST werkt op basis van vaste endpoints (bijv. /users/123) waarbij elk endpoint een vaste structuur aan data teruggeeft. Hoewel dit concept simpel en schaalbaar is, loopt het in moderne applicaties — waar data vanuit meerdere bronnen moet worden samengevoegd voor complexe user interfaces — snel tegen zijn grenzen aan. Ontwikkelaars kampen dagelijks met ‘over-fetching’ (te veel overbodige data ophalen) en ‘under-fetching’ (te weinig data ophalen, waardoor er extra netwerk-calls nodig zijn naar andere endpoints zoals /users/123/posts).
In 2015 introduceerde Facebook een elegante oplossing voor dit probleem: GraphQL. In plaats van meerdere starre endpoints aan te spreken, biedt GraphQL één enkel, flexibel endpoint. De client (frontend) stuurt een query waarin het exact beschrijft welke datavelden het nodig heeft, en de server retourneert uitsluitend en exact die gevraagde data.
De Architectuur van GraphQL: Typen, Query’s en Resolvers
De kern van GraphQL is het Schema. Het schema, geschreven in de Schema Definition Language (SDL), fungeert als een bindend contract tussen de frontend en de backend. Het definieert exact welke objecten (Types) beschikbaar zijn, welke velden ze hebben en hoe ze aan elkaar gerelateerd zijn. Omdat GraphQL sterk getypeerd is, kunnen ontwikkelaars automatisch documentatie genereren en profiteren van auto-aanvulling (IntelliSense) in hun code-editors.
Aan de backend wordt het zware werk gedaan door ‘Resolvers’. Voor elk veld in de query schrijft de backend-developer een resolver-functie die verantwoordelijk is voor het ophalen van de data uit de onderliggende bronnen (SQL-databases, NoSQL-databases, externe API’s of microservices). Dit betekent dat GraphQL fungeert als een abstractielaag (een API Gateway) die de complexiteit van de backend-infrastructuur volledig verbergt voor de frontend-developer.
Het N+1 Probleem en Dataloaders
Ondanks de voordelen introduceert GraphQL zijn eigen technische uitdagingen, waarvan het ‘N+1 probleem’ de beruchtste is. Omdat resolvers op veldniveau worden uitgevoerd, kan een query die een lijst van 100 artikelen opvraagt, samen met de naam van de auteur van elk artikel, resulteren in 1 initiële database-query voor de artikelen, gevolgd door 100 afzonderlijke query’s voor de auteurs (N+1). Dit belast de database enorm en vernietigt de performance.
Enterprise-omgevingen lossen dit op door ‘Dataloaders’ te implementeren. Een Dataloader is een utility die in de backend draait en binnenkomende requests gedurende een paar milliseconden verzamelt (batching), om ze vervolgens als één grote, geoptimaliseerde IN-query (bijv. SELECT * FROM users WHERE id IN (1, 2, 3...)) naar de database te sturen. Bovendien zorgt de Dataloader voor caching binnen één request, zodat dezelfde auteur nooit twee keer wordt opgehaald.
Beveiliging en Caching Uitdagingen
GraphQL is ongekend krachtig, maar met grote kracht komt grote verantwoordelijkheid. Omdat de client de structuur van de query bepaalt, kan een kwaadwillende gebruiker een oneindig diep geneste query sturen (bijv. Auteur -> Artikel -> Commentaar -> Auteur -> Artikel...) in een poging de server te laten crashen (DDoS). Ontwikkelaars moeten beveiligingsmaatregelen treffen zoals Query Depth Limiting en Query Cost Analysis om te voorkomen dat zware queries de server overbelasten.
Daarnaast is HTTP-caching (via CDN’s) bij GraphQL lastiger dan bij REST, omdat alle requests als POST-berichten naar hetzelfde endpoint worden gestuurd. Tools zoals Apollo Server bieden hiervoor geavanceerde oplossingen zoals ‘Persisted Queries’, waarbij de client slechts een hash van de query verstuurt. GraphQL is geen magische kogel die REST overbodig maakt, maar voor data-intensieve frontend-applicaties biedt het een ongeëvenaarde ontwikkelervaring. Ontdek de mogelijkheden van geavanceerde API’s op Frankwatching.
Serverless Architecturen en Edge Computing: Voorbij de Koude Start
