Het kan lastig zijn om de technologieën te kiezen die in de techstack van je volgende project worden opgenomen. In veel gevallen – en vooral als het gaat om de keuze tussen GraphQL en RESTful API’s – gaat het om het kiezen van de op één na beste API ontwerparchitectuur.
Er zijn vier belangrijke manieren om API’s te bouwen: SOAP, GRPC, REST en GraphQL. We beperken ons vaak tot REST en GraphQL als we API’s willen bouwen. Dat komt omdat REST de traditionele manieren om API’s te bouwen met SOAP en GRPC heeft veranderd.
GraphQL wordt algemeen bestempeld als een betere REST, omdat het een betere manier is om API’s te bouwen. Veel ontwikkelaars geloven dat GraphQL REST zal vervangen. Nog meer hebben al ontdekt dat GraphQL helpt bij het oplossen van enkele veel voorkomende uitdagingen waar ontwikkelaars tegenaan lopen bij het bouwen van REST API’s.
Deze twee methoden om API’s te bouwen zijn totaal verschillend. In de praktijk werken deze technologieën door een HTTP verzoek te sturen en het resultaat te ontvangen. Ze hebben allebei hun voor- en nadelen, en in dit artikel gaan we uitgebreid in op deze twee geweldige technologieën die de manier waarop we API’s ontwikkelen en schalen hebben veranderd.
Maar voordat we in de details graven, laten we eerst de betekenis van GraphQL en RESTful API’s verkennen.
Wat is GraphQL?
GraphQL is een API querytaal en een runtime voor het beantwoorden van die queries met bestaande gegevens. Het is uitgerust met krachtige tools om zelfs de meest complexe queries af te handelen.
De centrale feature van GraphQL is de mogelijkheid om alleen de gevraagde specifieke gegevens op te vragen en te ontvangen – niets meer. Dit maakt het veel eenvoudiger om je API’s mee te schalen met je app.
Het interessantste deel van GraphQL is zijn vermogen om je alle data in één endpoint te geven.
Het bovenstaande diagram is een typische weergave van GraphQL architectuur. Clients doen verzoeken vanaf verschillende apparaten, en GraphQL handelt hun verzoeken af en geeft alleen de door hen gevraagde data terug. Dit lost netjes het probleem van over-fetching en under-fetching in RESTful API’s op.
In het bovenstaande voorbeeld laten we een GraphQL playground zien en hoe je met een enkel endpoint data kunt opvragen. Bovenaan staat het API endpoint, links staat de query die namen van continents opvraagt, en als laatste, rechts, reageren we op de opgevraagde query.
GraphQL werd gemaakt door Facebook met als voornaamste doel het oplossen van de ervaring van hun ontwikkelaars van mobiele apps bij het werken met REST API’s. Sinds de eerste open-source versie ervan in 2015 werd uitgebracht, heeft GraphQL een enorme groei doorgemaakt door de adoptie van de technologie door grote spelers in de techbusiness.
Bedrijven die GraphQL gebruiken
Hieronder volgt een lijst van een (klein) deel van de bedrijven en applicaties die GraphQL actief gebruiken op hun servers.
Facebook creëerde GraphQL, en gebruikt het sinds 2012 in productie om hun mobiele apps aan te drijven. Het reusachtige socialenetwerkbedrijf heeft de GraphQL spec in 2015 ge-opensourced, waardoor hij toegankelijk is voor vele omgevingen en voor teams van elke omvang.
GitHub
Ook GitHub gebruikt GraphQL door een GraphQL API aan te bieden voor het maken van integraties, het ophalen van gegevens en het automatiseren van je workflows met behulp van de GitHub GraphQL API. De GitHub GraphQL API biedt preciezere en flexibelere queries dan de GitHub REST API.
Pinterest is ook een vroege gebruiker van GraphQL. De foto-sharing gigant heeft publiekelijk gesproken over hun vroege verkenning van GraphQL en hoe ze de GraphQL technologie gebruiken die hun miljardenbedrijf aandrijft.
Veel andere miljardenbedrijven zoals Intuit, Shopify, Coursera en Airbnb drijven hun applicaties aan met GraphQL. En deze brede voorkeur voor REST blijft alleen maar groeien.
Wat is RESTful API?
REST staat voor “Representational State Transfer,” een softwarematige architectuurstijl voor gedistribueerde hypermediasystemen. Het definieert principes en beperkingen voor het uitwisselen van resources tussen de server en de clients.
Als deze principes in een API worden gevolgd, wordt de toepassing van die API “RESTful” genoemd. De WordPress REST API is hier een uitstekend voorbeeld van.
Hieronder staan enkele van de principes en beperkingen waaraan een API moet voldoen om een Restful API genoemd te worden:
- Client-Server ontkoppeling: De clients (frontend) en de server (backend) zijn volledig gescheiden en kunnen alleen communiceren via de endpoints.
- Uniforme interface: Gegevens die in de interface te zien zijn, zijn identiek voor alle apparaten.
- Stateless: De server onthoudt niet of het huidige verzoek voor de eerste keer wordt gedaan of niet. Elke keer dat een verzoek wordt gedaan, moet het alle informatie bevatten die nodig is om het vanaf nul te verwerken.
- Cacheerbaarheid: Caching en sessieopslag is toegestaan, maar ze moeten zo geconfigureerd zijn dat eindgebruikers kunnen afzien van het cachen van gegevens.
- Gelaagde systeemarchitectuur: API’s moeten zo ontworpen zijn dat noch de client noch de server kan zien of ze rechtstreeks of via een tussenpersoon communiceren.
Het diagram hieronder is een basic REST architectuur. Het laat zien hoe verzoeken en reacties gewoonlijk worden afgehandeld.
GraphQL vs REST: Wat is het verschil?
Voordelen van GraphQL
Hieronder staan een paar voordelen van het gebruik van GraphQL, die illustreren waarom het meer dan voldoende is voor het bouwen elke mogelijke app.
Gegevens ophalen via een enkel API endpoint
Het grootste voordeel van GraphQL is de mogelijkheid om via een enkel API endpoint toegang te krijgen tot een of alle datapoints.
Een van de meest voorkomende problemen met RESTful API’s is het hebben van te veel endpoints om informatie op te vragen. In GraphQL heb je maar één enkel endpoint, zodat je niet meerdere verzoeken hoeft te sturen om verschillende informatie over een object op te halen.
Het diagram hieronder toont een duidelijk voorbeeld van het opvragen van resources met behulp van RESTful API en GraphQL. Je kunt zien dat er maar één eindpunt is om toegang te krijgen tot de resource in de GraphQL server, terwijl er meerdere API eindpunten nodig zijn om toegang te krijgen tot verschillende resources in de RESTful API.
Geen over-fetching of under-fetching
Het probleem van over- of under-fetching is een bekend probleem bij RESTful API’s. Dit is wanneer cliënten gegevens downloaden door endpoints op te vragen die vaste gegevensstructuren retourneren, of anders meer of minder ophalen dan ze verwachtten.
Over-fetching heeft tot gevolg dat het verzoek meer gegevens ontvangt – of “ophaalt” – dan wat nodig is voor een bepaald verzoek. Stel je voor dat je alle gebruikers in een tabel ophaalt met de bedoeling hun gebruikersnamen op je homepage weer te geven. In dat geval zal over-fetching alle gegevens over elke gebruiker teruggeven, inclusief (maar niet alleen) de naam.
Under-fetching is relatief zeldzaam, maar het gebeurt wel als het specifieke eindpunt niet alle gevraagde informatie kan leveren. De cliënt moet dan extra verzoeken doen om toegang te krijgen tot de andere informatie, indien nodig.
GraphQL lost het probleem van over-fetching of under-fetching efficiënt op door precies die resource te pakken die de cliënt heeft opgevraagd, zonder extra details.
Betere afhandeling van complexe systemen en microservices
GraphQL kan de complexiteit van geïntegreerde meerdere systemen verenigen en verbergen.
Stel bijvoorbeeld dat we willen migreren van een monolithische backend applicatie naar een microservice architectuur. De GraphQL API helpt de communicatie tussen verschillende microservices af te handelen door ze samen te voegen in één GraphQL schema.
Zodra deze schema’s zijn gedefinieerd, kunnen zowel de frontend als de backend afzonderlijk communiceren zonder verdere wijzigingen, omdat de frontend weet dat de gegevens in het schema altijd synchroon zullen zijn over het hele systeem.
Snel en veilig
Het probleem van over-fetching kan resulteren in een hoger bandbreedteverbruik voor clients, wat op den duur vertraging in je applicatie kan veroorzaken. Het gebruik van RESTful API ontwerppatronen kost meer tijd om de benodigde informatie uit een enorme payload te sorteren.
Door het vermogen van GraphQL om over-fetching en under-fetching te vermijden, stuurt de server een veilige, goed leesbare en voorspelbare vorm terug, waardoor je API verzoeken en reacties sneller worden.
Voordelen van REST
Ondanks de groeiende populariteit van GraphQL is REST nog steeds een van de populairste API standaarden. Laten we eens kijken waarom.
- Leercurve: RESTful API’s zijn het gemakkelijkst te leren en te begrijpen. Dit is het belangrijkste voordeel ten opzichte van andere API’s.
- Serialisatie: REST heeft een flexibele aanpak en formats voor het serialiseren van gegevens in JSON.
- Caching: REST API kan een hoge belasting aan met behulp van een HTTP proxy server en cache.
- Complexe verzoeken: REST API’s hebben een apart eindpunt voor verschillende verzoeken, en dat helpt om het complexe verzoek beter beheersbaar te maken dan bij andere API’s
- Strak en eenvoudig: REST API’s zijn elegant, eenvoudig en strak. Ze zijn eenvoudig te verkennen.
- Standaard HTTP procedures: REST gebruikt standaard HTTP procedure aanroepen om gegevens op te halen en verzoeken te doen.
- Client/Server: Dit betekent dat de bedrijfslogica is losgekoppeld van de presentatie. Je kunt dus het ene veranderen zonder het andere te beïnvloeden.
- REST is stateless: Alle berichten die tussen client en server worden uitgewisseld hebben alle context die nodig is om te weten wat er met het bericht moet gebeuren.
Nadelen van GraphQL
Nu we de voordelen van GraphQL vs REST hebben besproken, laten we eens kijken naar enkele nadelen van GraphQL:
- Moeilijke leercurve: GraphQL is niet zo gemakkelijk te leren als REST. Het meest uitdagende deel van het bouwen van een GraphQL API is het ontwerpen van het schema. Dit kost veel tijd en domeinkennis.
- Bestanden uploaden: GraphQL heeft geen native feature voor het uploaden van bestanden. Dit kan worden omzeild met Base64 codering, maar de kosten van het coderen en decoderen op deze manier kunnen tijdrovend en duur zijn.
- Webcaching: Caching helpt het frequente verkeer naar de server te verminderen, wat de verzoeken en het antwoordproces versnelt door veelgebruikte informatie dicht bij de server te houden. GraphQL ondersteunt of vertrouwt niet op HTTP cachingmethoden, maar is afhankelijk van de cachingmechanismen van de Apollo of Relayclients.
- Ongeschikt voor kleine applicaties: GraphQL is misschien niet de beste API architectuur voor het bouwen van een kleine applicatie. Als je app de flexibelere queries die GraphQL biedt niet nodig heeft, dan is REST de beste oplossing.
- Complexe queries: Het vermogen van GraphQL om een client precies te geven wat hij wil, kan ook leiden tot querypropagatieproblemen. Als een client te veel nested queries indient, kan dat ertoe leiden dat de verkeerde queries worden verzonden, wat de server veel tijd kan kosten. Het is beter om REST te gebruiken met aangepaste endpoints om aan zulke verzoeken te voldoen.
Nadelen van REST
Laten we nu eens kijken naar de nadelen van REST:
- Meerdere retours: Het grootste probleem met REST API’s is de aard van talrijke eindpunten. Dit betekent dat de client, om alle resources voor een complete applicatie te krijgen, ontelbare retours moet maken om de gegevens te krijgen.
- Over-fetching en under-fetching: Het probleem van over-fetching en under-fetching is een groot nadeel bij RESTful APIS. Het kan vertraging in reacties veroorzaken door het ophalen van grote ongewenste payloads.
- Hiërarchie: Omdat REST API’s gebouwd zijn op URI verwijzende resources, passen ze slecht bij resources die niet van nature georganiseerd zijn of benaderd worden in een eenvoudige hiërarchie.
Waarom GraphQL gebruiken in plaats van REST?
Vervolgens zullen we bespreken waarom je GraphQL zou kunnen overwegen voor je toekomstige API ontwikkeling in plaats van RESTful API.
Sterk getypeerd schema
GraphQL gebruikt een sterk typesysteem om de mogelijkheden van de API te definiëren. In GraphQL wordt schema definition language (SDL) gebruikt om de parameters te definiëren rond de manier waarop de client toegang krijgt tot de gegevens van de server. Alle aan de client blootgestelde API’s worden in SDL opgeschreven, waardoor het probleem van de gegevensinconsistentie, zoals dat bij RESTful API’s voorkomt, wordt opgelost.
Geen over-fetching of under-fetching
Het probleem van over- of under-fetching is een bekend probleem bij RESTful API’s, waarbij clients ofwel meer ofwel minder informatie terugkrijgen dan ze vroegen. GraphQL lost dit probleem op door de cliënt een medium te bieden om de benodigde informatie te specificeren, en vervolgens precies – en alleen – die specifieke informatie terug te sturen.
Meerdere endpoints
Een van de grootste problemen van RESTful API’s is het hebben van te veel eindpunten om informatie op te vragen.
Stel dat je een bepaalde gebruiker wilt benaderen via zijn ID nummer. Je krijgt dan een eindpunt als /users/1. Maar als je toegang wilt tot de foto’s van die gebruiker, moet je een verzoek sturen naar een ander eindpunt, zoals /users/1/photos.
In GraphQL heb je een enkel eindpunt, en hoef je niet meerdere verzoeken te sturen om verschillende informatie over de gebruiker op te vragen.
Showdown GraphQL vs REST
Tot slot gaan we het grote verschil tussen GraphQL en RESTful API’s onderzoeken. Daarna bespreken we enkele kenmerken van een goed API-ontwerp en vergelijken we hoe elke technologie daarmee omgaat.
Prestaties
Het lijdt geen twijfel dat GraphQL sneller presteert dan RESTful API’s vanwege het vermogen om een enkel endpoint te bieden voor toegang tot al je resources. RESTful API’s gebruiken meerdere eindpunten, wat kan leiden tot netwerklatentie.
Complexiteit van de query
Omdat endpoints niet in meerdere endpoints worden gescheiden, kunnen GraphQL queries in de loop der tijd steeds complexer worden. RESTful API endpoints daarentegen zijn gescheiden, waardoor RESTful API’s beperkt blijven tot eenvoudige queries.
Populariteit en steun van de community
GraphQL is een groeiend API architectuurpatroon en querytaal. Hoewel het nog jong is, groeit het aantal gebruikers en resources snel, en er zijn al resources in overvloed voor degenen die het zelf willen leren.
REST, aan de andere kant, heeft al veel steun van de community en wordt nog steeds gebruikt door allerlei soorten bedrijven, variërend van bedrijven die kleine microservices bouwen tot bedrijven die complexe sociale apps maken en meer.
Op dit moment is de populariteitswedstrijd tussen GraphQL vs REST een gelijkspel. Beide technologieën worden nog steeds veel gebruikt en goed ondersteund door de ontwikkelgemeenschap.
Leercurve
De leercurve voor GraphQL is steil. Het vereist goede kennis van het domein van API ontwikkeling en algemene software engineering. Een complete beginner zal het moeilijk hebben om GraphQL goed genoeg te begrijpen om een complexe applicatie te bouwen.
REST daarentegen is heel gemakkelijk om mee te beginnen en vereist minder domeinkennis. RESTful API is goed geïntegreerd in de meeste grote programmeertalen en populaire frameworks, wat het leren ervan erg gemakkelijk maakt.
Samenvatting
GraphQL is een nieuwe technologie die in het spoor treedt van RESTful API architectuurpatronen, net zoals REST werd geïntroduceerd om problemen met SOAP API patronen op te lossen.
GraphQL biedt je snellere responses, een enkel API endpoint voor al je queries, en een strikt schema voor consistente gegevenstoegang. Deze redenen hebben ervoor gezorgd dat miljardenbedrijven beginnen over te stappen op GraphQL, zelfs in een vroeg stadium. Maar ondanks zijn beperkingen blijft GraphQL’s voorloper REST sterk aanwezig op het wereldtoneel.
In deze handleiding hebben we alles onderzocht wat je moet weten over GraphQL en RESTful API’s, inclusief de voor- en nadelen van elke technologie, zodat je met vertrouwen kunt beslissen aan welke je de voorkeur geeft. We hebben ook de bekende problemen met RESTful API’s besproken – zoals over-fetching, under-fetching, en meerdere endpoints – en hoe GraphQL probeert die problemen op te lossen en de prestaties van je app te verbeteren.
Je hebt nu genoeg inzicht om te kiezen of GraphQL vs REST geschikt is voor je volgende project. Laat ons in de commentaarsectie weten wat jij gaat bouwen met de door jou gekozen winnaar!
Het belangrijkste verschil is hoe ze met de server communiceren. GraphQL is een nieuwere technologie die een enkel endpoint gebruikt om te reageren op verzoeken, terwijl REST een reeks endpoints gebruikt die reageren op specifieke HTTP verzoeken. GraphQL wordt over het algemeen beschouwd als efficiënter en flexibeler dan REST.