GraphQL – Ändrar och förbättrar sättet applikationer kommunicerar

Det kommer inte att dröja länge innan nästa generation kommer att köpa krypto och kontrollera sina enhetsfondsbalanser i Fortnite-lobbyn mellan spel. Detta kommer att möjliggöras genom många tekniska framsteg.

Den vi diskuterar idag är sättet data överförs (läses, uppdateras, läggs till/ tas bort) mellan applikationer och de företag som äger dem. Applikationsprogrammeringsgränssnitt (API) är arkitekturen som definierar denna datakommunikation och när dessa standarder har utvecklats, har bearbetningskraven och datalagringskraven blivit mindre betungande.

Ledaren i gruppen när det gäller “lätt” resursanvändning är GraphQL, ett öppen källkodsdatafrågespråk och manipuleringsspråk. Dess ekosystems grund är dess specifikation och en samling verktyg som har skapats runt det.

Det är inte nytt – tiden går fort. Facebook utvecklade det 2012 och använde det endast internt för mobilapplikationsutveckling. 2015 “öppen källkods”-det och idag sköts det av GraphQL Foundation (https://graphql.org/foundation/) som övervakar dess vidareutveckling.

Så varför skriver jag om det nu? En typisk väg till teknisk antagande kommer att följa följande antagande 1) hobbyister/personliga projekt, 2) implementering över flera språk, 3) implementering över start-ups och små företag, 4) medelstora företag och används i produktutveckling, 5) stora företag och techjättar.

GraphQL har nått nivå 5. För närvarande används det av GitHub, Pinterest, Shopify, Microsoft för att nämna några och senast, från och med mars 2022, Salesforce.

När jag letade efter ett sätt att hämta data mer effektivt från Salesforce kom jag över deras GraphQL-dokumentation och började läsa och titta på sätt att implementera det.

Hur skiljer det sig från en traditionell REST API?

• En av de stora fördelarna är att med GraphQL kan du fråga och endast få den specifika datan. Om du bara vill ha två fält relaterade till ett visst kundärende, då är det vad du får. En traditionell REST API skulle returnera alla fält associerade med ärendet. Det kunde vara 100+ fält. Nu måste du göra något med all den data du inte ville ha från början. Detta kallas data över hämtning (under hämtning är också ett problem).
• Ovanstående gör GraphQL snabbare än andra API-metodik när det gäller att returnera data.
• GraphQL är ett starkt typat språk som bland annat innebär att kodfel upptäcks innan programmet körs och inte under det.
• En stor uppsättning verktyg har byggts runt GraphQL som har gjort det mycket utvecklarvänligt.
• GraphQL har en enda slutpunkt till skillnad från REST API som har flera slutpunkter. Detta innebär att all din data kan hämtas i en enda begäran.

Two sides of the coin: requestor (client) and provider (GraphQL host)

Jag har tittat på GraphQL så långt från data “begäran” perspektivet. Där ett företag som Salesforce eller Microsoft har konfigurerat en GraphQL API som du kan använda för att fråga och manipulera data (läsa, uppdatera, lägga till).

Om vi till exempel ville inkludera data från Salesforce relaterad till kundärenden i en kundportal, skulle det mest effektiva sättet att göra detta vara att begära den exakta datan vi är ute efter genom en GraphQL-fråga från portalen till Salesforce GraphQL-servern. Du kommer att få exakt den data du vill ha, ingen under- eller överhämtning och som ett resultat kommer ingen ytterligare bearbetning eller datalagring att krävas.

Den andra sidan av myntet är organisationen som konfigurerar GraphQL-arkitekturen så att dina kunder kan ha en effektiv metod för att komma åt den data de önskar.

När man bygger GraphQL API skapar en organisation en modell som integrerar alla system i en modell. Det förenar dessa system och när arbetet är klart, blir det att fråga datan sömlöst genom API:et.

När jag jämför applikationer eller leverantörer tittar jag på vilka funktioner de erbjuder mig för att hämta min data tillbaka från dem. Jag vill inte behöva skicka e-post till dem eller förlita mig på stela fördefinierade rapporter. Jag vill kunna “ansluta till” min data och fråga den på ett flexibelt och snabbt sätt. Om det kommer ner till två applikationer/leverantörer och de är lika matchade på andra jämförelsepunkter, och en av dem erbjuder antingen en REST API eller en GraphQL API, kommer jag definitivt att välja den med API:et.