Graphql – Förä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 sin unit trust-balans 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 data lagringskraven blivit mindre ansträngande.

Ledaren i gruppen när det gäller “lätta” 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 blev det “öppen källkod” och idag sköts det av GraphQL Foundation (https://graphql.org/foundation/) som övervakar dess vidareutveckling.

Varför skriver jag om det nu? En typisk väg till en teknisk antagande kommer att följa följande uppdelning 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 teknikjä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 data som returneras. Om du bara vill ha två fält relaterade till en specifik kundincident, då är det vad du får. En traditionell REST API skulle returnera alla fält associerade med incidenten till dig. 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-metoder 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.

Båda sidor av myntet: begäran (klient) och tillhandahållare (GraphQL-värd)

Jag har tittat på GraphQL hittills från datans “begäran” perspektiv. 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).

Till exempel, om vi ville inkludera data från Salesforce relaterad till kundincidenter i en kundportal, skulle det mest effektiva sättet att göra detta vara att begära den exakta data 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 det inte att krävas någon ytterligare bearbetning eller data lagring.

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 vill ha.

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 data genom API:et helt sömlöst.

När jag jämför applikationer eller tillhandahållare tittar jag på vilka funktioner de erbjuder mig för att få tillbaka min data från dem. Jag vill inte behöva mejla dem eller förlita mig på styva fördefinierade rapporter. Jag vill kunna “koppla in” min data och fråga den på ett flexibelt och snabbt sätt. Om det kommer ner till två applikationer/tillhandahållare och de är jämnt matchade på andra jämförelsepunkter, och en erbjuder antingen en REST API eller en GraphQL API, kommer jag definitivt att välja den med API:et.