Meer efficiency en flexibiliteit in API’s

Er wordt steeds meer gebruik gemaakt van GraphQL API. Tijdens mijn laatste opdracht heb ik hier dan ook mee gewerkt.. Graag deel ik mijn ervaringen hierover in een aantal blogs. In deze eerste blog wil ik het graag hebben over de uitdagingen met REST API en hoe GraphQL deze oplost.

Maar eerst even een korte introductie in REST API. We leven in een wereld waarin alles en iedereen door technologie met elkaar is verbonden. Hoe we dat doen? Met API’s, application programming interfaces. Bij het bouwen van een applicatie wordt vaak voor RESTful webservices gekozen om de applicatie met de buitenwereld te verbinden. REST staat voor REpresentational State Transfer. REST API’S definiëren een set aan functies welk de ontwikkelaars/testers kunnen uitvoeren bij het doen van requests en ontvangen van responses via HTTP Protocol zoals “GET”, “PUT”, “POSTS en “DELETE”.

Het gaat hierbij om het representeren van resources zoals foto’s, webpagina’s, profielen, artikelen, videoclips etc. via een client-server model. Bij het intypen van een URL in een browser of het klikken op een webpagina link doe je een request naar de webserver en ontvang je een response vanuit de webserver in de vorm van een resource terug. De webserver geeft dus niet een specifiek database als response terug, maar juist een representatie van de database in een formaat wat leesbaar is voor de gebruiker, bijvoorbeeld een HTML pagina of een XML/JSON bericht. Het klikken, scrollen of swipen op webpagina onderdelen geeft je continu een andere staat van de webpagina aan. De resources worden vervolgens in verschillende formaten vanuit de webserver overgedragen naar je webclient. Een REST API is dus een communicatie protocol tussen front-end en back-end.

Ongetwijfeld heb je ook over GraphQL gehoord, een open source data querytaal en runtime omgeving die je in staat stelt om een applicatie met de buitenwereld te verbinden. Is dit de eerste keer dat je van GraphQL hoort? Dan heb ik hier een interessante feit: je hebt het al gebruikt of gebruikt het nog steeds! Facebook heeft in 2012 GraphQL intern ontwikkeld en in 2015 op de markt uitgebracht. Het gebruik maken van Facebook betekent dus automatisch het gebruik van GraphQL en dit is bedacht om een aantal uitdagingen die worden ondervonden bij het gebruik van REST API’s op te lossen. Voornaamste doel is om de data uitwisseling tussen API’s en front-end applicaties eenvoudiger, efficiënter en flexibeler te maken.

Uitdaging 1: Multiple Endpoints

Web en mobiele applicaties zijn steeds meer data-driven en vereisen grote datasets die gerelateerde resources combineren. Om de volledige data op te halen, ook wel “fetching” genoemd, moet men via een REST API vaak meerdere calls uitsturen om alle nodige data te verzamelen om het uiteindelijk aan de gebruiker te representeren. Als een gebruiker bijvoorbeeld op de website van de Telegraaf een opmerking op een willekeurige artikel pagina met een profielfoto en de naam van de auteur opvraagt, dan wordt bij het opvragen van deze data driemaal een roundtrip naar de server gedaan om uiteindelijk over de volledige data te beschikken. Er wordt dus een call gedaan voor zowel de opmerking op de artikel pagina als voor de profielfoto en de naam van de auteur.

Met behulp van GraphQL, waarin QL staat voor “Query Language”, kan men zelf query’s samenstellen en hierin zelf exact duidelijk maken wat diegene van de API nodig heeft. De runtime omgeving vertaalt deze query’s naar functies om data op te halen en eventueel te wijzigen. Waar REST API meerdere endpoints nodig heeft voor het ophalen van data, heeft GraphQL er slechts één nodig.

Kortom: met een single endpoint kan GraphQL de exacte data ophalen om deze aan de gebruiker te representeren. Niet meer en niet minder! Op deze manier creëer je efficiëntie in je architectuur.

Uitdaging 2: Overfetching & underfetching van data

Een ander probleem die veroorzaakt wordt bij het gebruiken van een Rest Service is overfetching en underfetching. Met overfetching wordt bedoeld dat de client data ophaalt welke niet noodzakelijk is. Meer data is meer benodigde tijd om de gevraagde data te parsen en te downloaden, waardoor de performance verslechtert. Uit ervaring weet ik, dat in vele gevallen bij het ophalen van klantgegevens zoals naam, achternaam, geboortedatum, adres, woonplaats vanuit de server vaak ook een profielnaam en profielfoto meegegeven worden. De laatste twee worden niet benut en het fetchen van deze data is daarom niet noodzakelijk – You ain’t gonna need it (YAGNI)! Underfetching is het tegenovergestelde van overfetching en houdt in dat er niet voldoende data is voorzien in de Rest Service. De client dient een additionele call te doen om de gewenste data op te halen vanuit de server. Je kunt dit oplossen door specifieke API endpoint te bouwen op de databehoeften van front-end applicaties. Je creëert dan wel meerdere endpoints, waardoor het managen van API’s in je front-end zeer inefficiënt kan worden. Daarnaast is het onderhouden van deze endpoints arbeidsintensief en worden met de tijd onoverzichtelijk.

Uitdaging 3: Geautomatiseerde documentatie

Bij een technische omgeving maakt men vaak gebruik van een REST API documentatie – swagger – waarin verschillende endpoints met de bijbehorende versies zijn beschreven en deze ook hierin worden onderhouden indien zich wijzigingen voordoen in de applicatie. Het voordeel van GraphQL API’s is dat deze zijn opgebouwd in types & fields en niet in endpoints. Het kloppende hart van een GraphQL API is het schema. In het schema definieer je welke query’s allemaal tegelijk mogelijk zijn op de API. In het schema worden alle objecten en velden vastgelegd die de gebruiker kan opvragen, eventueel met de benodigde relaties van deze objecten. Daarnaast wordt als ondersteuning een tool, GraphiQL, meegeleverd die naast je GraphQL server draait waarmee het schema van de API in een web interface wordt weergegeven en de gebruiker automatisch suggesties krijgt bij het invoeren van de query. GraphiQL verzorgt voor een volledig geautomatiseerd documentatie van de GraphQL API en maakt deze op een centraal repository beschikbaar voor de verschillende API’s, hetgeen leidt tot front-end ontwikkelaar/tester gebruikersgemak.

Conclusie

In deze blog heb je vooral over de verschillen tussen GraphQL en REST API gelezen. Ik zou zeggen probeer eens GraphQL uit! Door de parallelle samenwerking tussen front-end engineers en back-end engineers kun je sneller features ontwikkelen. Je hoeft dus niet meer te wachten totdat de back-end engineers ontwikkeld hebben om de front-end applicatie op aan te sluiten. Ik ben van mening dat GraphQL de toekomst is en het ziet ernaar uit dat GraphQL API razendsnel populair wordt en de harten van ontwikkelaars veroverd. GraphQL API dient zeker niet als vervanging van de huidige REST API architectuur gezien te worden, maar juist vooral als alternatief. In mijn volgende blog ga ik verder in op het opzetten van GraphQL server met schema om mutaties uit te voeren. Wil je meer weten over GraphQL, dan kun je de volgende webpagina bezoeken: https://graphql.org/.