Hva er GraphQL?
GraphQL er et spørrespråk for API-er der klienten selv angir nøyaktig hvilke felter den vil ha, og får akkurat det i ett svar, verken mer eller mindre. Det løser problemet med å hente for mye eller for lite data, et vanlig problem i mobilapper. GraphQL er først og fremst verdt den ekstra kompleksiteten når mange klienter trenger ulike, sammensatte datavisninger.
GraphQL dukker opp i tekniske diskusjoner som et alternativ til den vanlige måten å bygge API-er på, ofte med et skjær av å være nyere og smartere. Ideen bak er faktisk enkel og løser et konkret problem, men den innebærer en kostnad som er like viktig å forstå. Her er hva GraphQL er, hvilket problem det løser, og når det er verdt kompleksiteten, uten hype.
Klienten spør, serveren svarer nøyaktig
I et vanlig API kaller klienten en ferdig adresse og får tilbake den datamengden serveren har bestemt at adressen skal gi. GraphQL snur om på dette: Her sender klienten en spørring som beskriver nøyaktig hvilke felter den vil ha, og serveren svarer med akkurat det, verken mer eller mindre.
Tenk på det som forskjellen på en fast meny og en bestilling der du spesifiserer hver detalj. I stedet for å ta imot en ferdig rett med tilbehør du kanskje ikke vil ha, ber du om nøyaktig de delene du er ute etter. Trenger appen bare navnet og e-postadressen til en bruker, spør den etter akkurat det og får ikke hele brukerposten på kjøpet.
Svaret kommer dessuten i samme form som spørringen, noe som gjør det forutsigbart. Klienten vet hva den ba om, og vet derfor hva den får tilbake.
Problemet det løser: over-fetching og under-fetching
GraphQL vokste frem av et reelt irritasjonsmoment, tydeligst i mobilapper, og det har to sider.
Over-fetching, å hente for mye, er at et kall gir mer data enn det som trengs. Appen ville ha et navn, men får hele profilen med tjue felter. Det sløser med båndbredde og batteri, og over en mobilforbindelse merkes det.
Under-fetching, å hente for lite, er det motsatte. Et kall gir for lite, så appen må gjøre flere kall og sette sammen svarene for å få det den trenger. Først en spørring om brukeren, deretter en om brukerens bestillinger, så en om innholdet i hver bestilling. Mange turer frem og tilbake gjør appen treg.
GraphQL løser begge deler på én gang. Fordi klienten ber om nøyaktig de feltene den vil ha, i ett enkelt svar, forsvinner både det overflødige og behovet for å gjøre kall på kall. En slank, sammensatt datamengde hentes i én omgang.
Et minimalt eksempel
Si at appen vil vise navnet til en bruker og titlene på brukerens siste bestillinger. Med GraphQL formulerer den én enkelt spørring som sier omtrent: Gi meg navnet til denne brukeren, og tittelen på hver bestilling. Spørringen lister bare opp de feltene.
Serveren svarer med akkurat det og ingenting annet:
- navn: Kari Nordmann
- bestillinger: «Vinterjakke», «Ryggsekk», «Vannflaske»
Ingen adresse, ingen ekstra data om brukeren, ingen separate kall for bestillingene. Klienten ba om en sammensatt visning og fikk den i ett svar, formet etter spørringen.
Når kompleksiteten er verdt det
Fleksibiliteten er reell, men den er ikke gratis. En GraphQL-server er mer kompleks å bygge og drifte og krever ekstra oppmerksomhet på både ytelse og sikkerhet nettopp fordi klienten kan stille frie spørringer. Den kostnaden må dekkes av et reelt behov for å være berettiget.
Tommelfingerregelen er at GraphQL lønner seg når mange ulike klienter trenger ulike datavisninger av den samme informasjonen. Har dere en mobilapp, en nettside og kanskje partnerintegrasjoner som hver for seg vil ha ulike felter, eller visninger som settes sammen fra flere kilder, betaler fleksibiliteten seg tilbake. Hver klient henter akkurat de riktige dataene og kan utvikles i sitt eget tempo uten at serveren hele tiden må bygge nye adresser.
Er klientene derimot få og databehovene enkle, er GraphQL sjelden verdt kompleksiteten. Da gjør et vanlig, enklere API samme nytten til lavere kostnad. Foreslår noen GraphQL, er det naturlige spørsmålet derfor: Hvilket konkret problem løser dette hos oss?
Vi i Weapp bygger både GraphQL og enklere API-er og hjelper til med å avgjøre hva som passer produktet deres. Se tjenestene våre eller ta kontakt.
Ofte stilte spørsmål
Hva betyr det at GraphQL er et spørrespråk?
At klienten formulerer en spørring som beskriver nøyaktig hvilke data den vil ha, omtrent som en bestilling med en detaljert spesifikasjon. Serveren svarer med akkurat det som ble etterspurt, i samme form som spørringen. Det skiller seg fra å bare kalle en ferdig adresse og få tilbake det serveren tilfeldigvis returnerer: Klienten styrer innholdet selv.
Hva er over-fetching og under-fetching?
Over-fetching er at et kall returnerer mer data enn det som trengs, noe som sløser med båndbredde og merkes særlig i mobilapper. Under-fetching er det motsatte: Et kall gir for lite, så det kreves flere kall for å få samlet det man trenger. Begge deler gjør apper tregere. GraphQL løser dem ved å la klienten be om nøyaktig riktig mengde i ett svar.
Er GraphQL bedre enn REST?
Ikke generelt, det avhenger av behovet. REST er enklere og holder for de fleste API-er. GraphQL kommer til sin rett når mange ulike klienter trenger ulike visninger av den samme informasjonen, men det legger til kompleksitet på serveren og i sikkerhetsarbeidet. Å velge GraphQL uten det behovet er å betale for fleksibilitet dere ikke bruker. Det handler om riktig verktøy for situasjonen.
Når lønner GraphQL seg?
Når dere har mange klienter (en mobilapp, en nettside, kanskje partnerintegrasjoner) som trenger ulike felter fra de samme dataene, eller visninger som settes sammen fra flere kilder. Da slipper hver klient både over-fetching og under-fetching og kan utvikles i sitt eget tempo. Er klientene få og behovene enkle, er GraphQL sjelden verdt den ekstra kompleksiteten det fører med seg.
Trenger jeg å forstå GraphQL som beslutningstaker?
Ikke i detalj, men det hjelper å kjenne igjen når det er aktuelt. Hvis utviklerne deres foreslår GraphQL, er det naturlig å spørre hvilket konkret problem det løser: Finnes det flere klienter med ulike databehov? Kan de peke på det, er det sannsynligvis berettiget. Kan de ikke det, er enklere REST ofte det billigere og klokere valget.