GraphQL – De manier waarop applicaties communiceren verandert en verbetert

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

De technologie waar we het vandaag over hebben, is de manier waarop data tussen applicaties en de bedrijven die ze bezitten, wordt overgedragen (gelezen, bijgewerkt, toegevoegd/verwijderd). Application Programming Interfaces (API’s) zijn de architectuur die deze datacommunicatie definieert, en naarmate deze standaarden zijn ontwikkeld, zijn de verwerkings- en gegevensopslagvereisten minder zwaar geworden.

De leider in het pakket in termen van “lichte” resource-gebruik is GraphQL, een open-source dataquery- 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 applicatie-ontwikkeling. In 2015 werd het “open source” gemaakt en tegenwoordig wordt het beheerd door de GraphQL Foundation (https://graphql.org/foundation/) die de verdere ontwikkeling ervan overziet.

Waarom schrijf ik hier nu over? Een typische roadmap naar technologische adoptie zal de volgende stappen 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 tech-reuzen.

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.

Ik zocht een manier om data efficiënter op te halen uit Salesforce en kwam hun GraphQL-documentatie tegen en begon te lezen en te kijken naar manieren om het te implementeren.

Hoe verschilt het van een traditionele REST API?

• Een van de grote voordelen is dat met GraphQL je data kunt opvragen en alleen de specifieke data terugkrijgt. Als je alleen twee velden wilt hebben die betrekking hebben op een specifiek client-incident, dan krijg je dat. Een traditionele REST API zou alle velden teruggeven die zijn gekoppeld aan het incident. Dat kan 100+ velden zijn. Nu moet je iets doen met alle data 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 teruggeven van data.
• GraphQL is een sterk getypeerde taal, wat onder andere betekent dat codefouten worden opgevangen voordat het programma wordt uitgevoerd en niet tijdens de uitvoering.
• Er is een geweldige set tools gebouwd rondom GraphQL, wat het voor ontwikkelaars zeer vriendelijk heeft gemaakt.
• GraphQL heeft één eindpunt, in tegenstelling tot REST API, die meerdere eindpunten heeft. Dit betekent dat alle data kan worden opgehaald in één aanvraag.

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

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

Als voorbeeld, als we data van Salesforce wilden opnemen met betrekking tot client-incidenten in een client-portaal, zou de meest efficiënte manier zijn om de exacte data op te vragen die we willen hebben via een GraphQL-aanvraag van het portaal naar de Salesforce GraphQL-server. Je krijgt exact de data 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 data 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 gedaan, wordt het opvragen van data via de API naadloos.

Wanneer ik applicaties of aanbieders vergelijk, kijk ik naar de functionaliteiten die ze me bieden om mijn data terug te krijgen van hen. Ik wil niet per se een e-mail moeten sturen of moeten vertrouwen op stug vooraf gedefinieerde rapporten. Ik wil in staat zijn om “in te pluggen” in mijn data en het op een flexibele, tijdige manier op te vragen. Als het erop neerkomt dat twee applicaties/aanbieders op andere vergelijkingspunten vergelijkbaar zijn en een van hen een REST API of een GraphQL API biedt, zal ik zeker degene met de API kiezen.