GraphQL – Ændrer og forbedrer måden, applikationer kommunikerer på

Det vil ikke vare længe, før den næste generation vil købe kryptovaluta og tjekke deres enhedstrustsaldo i Fortnite-lobbien mellem spil. Dette vil blive muliggjort gennem mange teknologiske fremskridt.

Det, vi diskuterer i dag, er måden, data overføres (læses, opdateres, tilføjes/fjernes) mellem applikationer og de virksomheder, der ejer dem. Applikationsprogrammeringsgrænseflader (API’er) er den arkitektur, der definerer denne datakommunikation, og da disse standarder er udviklet, er behandlingskravene og datalagringskravene blevet mindre besværlige.

Lederen i flokken i forhold til “let ressourceforbrug” er GraphQL, et åbent dataforespørgsel- og manipulationsprog. Dets økosystems grundlag er dets specifikation og en samling værktøjer, der er blevet skabt omkring det.

Det er ikke nyt – tiden går hurtigt. Facebook udviklede det i 2012 og brugte det kun internt til mobilapplikationsudvikling. I 2015 blev det “åbent kilde” og i dag bliver det passede af GraphQL Foundation (https://graphql.org/foundation/), der overvåger dets yderligere udvikling.

Hvorfor skriver jeg så om det nu? En typisk vej til teknologisk tilpasning vil følge følgende optagelser: 1) hobbyister/personlige projekter, 2) implementering på tværs af flere sprog, 3) implementering på tværs af start-ups og små virksomheder, 4) medium-størrelse virksomheder og brugt i produktudvikling, 5) store virksomheder og teknologigiganter.

GraphQL har nået niveau 5. I øjeblikket bruges det af GitHub, Pinterest, Shopify, Microsoft for at nævne nogle få, og senest, pr. marts 2022, Salesforce.

Da jeg ledte efter en måde at hente data mere effektivt fra Salesforce, fandt jeg deres GraphQL-dokumentation og begyndte at læse og se på måder at implementere det på.

Hvorledes adskiller det sig fra en traditionel REST API?

• En af de største fordele er, at med GraphQL kan du forespørge og kun få returneret den specifikke data. Hvis du kun vil have to felter relateret til en bestemt kundeepisode, så er det, hvad du får. En traditionel REST API ville returnere alle felter associeret med episoden. Det kunne være 100+ felter. Nu må du gøre noget med all den data, du ikke ønskede at starte med. Dette kaldes data over-fetching (under-fetching er også et problem).
• Ovennævnte gør GraphQL hurtigere end andre API-metoder, når det returnerer data.
• GraphQL er et stærkt typiseret sprog, hvilket blandt andet betyder, at kodefejl opdages, før programmet køres, og ikke under det.
• Et stort sæt værktøjer er blevet bygget omkring GraphQL, hvilket har gjort det meget udviklervenligt.
• GraphQL har ét endepunkt i modsætning til REST API, der har multiple endepunkter. Dette betyder, at all din data kan hentes i en enkelt anmodning.

To sider af mønten: anmoder (klient) og udbyder (GraphQL-vært)

Jeg har set på GraphQL indtil nu fra data-“anmod”-perspektivet. Hvor en virksomhed som Salesforce eller Microsoft har sat op en GraphQL API, som du kan bruge til at forespørge og manipulere data (læse, opdatere, tilføje).

Hvis vi som eksempel ønskede at inkludere data fra Salesforce relateret til kundeepisoder i en kundeportal, ville den mest effektive måde at gøre dette være at anmode om den præcise data, vi er efter, gennem en GraphQL-forespørgsel fra portalen til Salesforce GraphQL-serveren. Du vil få præcis den data, du ønsker, ingen under- eller over-fetching, og derfor ingen yderligere behandling eller dataopbevaring ville være nødvendig.

Den anden side af mønten er organisationen, der sætter op GraphQL-arkitekturen, så dine kunder kan have en effektiv metode til at få adgang til den data, de ønsker.

Ved at bygge GraphQL API skaber en organisation en model, der integrerer alle deres systemer i en model. Det forener disse systemer, og når arbejdet er færdigt, bliver det at forespørge data gennem API’et problemfrit.

Når jeg sammenligner applikationer eller udbydere, ser jeg på, hvilke funktioner de tilbyder mig for at få min data tilbage fra dem. Jeg ønsker ikke at skulle sende dem en e-mail eller afhænge af stive foruddefinerede rapporter. Jeg ønsker at kunne “plugge ind” i min data og forespørge den på en fleksibel og rettidig måde. Hvis det kommer ned til to applikationer/udbydere, der er ens på andre sammenligningspunkter, og en af dem tilbyder enten en REST API eller en GraphQL API, vil jeg med sikkerhed vælge den med API’et.