Hvad er GraphQL?
GraphQL er et forespørgselssprog til API’er hvor klienten selv angiver præcis hvilke felter den vil have og får netop det i ét svar, hverken mere eller mindre. Det løser problemet med at hente for meget eller for lidt data, et almindeligt problem i mobilapps. GraphQL retfærdiggør sin ekstra kompleksitet primært når mange klienter har brug for forskellige, sammensatte datavisninger.
GraphQL dukker op i tekniske diskussioner som et alternativ til den almindelige måde at bygge API’er på, ofte med en aura af at være nyere og smartere. Idéen bag er faktisk enkel og løser et konkret problem, men den kommer med en omkostning som er lige så vigtig at forstå. Her er hvad GraphQL er, hvilket problem det løser og hvornår det er sin kompleksitet værd, uden hype.
Klienten spørger, serveren svarer præcist
I et almindeligt API kalder klienten en færdig adresse og får den datamængde tilbage som serveren har bestemt at den adresse skal give. GraphQL vender kontrollen om: Her sender klienten en forespørgsel der beskriver præcis hvilke felter den vil have, og serveren svarer med netop det, hverken mere eller mindre.
Tænk på det som forskellen mellem en fast menu og en bestilling hvor du specificerer hver detalje. I stedet for at tage imod en færdig ret med tilbehør du måske ikke vil have, beder du om præcis de dele du er ude efter. Har appen kun brug for en brugers navn og e-mail, spørger den efter netop det og får ikke hele brugerposten med i købet.
Svaret kommer desuden i samme form som forespørgslen, hvilket gør det forudsigeligt. Klienten ved hvad den bad om og ved derfor hvad den får tilbage.
Problemet det løser: over- og under-fetching
GraphQL opstod ud fra et reelt irritationsmoment, tydeligst i mobilapps, og det har to sider.
Over-fetching er når et kald giver flere data end der er brug for. Appen ville have et navn, men får hele profilen med tyve felter. Det spilder båndbredde og batteri, og over en mobilforbindelse kan det mærkes.
Under-fetching er det modsatte. Et kald giver for lidt så appen skal lave flere kald og stykke svarene sammen for at få det den har brug for. Først en forespørgsel om brugeren, så en om brugerens ordrer, så en om hver ordres indhold. Mange ture frem og tilbage gør appen langsom.
GraphQL løser begge dele på én gang. Fordi klienten beder om præcis de felter den vil have, i ét enkelt svar, forsvinder både det overflødige og behovet for at stable kald oven på hinanden. En slank, sammensat datamængde hentes i ét hug.
Et minimalt eksempel
Lad os sige at appen vil vise en brugers navn og titlerne på brugerens seneste ordrer. Med GraphQL formulerer den én enkelt forespørgsel der cirka siger: Giv mig denne brugers navn, og for hver ordre titlen. Forespørgslen oplister kun de felter.
Serveren svarer med netop det og intet andet:
- navn: Anna Hansen
- ordrer: “Vinterjakke”, “Rygsæk”, “Vandflaske”
Ingen adresse, ingen ekstra data om brugeren, ingen separate kald for ordrerne. Klienten bad om en sammensat visning og fik den i ét svar, formet efter forespørgslen.
Hvornår kompleksiteten er det værd
Fleksibiliteten er reel, men den er ikke gratis. En GraphQL-server er mere kompleks at bygge og drifte og kræver ekstra omhu med både ydeevne og sikkerhed, netop fordi klienten kan stille frie forespørgsler. Der skal et reelt behov til for at den omkostning er begrundet.
Tommelfingerreglen er at GraphQL betaler sig når mange forskellige klienter har brug for forskellige datavisninger af de samme oplysninger. Har I en mobilapp, en webløsning og måske partnerintegrationer der hver især vil have forskellige felter, eller visninger der sættes sammen fra flere kilder, så tjener fleksibiliteten sig hjem. Hver klient henter præcis de rigtige data og kan udvikles i sit eget tempo uden at serveren hele tiden skal bygge nye adresser.
Er klienterne derimod få og databehovene enkle, retfærdiggør GraphQL sjældent sin kompleksitet. Så gør et almindeligt, enklere API samme nytte til en lavere omkostning. Foreslår nogen GraphQL, er det rimelige spørgsmål derfor: Hvilket konkret problem løser det her hos os?
Vi hos Weapp bygger både GraphQL og enklere API’er og hjælper med at afgøre hvad der passer til jeres produkt. Se vores ydelser eller kontakt os.
Ofte stillede spørgsmål
Hvad betyder det at GraphQL er et forespørgselssprog?
At klienten formulerer en forespørgsel som beskriver præcis hvilke data den vil have, lidt som en bestilling med en detaljeret specifikation. Serveren svarer med netop det der blev spurgt efter, i samme form som forespørgslen. Det adskiller sig fra bare at kalde en færdig adresse og få tilbage hvad serveren nu tilfældigvis returnerer: Klienten styrer selv indholdet.
Hvad er over-fetching og under-fetching?
Over-fetching er når et kald returnerer flere data end der er brug for, hvilket spilder båndbredde, især mærkbart i mobilapps. Under-fetching er det modsatte: Et kald giver for lidt så der kræves flere kald for at samle det der er brug for. Begge dele gør apps langsommere. GraphQL løser dem ved at lade klienten bede om præcis den rigtige mængde i ét svar.
Er GraphQL bedre end REST?
Ikke generelt, det afhænger af behovet. REST er enklere og rækker til de fleste API’er. GraphQL kommer til sin ret når mange forskellige klienter har brug for forskellige datavisninger af de samme oplysninger, men tilføjer kompleksitet i serveren og i sikkerhedsarbejdet. At vælge GraphQL uden det behov er at betale for fleksibilitet I ikke bruger. Det handler om det rigtige værktøj til situationen.
Hvornår betaler GraphQL sig?
Når I har mange klienter (en mobilapp, en webløsning, måske partnerintegrationer) der har brug for forskellige felter fra de samme data, eller visninger der sættes sammen fra flere kilder. Så slipper hver klient for over- eller under-fetching og kan udvikles i sit eget tempo. Er klienterne få og behovene enkle, retfærdiggør GraphQL sjældent den ekstra kompleksitet det fører med sig.
Behøver jeg at forstå GraphQL som beslutningstager?
Ikke i detaljer, men det hjælper at kunne genkende hvornår det er det rigtige spørgsmål. Hvis jeres udviklere foreslår GraphQL, er det rimeligt at spørge hvilket konkret problem det løser: Er der flere klienter med forskellige databehov? Kan de pege på det, er det sandsynligvis begrundet. Kan de ikke, er det enklere REST ofte det billigere og klogere valg.