GraphQL, de query taal om te spelen met API’s

Voordelen van GraphQL

Een van de grootste voordelen ten opzichte van traditionele REST calls is dan ook dat developers zelf de data in de response kunnen samenvoegen uit meerdere API calls op de Back-End waardoor er vanaf de Front-End maar één call nodig is naar een GraphQL tussenlaag.

Naast dit typische voordeel van data fetching heeft GraphQL nog meer voordelen. Ik zet alle voordelen op een rij:

• Data fetching
• Geen over/under fetching
• Complexe state and cache management (Apollo server)
• Hiërarchische structuur
• Gedefinieerd data model
• Strongly typed
• Schaalbaar
• Documentatie

Geen over / under fetching

Door het gebruik van GraphQL kunnen we op een gemakkelijke manier de architectuur bepalen van de data die we aanroepen vanaf de Front-End. Hierdoor ontstaat er geen over of under fetching: we vragen alleen de data op die we daadwerkelijk nodig hebben. Een voorbeeld: als we een profiel willen tonen met enkel een foto en een naam, hebben we van dat profiel niet de adresgegevens nodig. In de Front-End call naar GraphQL vragen we dan enkel de ID, naam en de foto op. Alle andere informatie van dit profiel kunnen we dan achterwege laten.

Per device (mobiel, tablet, desktop enz.) kunnen we een andere view hebben, welke meer of minder informatie weergeeft. De data kunnen we per view aanpassen zodat we nooit meer informatie opvragen dan nodig. Dit komt uiteraard de performance ten goede.

Complexe state and cache management

Door GraphQL te combineren met Apollo server, hebben we ook een complexe state en cache management tot onze beschikking. We kunnen het zo instellen, dat als de data zich al in de cache van de client bevindt, we deze data niet opnieuw opvragen.

Hiërarchische structuur

Doordat we meer controle krijgen en minder afhankelijk worden van een Back-End, kunnen we de data-architectuur op een hiërarchische structuur inrichten. Hierdoor is het ook mogelijk meerdere data-objecten te hergebruiken.

Facebook is hiervan een mooi voorbeeld: deze heeft één gebruikersobject, die kan worden hergebruikt voor de connecties van de gebruiker. Ook die heeft weer connecties waar het voor kan worden hergebruikt. Etc, etc. Mede door de herbruikbare objecten maken we efficiënt gebruik van GraphQL.

Nadelen van GraphQL

Uiteraard kleven er ook nadelen aan het gebruik van GraphQL. Dit zit hem voornamelijk in de complexiteit. Wanneer we GraphQL gaan inzetten en we gebruiken GraphQL enkel als een 1-op-1 doorgeefluik van data, dan zal het gebruik van een REST API hiervoor meer geschikt zijn en voorkomen we overbodige complexiteit in onze codebase.

Van query’s tot resolvers

In de basis bestaat GraphQL uit query’s, mutations, subscriptions en resolvers.

In de Front-End kunnen we een query, mutation of subscription uitvoeren naar GraphQL.

• Query: ophalen van data ( GET )
• Mutation: mutatie van de data, dat kan een POST, UPDATE of een DELETE zijn.
• Subscription: hiermee kunnen we een subscription instellen om de Front-End aan te passen wanneer er op de server wat verandert zonder dat er een actie is geweest vanuit de Front-End.

Om deze data op te halen, moeten we voor de query’s, mutations of subscriptions een resolver inrichten. Een resolver maakt de connectie en verwerkt de data van de externe API call of een database query. Het resultaat wordt door een query weer teruggestuurd naar de Front-End.

Als de query’s, mutations en resolvers zijn ingesteld, willen we deze ook kunnen testen zonder al te veel code te schrijven. In de console kunnen we de GraphQL server starten waarna de playground/sandbox tot onze beschikking komt.

Er zijn diverse playgrounds of sandboxes beschikbaar, van een lokale playground-versie tot aan een subscription op studio.apollographql.com of een browser extention zoals GraphQL Playground for Chrome. Uiteraard kan er ook een call gemaakt worden vanuit postman om de API te testen.

GraphQL community

GraphQL bestaat nu 7 jaar en weten we dat deze door de community wordt omarmd, mede doordat het niet enkel en alleen in JavaScript beschikbaar is, maar ook bijvoorbeeld in Python, Ruby en C#.

Als we kijken in GitHub naar de stars (likes) en downloads zien we voor de belangrijkste JavaScript varianten:

• GraphQL: 19K stars / 9.5k downloads p/w
• Apollo server: 13k stars / 1.6k downloads p/w
• Express GraphQL: 6k stars / 0.7 downloads p/w

Dit geeft uiteraard een beeld hoe het ontvangen wordt door de community, maar om een beter beeld te krijgen hebben ze in 2022 een survey gehouden: State of GraphQL 2022.

Wat zijn de highlights van de state of GraphQL 2022

Er hebben meer dan 3.000 developers meegedaan aan deze survey. Gemiddeld hadden de deelnemers 6 tot 10 jaar development-ervaring en bijna de helft werkt bij middelgrote tot grote bedrijven. Hieronder licht ik enkele vragen uit de survey uit, om een goed beeld te schetsen.

In welke combinatie met webframeworks wordt GraphQL het meeste gebruikt?

1. Next.js: 32,2%
2. React: 27,8%
3. Gatsby: 12,1%

Voor welke clients wordt een GraphQL het meeste ingezet?

1. Browsers: 62,3%
2. Native Mobile Apps: 24,2%
3. Other Servers: 16,3%

Welke taal wordt gebruikt om GraphQL-backends te schrijven?

1. TypeScript: 49,7%
2. Javascript: 34,7%
3. Go: 7,5%

Welke GraphQL server wordt het meest gebruikt?

1. Apollo server: 67,3%
2. GraphQL.js: 32,4%
3. Express-GraphQL: 27,7%

Welke GrapQL IDE’s worden het meeste gebruikt?

1. GraphQL: 39,4%
2. GraphQL Playground: 34,8%
3. Postman: 18%

Conclusie van de state of GraphQL

Quote: Als gevolg hiervan verandert het tij in de manier waarop we GraphQL op de client gebruiken, waarbij bibliotheken zoals urql en React Query tegenwoordig populaire keuzes zijn, naast getrouwen zoals Apollo Client en Relay. Het is ook geweldig om te zien dat GraphQL blijft groeien en bloeien in andere talen dan JavaScript – er zijn nu stabiele en volwassen GraphQL-servers en -clients in bijna alle populaire programmeertalen!

Wil je meer weten? Bekijk dan de hele survey op https://2022.stateofgraphql.com/

Uiteraard zou GraphQL, GraphQL niet zijn als ze de data van state of GraphQL niet openbaar beschikbaar stellen op https://graphiql.devographics.com/.

De toekomst van GraphQL

Naar verwachting neemt GraphQL steeds meer zijn eigen plek in het API landschap in. GraphQL heeft niet de intentie om ander servers zoals REST API te vervangen, maar het wordt ingezet vanuit de behoefte. In het geval van GraphQL is dat meer vanuit de gedachte ‘client first’ omdat we GraphQL vanuit onze Front-End gemakkelijker kunnen beheren. GraphQL heeft zijn oorsprong bij Meta (Facebook) en daarom zien we ook dat de aanhang onder Reactgebruikers hoog is. Ik verwacht wel dat GraphQL in de toekomst breder ingezet gaat worden in combinatie met Angular of Vue.

Wil je nou ook aan de slag met GraphQL en kan je daar hulp bij gebruiken? Laat het ons weten: mijn collega’s en ik helpen je graag!