REST versus GraphQL: een eerlijk gevecht?

15-1-2019

REST versus GraphQL: een eerlijk gevecht?

Binnen een “API First Economy” maken API’s een enorm sterke ontwikkeling door. Waar van oudsher de focus niet of nauwelijks op goed ontworpen, ontwikkelde en gedocumenteerde API’s lag, is dit binnen een hedendaags – vaak ontkoppeld – IT-landschap niet meer weg te denken. Wie vaker met API’s te maken heeft gehad, kent ongetwijfeld ook de verschillende “smaken” webservices waarmee informatie uitgewisseld kan worden, waarvan REST het meest een belletje doet rinkelen. Er is echter een relatief nieuwe speler actief: GraphQL. Dit is een query-taal voor API’s, van origine intern ontwikkeld door Facebook in 2012 – publiekelijk open source gemaakt in 2015 - met als doel het verbeteren van de productiviteit van de ontwikkelaar en het minimaliseren van dataoverdracht. Je bespaart in theorie dus kosten aan respectievelijk personeel en je (Cloud) provider.

Kortom: kan GraphQL als uitdager van het alom gebruikte REST gelden?

Schaak API
Kan GraphQL als uitdager van het alom gebruikte REST gelden?

De verschillen

Bij reguliere vergelijkingstesten zet je twee partijen tegenover elkaar en bekijk je ieders plus- en minpunten om daarna middels een scoretelling een winnaar uit te roepen. ‘Een fluitje van een cent’, zou je zeggen? Welnu, helaas niet. REST en GraphQL zijn namelijk wezenlijk verschillend en daarbij niet te vergelijken. Daar waar REST een architectuurconcept is zonder specificatie en zich geenszins bekommert welk protocol je gebruikt, is GraphQL een query-taal met specificaties die ontworpen is om middels een enkele “resource” via HTTP te werken. GraphQL focust zich daarmee in essentie op performance, daar waar REST met een bepaalde mate van robuustheid ontwikkeld is om decennialang mee te gaan. Betekent dit dat je dus een keuze moet maken tussen de twee? Nee, geenszins. Dat vereist verdere toelichting.

Toepassingen in de praktijk

Zonder al te veel technisch de diepte in te duiken, is het belangrijk om nogmaals aan te halen dat je via GraphQL verschillende resources kan raadplegen in één enkele request; je hebt dus maar één resource waar je tegenaan programmeert. Bij REST API’s zijn resources gescheiden opgezet en zal je doorgaans meerdere requests doen om de benodigde data op te halen.

Laten we kijken naar een versimpeld voorbeeld. Stel je wilt weten wie de vrienden van een superheld zijn. In een gestructureerde REST-situatie zou je normaliter eerst informatie moeten verkrijgen over een superheld (al dan niet via een algemene resource), waarmee je vervolgens met de data die je terugkrijgt een aparte request kan doen naar een andere resource die informatie bevat over de vrienden van deze superheld:

request superheld

In GraphQL ziet een soortgelijke request er anders uit:

Request superheld

 

De request bevat dus een enkele query op een enkele resource waarmee je filtert op hetgeen je wilt opvragen. Het voorkomt dus verschillende requests naar meerdere resources. Dit brengt wel weer een andere vraag met zich mee (en geeft GraphQL daarmee wellicht de stempel van “poor man’s API”): kan je dus simpelweg de volgende query afvuren: { hero(id: 123) { * } } of nog erger: { * }? Zou het niet fantastisch wezen om een bulk aan data uit je ‘system of record’ te trekken, hoor ik menigeen denken? Helaas levert dit potentieel een enorme performance issue op. Gelukkig is GraphQL ontwikkeld om dit soort “feest queries” tegen te gaan. Je moet namelijk altijd exact aangeven welke velden je terug wenst te verwachten.

Een nadeel dat vaak genoemd wordt, is dat je er zeker van moet zijn dat je cache-laag en de indexes op je achterliggende database(s) op een juiste manier aangelegd zijn om voor een snelle respons te zorgen, maar dat kan je ten dele ook van de REST-variant zeggen (je komt dan in theorie resources tegen die trager werken dan andere).

Voor velen die structuur nastreven, is het hebben van verschillende resources via REST gevoelsmatig de manier om hun API-product te ontwikkelen. En daar is ook wat voor te zeggen. Je kan echter ook niet om het ogenschijnlijke gemak van een query via een enkele resource heen.

Hoe verder?

Nu we gezien hebben tot wat beide in staat zijn, kan je ze eigenlijk geen opponenten noemen. De vraag die zich nu aandient is: hoe plaats ik beide in mijn IT-landschap?

Het antwoord is sterk afhankelijk van je IT-landschap. Vaak zie je dat er geen keuze gemaakt wordt voor één enkele vorm: in een ontkoppeld IT-landschap waar met (micro)services gewerkt wordt, kan het zo maar zijn dat je voor bepaalde services juist GraphQL kiest. Welke dat zijn, wordt dan veelal bepaald door welke databronnen ontsloten moeten worden en hoe “simpel” deze opgezet zijn. Ergens ontstaat het idee dat als je service aan de achterkant met koppeltabellen werkt, je eerder voor verschillende resources via REST zou kiezen.

Ze kunnen overigens ook prima naast elkaar leven binnen de scope van je hele API-product, hoewel daar dan weer de uitdaging ontstaat om het beheersbaar te houden. In dit laatste geval wordt er vaker geopperd om een soort gateway/data proxy via GraphQL op te zetten die op zijn beurt weer communiceert met onderliggende REST resources.

Al met al zijn we benieuwd wat jullie mening is over dit onderwerp en sparren graag over hoe dit vervolgens toepasbaar zou zijn binnen jullie API First Economy.

 

Robin Day

Business Thema's

IT-Trends

Kennismaken?

nl.info@ciber.nl

Binnen één werkdag reactie

Onze locaties

Bekijk onze locaties

Contact
2.0.2