Graphql – Het veranderen en verbeteren van de manier waarop applicaties communiceren

Het zal niet lang duren voordat de volgende generatie crypto koopt en hun unit trust-saldo controleert in de Fortnite-lobby tussen games. Dit zal mogelijk gemaakt worden door veel technologische vooruitgang.

De technologie waarover we vandaag spreken, is de manier waarop gegevens worden overgedragen (gelezen, bijgewerkt, toegevoegd/verwijderd) tussen applicaties en de bedrijven die ze bezitten. Application Programming Interfaces (API’s) zijn de architectuur die deze gegevenscommunicatie definieert, en naarmate deze standaarden zijn ontwikkeld, zijn de verwerkings- en gegevensopslagvereisten minder zwaar geworden.

De leider in het pakket in termen van “lichte” resourcegebruik is GraphQL, een open-source gegevensquery- en manipulatietaal. De basis van zijn ecosysteem is zijn specificatie en een verzameling tools die rondom het is gecreëerd.

Het is niet nieuw – de tijd gaat snel. Facebook ontwikkelde het in 2012 en gebruikte het alleen intern voor mobiele applicatieontwikkeling. In 2015 werd het “open source” en tegenwoordig wordt het beheerd door de GraphQL Foundation (https://graphql.org/foundation/) die de verdere ontwikkeling ervan verzorgt.

Waarom schrijf ik er nu over? Een typische roadmap naar technologische adoptie zal de volgende fasen volgen: 1) hobbyisten/persoonlijke projecten, 2) implementatie over meerdere talen, 3) implementaties over start-ups en kleine bedrijven, 4) middelgrote bedrijven en gebruikt in productontwikkeling, 5) grote ondernemingen en techreuzen.

GraphQL heeft niveau 5 bereikt. Momenteel wordt het gebruikt door GitHub, Pinterest, Shopify, Microsoft, om er maar een paar te noemen, en meest recent, vanaf maart 2022, Salesforce.

Toen ik op zoek was naar een manier om gegevens efficiënter op te halen uit Salesforce, stuitte ik op hun GraphQL-documentatie en begon te lezen en te zoeken naar manieren om het te implementeren.

Hoe verschilt het van een traditionele REST API?

• Een van de grote voordelen is dat met GraphQL je gegevens kunt opvragen en alleen de specifieke gegevens terugkrijgt. Als je alleen twee velden wilt hebben die verband houden met een specifiek clientincident, dan krijg je dat. Een traditionele REST API zou alle velden retourneren die verband houden met het incident. Dat kan 100+ velden zijn. Nu moet je iets doen met alle gegevens die je niet wilde hebben. Dit wordt data over fetching (onder fetching is ook een probleem) genoemd.
• Het bovenstaande maakt GraphQL sneller dan andere API-methodologieën bij het retourneren van gegevens.
• GraphQL is een sterk getypeerde taal, wat onder andere betekent dat codefouten worden opgepikt voordat het programma wordt uitgevoerd en niet tijdens de uitvoering.
• Er is een geweldige set tools gebouwd rondom GraphQL, waardoor het zeer ontwikkelaarvriendelijk is.
• GraphQL heeft één eindpunt, in tegenstelling tot REST API, die meerdere eindpunten heeft. Dit betekent dat alle gegevens kunnen worden opgehaald in één verzoek.

Twee kanten van de medaille: aanvrager (client) en aanbieder (GraphQL-host)

Ik heb tot nu toe naar GraphQL gekeken vanuit het perspectief van gegevens “aanvragen”. Waar een bedrijf zoals Salesforce of Microsoft een GraphQL API heeft ingesteld die je kunt gebruiken om gegevens op te vragen en te manipuleren (lezen, bijwerken, toevoegen).

Als voorbeeld, als we gegevens van Salesforce over clientincidenten in een clientportal wilden opnemen, zou de meest efficiënte manier zijn om de exacte gegevens die we zoeken op te vragen via een GraphQL-query van de portal naar de Salesforce GraphQL-server. Je krijgt precies de gegevens die je wilt, geen onder- of over-fetching en als gevolg daarvan geen extra verwerking of gegevensopslag vereist.

De andere kant van de medaille is de organisatie die de GraphQL-architectuur instelt zodat klanten een efficiënte methode hebben om toegang te krijgen tot de gegevens die ze willen.

Bij het opbouwen van de GraphQL API creëert een organisatie een model dat alle systemen integreert in één model. Het unificeert deze systemen en zodra het werk is voltooid, wordt het opvragen van gegevens via de API naadloos.

Wanneer ik applicaties of aanbieders vergelijk, kijk ik naar welke functionaliteiten ze me bieden om mijn gegevens terug te krijgen. Ik wil niet per e-mail moeten vragen of moeten vertrouwen op rigide vooraf gedefinieerde rapporten. Ik wil in staat zijn om “in te pluggen” in mijn gegevens en ze flexibel en tijdig op te vragen. Als het erop aankomt tussen twee applicaties/aanbieders en ze zijn vergelijkbaar op andere vergelijkingspunten, en één biedt een REST API of een GraphQL API, zal ik zeker degene met de API kiezen.