GraphQL – Endrer og Forbedrer Måten Applikasjoner Kommuniserer

Det vil ikke vare lenge før den neste generasjonen kjøper krypto og sjekker sin enhets tillitsbalanse i Fortnite-lobbien mellom spill. Dette vil bli mulig gjennom mange teknologiske fremganger.

Den ene vi diskuterer i dag er måten data overføres (les, oppdatert, lagt til / fjernet) mellom applikasjoner og selskapene som eier dem. Applikasjonsprogrammeringsgrensesnitt (API) er arkitekturen som definerer denne datakommunikasjonen, og når disse standardene har utviklet seg, har behandlingskravene og datalagringskravene blitt mindre plagsomme.

Lederen i pakken når det gjelder “lett” ressursbruk er GraphQL, et åpen kildekode dataforespørsel og manipulasjonsspråk. Dets økosystems grunnlag er dens spesifikasjon og en samling verktøy som har blitt skapt rundt det.

Det er ikke nytt – tiden går raskt. Facebook utviklet det i 2012 og brukte det bare internt for mobilapplikasjonsutvikling. I 2015 ble det “åpen kildekode” og i dag blir det ivaretatt av GraphQL Foundation (https://graphql.org/foundation/) som overvåker dens videre utvikling.

Hvorfor skriver jeg om det nå? En typisk veikart til en teknologisk tilpasning vil følge følgende oppakning 1) hobbyister / personlige prosjekter, 2) implementering over flere språk, 3) implementeringer over start-ups og små selskaper, 4) mellomstore selskaper og brukt i produktutvikling, 5) store konserner og teknologigiganter.

GraphQL har nådd nivå 5. For tiden brukes det av GitHub, Pinterest, Shopify, Microsoft for å nevne noen, og sist, fra mars 2022, Salesforce.

I jakten på en måte å hente data mer effektivt fra Salesforce kom jeg over deres GraphQL-dokumentasjon og begynte å lese og se på måter å implementere det på.

Hvordan skiller det seg fra en tradisjonell REST API?

• En av de største fordelene er at med GraphQL kan du forespørre og bare få returnert den spesifikke dataen. Hvis du bare ønsker to felt relatert til en bestemt kundeepisode, så er det det du får. En tradisjonell REST API ville returnere alle feltene assosiert med episoden. Det kunne være 100+ felt. Nå må du gjøre noe med all den dataen du ikke ønsket fra starten. Dette kalles data over fetching (under fetching er også et problem).
• Ovennevnte gjør GraphQL raskere enn andre API-metodologier når det returneres data.
• GraphQL er et sterkt typet språk som blant annet betyr at kodefeil blir fanget opp før programmet kjøres og ikke under det.
• En stor samling verktøy har blitt bygget rundt GraphQL, noe som har gjort det svært utviklervennlig.
• GraphQL har ett enkelt endepunkt i motsetning til REST API, som har flere endepunkter. Dette betyr at all din data kan hentes i ett enkelt forespørsel.

To sider av mynten: forespørrende (klient) og tilbyder (GraphQL-host)

Jeg har sett på GraphQL så langt fra data “forespørsel” perspektivet. Hvor et selskap som Salesforce eller Microsoft har satt opp en GraphQL API som du kan bruke til å forespørre og manipulere data (lese, oppdatere, legge til).

For eksempel, hvis vi ønsket å inkludere data fra Salesforce relatert til kundeepisoder i en kundeportal, ville den mest effektive måten å gjøre dette være å forespørre den eksakte dataen vi er ute etter gjennom en GraphQL-forespørsel fra portalen til Salesforce GraphQL-serveren. Du vil få eksakt den dataen du ønsker, ingen under eller over fetching og som resultat ingen ekstra prosessering eller datalagring ville være nødvendig.

Den andre siden av mynten er organisasjonen som setter opp GraphQL-arkitekturen så at dine kunder kan ha en effektiv metode for å få tilgang til den dataen de ønsker.

Ved å bygge GraphQL API skaper en organisasjon en modell som integrerer alle deres systemer i én modell. Den forener disse systemene og når arbeidet er fullført, blir det å forespørre dataen enkelt gjennom API-en.

Når jeg sammenligner applikasjoner eller tilbydere, ser jeg på hva funksjoner de tilbyr meg for å få tilbake min data fra dem. Jeg ønsker ikke å måtte sende e-post til dem eller være avhengig av stive forhåndsdefinerte rapporter. Jeg ønsker å kunne “plugge inn” i min data og forespørre den på en fleksibel og tidsmessig måte. Hvis det kommer ned til to applikasjoner / tilbydere og de er like godt matchet på andre sammenligningspunkter, og en av dem tilbyr enten en REST API eller en GraphQL API, vil jeg uten tvil velge den med API-en.