De kracht van GraphQL: waarom we toch vaak voor deze technologie kiezen

Als ontwikkelaars staan we voortdurend voor de uitdaging om de beste technologieën te kiezen die passen bij onze projecten. In dit blogartikel willen we graag de redenen delen waarom we er bij onze projecten vaak voor kiezen om GraphQL te gebruiken. Ondanks dat er regelmatig nadelen van GraphQL worden belicht, zijn er verschillende factoren die ons overtuigen om deze technologie (met grote regelmaat) te omarmen. Als je nou geen flauw idee hebt wat GraphQL precies is, hier vind je wat algemene informatie.

We zien de laatste tijd steeds vaker dat de nadelen van GraphQL benadrukt worden en dat zien we eigenlijk ook wel als een goed iets. Bij technieken die je gebruikt is het altijd verstandig om je te bedenken of het een of ander ook echt de beste oplossing is voor een probleem.

Een van die nadelen die vaak benoemd wordt is versiebeheer (versioning). In principe draai je 1 versie van GraphQL, waar het bij andere API’s (bijvoorbeeld op basis van REST) mogelijk is om meerdere versies te hebben. Dit kan voornamelijk problemen geven bij mobiele applicaties waarbij het nog maar de vraag is of alle gebruikers regelmatig hun apps updaten (en je dus zeker wilt weten dat een oudere versie blijft werken). Echter, aangezien de API's van onze projecten meestal niet gericht zijn op publiek gebruik, of voornamelijk bestaan uit webapplicaties, hebben we significant minder last van dit nadeel. Bovendien maakt het continuous development van deze webapplicaties een stuk eenvoudiger.

Een ander nadeel dat vaak genoemd wordt, is dat GraphQL te veel informatie kan vrijgeven (te veel exposen). Als je niet goed nadenkt over je database architectuur en configuratie van GraphQL kan het zomaar zijn dat er te veel informatie vanuit de database wordt meegegeven en gevoelige informatie ineens op straat ligt. Uiteraard zijn we ons bewust van het belang van die juiste configuratie. Wat ook nog meehelpt, is dat we veelal werken aan intern geauthenticeerde applicaties. Dan is informatie op een eerder niveau al uitgebreid beschermd, nog voordat er een query uitgevoerd wordt.

Naast de genoemde nadelen heeft GraphQL ook grote voordelen die ons overtuigen om voor deze techniek te kiezen. Allereerst biedt GraphQL een eenvoudige manier om typen te definiëren, wat enorm helpt bij het behouden van een consistente datastructuur en het minimaliseren van fouten. Daarnaast heeft GraphQL een robuust ecosysteem met populaire tools zoals NestJS, Apollo, Codegen en React, waardoor we een enorme bibliotheek van oplossingen hebben om uit te kiezen bij het ontwikkelen. Dit maakt het gemakkelijk om te integreren en efficiënter te werken. Tot slot waarderen we de flexibiliteit die GraphQL biedt bij het scheiden van de backend en frontend, terwijl beide wel in één monorepo zitten. Hierdoor kunnen teams onafhankelijk en parallel werken en kunnen we wijzigingen in beide lagen gelijktijdig coördineren.

Ondanks de nadelen die vaak worden besproken, zijn er diverse redenen waarom we vaak voor GraphQL kiezen bij onze projecten. Het minimaliseren van versiebeheer, de voordelen van eenvoudig typen en een flexibele backend/frontend scheiding zijn allemaal factoren die ons overtuigen van de kracht van GraphQL als technologische keuze voor veel van onze projecten. Uiteraard is elk project anders en is GraphQL voor sommige projecten minder geschikt, maar tot nu toe zijn we fan!