Het is een bekend probleem binnen de technologiebranche: hoe kun je data op de meest efficiënte manier verplaatsen van de ene naar de andere locatie? Het is een uitdaging die de sector al jaren probeert op te lossen. En inderdaad: netwerken zijn veel sneller geworden en we kunnen data dus veel sneller door digitale buizen duwen. Ook gebruiken we meer mobiele data dan ooit. Mobiele netwerken zijn ook beter dan ze ooit waren, waarbij we wel moeten beseffen dat er dagelijks een groot aantal nieuwe mobiele devices bijkomt.
Van REST naar GraphQL
In de afgelopen jaren zijn er technologieën gelanceerd die beloofden dat ze efficiënter en gebruiksvriendelijker zouden zijn dan hun voorgangers. Ik zal je niet vermoeien met de geschiedenis van datatransferprotocollen, maar vandaag de dag draait het vaak om REST of REpresentational State Transfer.
REST is steeds populairder geworden en dat ging ten koste van een andere, op dat moment minstens zo populaire technologie: SOAP. Waarom? Omdat REST enkel voordelen biedt ten opzichte van SOAP. Het is in het algemeen iets gebruiksvriendelijker en gebruikt minder data dan SOAP, omdat er geen XML meer bij komt kijken.
Maar er is inmiddels een nieuwere optie die aan populariteit wint: het in 2012 door Facebook ontwikkelde GraphQL. In 2015 werd de technologie open source. GraphQL omschrijft zichzelf als een 'query-taal voor API's'. Het heeft niet alleen netwerkresources nodig, maar ook minder front-end-resources, wat zorgt voor een betere totaalprestatie.
Het probleem van REST
REST is een geweldige technologie, en GraphQL is niet zozeer een vervanger als wel een aanvulling, die enkele issues van het REST-design aanpakt.
REST behandelt data als resources, waarbij elk REST-endpoint resources van een specifiek datatype kan terugsturen. Soms zijn resources gelinkt aan andere resources. Een voorbeeld: als je een online order op een website plaatst, spelen tal van data een rol bij die order. Een bekende use case in dit verband is rapportages.
Stel, we willen een overzicht van alle orders van augustus 2018 die zijn geplaatst door klanten tussen de 15 en 25. We vragen hier dus verschillende data op: over orders, producten en klanten. Dat zorgt voor diverse calls naar de backend voor elk object. Dit wordt wel underfetching genoemd. Je krijgt niet in één keer alle data die je nodig hebt, en je moet meerdere calls doen.
Een ander typische issue met REST is juist het tegenovergestelde: overfetching. Misschien hebben we alleen een orderlijst met de klantnamen nodig maar krijgen we ook alle blogcontent. Wanneer een app via een mobiel netwerk vragen moet afhandelen, wil je dit overfetching natuurlijk niet.
Nog voor alle duidelijkheid: REST is niets meer dan een architectuurstijl, terwijl GraphQL een specificatie heeft: meer dan tweehonderd pagina's met een gedetailleerde beschrijving over hoe je je schema moet ontwerpen. REST is meer wildwest - de enige specificatie die je hebt komt van de server.
Wiskundeles?
Ik zal er geen wiskundeles van maken, maar laten we even kijken hoe we zaken modelleren. Bij computerwetenschappen gaat om het modelleren van objecten uit de fysieke wereld en het bepalen hoe ze samenwerken. In de grafentheorie is een graaf een manier om objecten en de manier waarop ze verbonden zijn, weer te geven. Bijvoorbeeld producten, klanten en orders. We geven zo een vorm aan data.
Wat GraphQL onder andere doet, is het specificeren van de vorm van de data die we opvragen. Wanneer we weten hoe de data die we krijgen eruitziet, is het veel gemakkelijker om er iets zinnigs over te zeggen.
Hoe speelt GraphQL in op de beperkingen van REST?
GraphQL biedt een oplossing voor under- en overfetching bij REST door een interface te bieden voor het specificeren van de exacte data die je nodig hebt. Met andere woorden: het biedt een taal voor het specificeren van de vorm van de data die we opvragen.
Zo kan ik in één netwerkcall een blogpost opvragen, inclusief de auteur, waarbij ik exact de vereiste velden kan aangeven. Dit lost twee problemen op: minder netwerkverkeer en dus een snellere respons. Maar omdat ik precies die data krijg die ik zoek, heb ik ook minder complexe front-end logica nodig. Ik hoef niet meer door allerlei REST-responses te ploegen om de juiste data te vinden: ik krijg alles via GraphQL.
Een andere interessante feature van GraphQL is introspectie. De GraphQL-server weet welke query's hij ondersteunt, wat betekent dat je hem kunt query'en voor ondersteunde functies. Maar je kunt ook gebruikmaken van hulp bij field completion. Wanneer ik dus een GraphQL-query schrijf, bespaar ik ontwikkeltijd omdat ik mij niet hoef af te vragen wat de juist veldnamen zijn
Natuurlijk is het niet allemaal rozengeur en maneschijn. Ook GraphQL heeft zijn nadelen. Aangezien alles een POST is voor een enkele URL wordt client-side caching een probleem. Ook query-complexiteit kan een probleem worden. Omdat GraphQL de meest computationele complexiteit van een query verbergt, kunnen slecht geschreven GraphQL-query's leiden tot bottlenecks en vertraging.
Daar komt bij dat je een extra laag aanbrengt tussen een server en een client. Meer bewegende delen betekent altijd een grotere kans dat iets stuk gaat.
Conclusie
GraphQL is een opkomende technologie. Het is geen vervanging van REST of SOAP en er blijven altijd use cases waarvoor GraphQL niet de juiste keus is. Maar het biedt wel een nieuwe manier van denken over het design en gebruik van API's. En als ontwikkelaar ben je altijd blij met nieuwe, glimmende tools.
Dave Lilly is Senior Solutions Consultant bij SaaS-platformbedrijf commercetools.
.
Reageer
Preview