REST eller GraphQL?
REST er enklere, har en moden verktøykjede og enkel caching, og er et trygt førstevalg for de fleste API-er. GraphQL kommer til sin rett når mange ulike klienter trenger ulike datavisninger, men gir mer kompleksitet på serveren og i sikkerhetsarbeidet. Anbefalingen er REST som standard og GraphQL først ved et bevist behov.
Få tekniske valg blir så ladet som REST mot GraphQL. Det snakkes om dem nesten som livssyn, men for den som skal bygge et produkt, er spørsmålet mer nøkternt: Hvilken måte å bygge API-et på gir minst trøbbel for det behovet dere faktisk har? Her er forskjellene i praktiske konsekvenser, uten religiøs iver, og til slutt en tydelig anbefaling dere kan ta utgangspunkt i.
Hva de to faktisk gjør
Et API er kontaktflaten der systemer henter og sender data. REST og GraphQL er to ulike måter å utforme den flaten på.
Med REST gjør klienten kall mot ferdige adresser, endepunkter, som hver for seg returnerer en bestemt datamengde. Vil appen ha en bruker, henter den fra en adresse for brukere. Vil den ha brukerens bestillinger, henter den fra en annen. Serveren bestemmer hva hver adresse returnerer, og strukturen er forutsigbar.
Med GraphQL finnes det i stedet én enkelt inngang der klienten sender en spørring etter nøyaktig de feltene den vil ha. Trenger appen bare navnet og e-postadressen til en bruker, spør den etter akkurat det, i ett kall, og får ikke mer. Kontrollen over hva som hentes, flyttes fra serveren til klienten.
Når GraphQL kommer til sin rett
GraphQL løser et konkret problem: at ulike klienter trenger ulike visninger av de samme dataene. En mobilapp vil ha en liten, slanket datamengde for å spare på dataoverføringen. En nettside vil ha mer. En partnerintegrasjon vil ha noe helt annet. Med REST fører dette gjerne enten til mange spesialtilpassede endepunkter eller til at alle henter for mye eller for lite.
Her er GraphQL i sitt ess. Hver klient spør etter akkurat det den trenger, og nye behov kan ofte dekkes uten at serveren må bygge et nytt endepunkt hver gang. Har dere flere ulike konsumenter av de samme dataene som utvikles i ulikt tempo, gir det en fleksibilitet REST har vanskelig for å matche.
Hva GraphQL koster
Den fleksibiliteten er ikke gratis. En GraphQL-server er mer kompleks å bygge og drifte, og kompleksiteten samles på to områder.
Det første er ytelse. Når klienten fritt kan spørre etter dypt nøstede data, kan én enkelt, tilsynelatende uskyldig spørring tvinge serveren til å gjøre tungt arbeid. Å beskytte seg mot det krever en bevisst innsats som REST sjelden tvinger frem.
Det andre er sikkerhet. Med frie spørringer må tilgangen ofte styres nøye felt for felt slik at en klient ikke kan spørre seg frem til data den ikke har lov til å se. Flaten som må tenkes gjennom, blir større. I tillegg er caching, altså å lagre svar så man slipper å beregne dem på nytt, enkelt og velprøvd i REST via nettets egen infrastruktur, men mer krevende i GraphQL.
| Aspekt | Sterkest |
|---|---|
| Enkelt å bygge og drifte | REST |
| Caching og modne verktøy | REST |
| Fleksible datavisninger for mange klienter | GraphQL |
| Færre kall for sammensatte data | GraphQL |
Anbefalingen: REST som standard
Veier man dette sammen, trer en tydelig holdning frem: Bruk REST som førstevalg, og ty til GraphQL først når behovet er bevist. REST holder for de aller fleste API-er, koster minst i kompleksitet og hviler på en moden verktøykjede som de fleste utviklere allerede behersker. Enkel caching og forutsigbar struktur er verdier man ikke bør gi fra seg uten grunn.
GraphQL blir riktig når du kan peke på det faktiske problemet det løser: flere klienter med ulike datavisninger som ellers fører til trøbbel. Kan du ikke det, legger GraphQL til kompleksitet på server- og sikkerhetssiden uten at det betaler seg.
Valget trenger heller ikke å gjelde hele systemet. Mange produkter bruker REST for det meste og legger til GraphQL akkurat der flere klienter krever fleksibilitet. Det kan avgjøres per behov snarere enn som et trosspørsmål.
Vi i Weapp bygger begge deler og hjelper dere med å avgjøre hva som passer produktet deres, uten å velge side på forhånd. Se tjenestene våre eller ta kontakt, så ser vi på de faktiske behovene deres og finner riktig valg.
Ofte stilte spørsmål
Hva er den praktiske forskjellen på REST og GraphQL?
Med REST gjør klienten kall mot ferdige adresser som hver for seg returnerer en bestemt datamengde. Med GraphQL ber klienten selv om nøyaktig de feltene den vil ha, i ett kall. GraphQL gir klienten mer kontroll over hva som hentes, mens REST gir serveren mer kontroll og en enklere, mer forutsigbar struktur.
Når er GraphQL riktig valg?
Når mange ulike klienter trenger ulike visninger av de samme dataene, for eksempel en mobilapp, en nettside og kanskje en partnerintegrasjon som hver vil ha forskjellige felt. Da løser GraphQL problemet med å hente for mye eller for lite, og klientene kan utvikles uten at serveren stadig trenger nye endepunkter.
Hva koster GraphQL i ekstra kompleksitet?
En GraphQL-server er mer kompleks å bygge og drifte. Fordi klienten kan stille frie spørringer, kreves det mer arbeid med ytelse og sikkerhet: at én enkelt spørring ikke kan overbelaste serveren, og at tilgangen styres riktig felt for felt. Caching, som er enkelt i REST, blir også mer krevende.
Hvorfor anbefales REST som standard?
Fordi det holder i de fleste tilfeller og koster minst. REST har en moden verktøykjede, enkel caching via nettets infrastruktur og en struktur de fleste utviklere kjenner. Hvis behovet for fleksible datavisninger ikke er bevist, legger GraphQL til kompleksitet uten å løse et reelt problem, og da er REST det billigere valget.
Kan man bruke både REST og GraphQL?
Ja, det er vanlig. Mange produkter har et REST-API for det meste og legger til GraphQL akkurat der flere klienter trenger fleksible datavisninger, eller omvendt. Valget trenger ikke å være et trosspørsmål for hele systemet. Det kan avgjøres per behov, der hver del bruker det som passer den best.