REST eller GraphQL?
REST er enklere, har en moden værktøjskæde og nem caching, hvilket gør det til et trygt standardvalg for de fleste API’er. GraphQL kommer til sin ret når mange forskellige klienter har brug for forskellige datavisninger, men tilføjer kompleksitet i serveren og i sikkerhedsarbejdet. Anbefalingen er REST som standard og GraphQL først ved et påvist behov.
Få tekniske valg bliver så ladede som REST over for GraphQL. Der tales om dem næsten som livsanskuelser, men for den der skal bygge et produkt, er spørgsmålet mere nøgternt: Hvilken måde at bygge API’et på giver mindst bøvl for det behov I faktisk har? Her er forskellene i praktiske konsekvenser, uden religion, og med en klar anbefaling at tage udgangspunkt i.
Hvad de to faktisk gør
Et API er kontaktfladen hvor systemer henter og sender data. REST og GraphQL er to forskellige måder at udforme den flade på.
Med REST kalder klienten faste adresser, endpoints, som hver returnerer en bestemt mængde data. Vil appen have en bruger, henter den en adresse for brugere; vil den have brugerens ordrer, henter den en anden. Serveren bestemmer hvad hver adresse returnerer, og strukturen er forudsigelig.
Med GraphQL findes der i stedet én enkelt indgang, og dertil sender klienten en forespørgsel om præcis de felter den vil have. Har appen kun brug for en brugers navn og e-mail, spørger den efter netop det, i ét enkelt kald, og får ikke mere. Kontrollen over hvad der hentes, flyttes fra serveren til klienten.
Når GraphQL kommer til sin ret
GraphQL løser et konkret problem: at forskellige klienter har brug for forskellige visninger af de samme data. En mobilapp vil have en lille, slanket datamængde for at spare på forbindelsen. En webapp vil have mere. En partnerintegration vil have noget helt andet. Med REST fører det typisk enten til mange specialtilpassede endpoints eller til at alle henter for meget eller for lidt.
Her er GraphQL i sit es. Hver klient spørger efter præcis det den har brug for, og nye behov kan ofte imødekommes uden at serveren skal bygge et nyt endpoint hver gang. Har I flere forskellige forbrugere af de samme data som udvikler sig i forskelligt tempo, giver det en fleksibilitet som REST har svært ved at matche.
Hvad GraphQL koster
Den fleksibilitet er ikke gratis. En GraphQL-server er mere kompleks at bygge og drifte, og kompleksiteten samler sig på to områder.
Det første er ydeevne. Når klienten frit kan spørge efter dybt indlejrede data, kan én enkelt tilsyneladende uskyldig forespørgsel tvinge serveren til at udføre tungt arbejde. At beskytte sig mod det kræver en bevidst indsats som REST sjældent tvinger frem.
Det andet er sikkerhed. Med frie forespørgsler skal adgangen styres omhyggeligt, ofte felt for felt, så en klient ikke kan spørge sig frem til data den ikke må se. Fladen der skal tænkes igennem, bliver større. Dertil kommer at caching, altså at gemme svar for at slippe for at beregne dem igen, er enkelt og velafprøvet i REST via nettets egen infrastruktur, men mere indviklet i GraphQL.
| Aspekt | Stærkest |
|---|---|
| Enkelt at bygge og drifte | REST |
| Caching og værktøjernes modenhed | REST |
| Fleksible datavisninger til mange klienter | GraphQL |
| Færre kald for sammensatte data | GraphQL |
Anbefalingen: REST som standard
Læg det sammen, og en klar holdning træder frem: Brug REST som standardvalg, og ræk først ud efter GraphQL når behovet er påvist. REST rækker til langt de fleste API’er, koster mindst i kompleksitet og hviler på en moden værktøjskæde som de fleste udviklere allerede behersker. Enkel caching og forudsigelig struktur er værdier man ikke skal opgive uden grund.
GraphQL bliver det rigtige valg når du kan pege på det faktiske problem det løser: flere klienter med forskellige datavisninger som ellers fører til bøvl. Kan du ikke det, tilføjer GraphQL server- og sikkerhedskompleksitet som ikke tjener sig hjem.
Valget behøver heller ikke at gælde hele systemet. Mange produkter kører REST til det meste og tilføjer GraphQL netop der hvor flere klienter kræver fleksibilitet. Det kan afgøres behov for behov snarere end som et trosspørgsmål.
Vi hos Weapp bygger begge dele og hjælper med at afgøre hvad der passer til jeres produkt uden at vælge side på forhånd. Se vores ydelser eller kontakt os, så kigger vi på jeres faktiske behov og når frem til det rigtige valg.
Ofte stillede spørgsmål
Hvad er den praktiske forskel på REST og GraphQL?
Med REST kalder klienten faste adresser som hver returnerer en bestemt mængde data. Med GraphQL spørger klienten selv efter præcis de felter den vil have, i ét enkelt kald. GraphQL giver klienten mere kontrol over hvad der hentes mens REST giver serveren mere kontrol og en enklere, mere forudsigelig struktur.
Hvornår er GraphQL det rigtige valg?
Når mange forskellige klienter har brug for forskellige visninger af de samme data: en mobilapp, en webapp og måske en partnerintegration der hver vil have forskellige felter. Så fjerner GraphQL problemet med at hente for meget eller for lidt, og klienterne kan udvikles uden at serveren hele tiden skal have nye endpoints.
Hvad koster GraphQL i ekstra kompleksitet?
En GraphQL-server er mere kompleks at bygge og drifte. Fordi klienten kan stille frie forespørgsler, kræves der mere arbejde med ydeevne og sikkerhed: at én enkelt forespørgsel ikke trækker serveren ned, og at adgangen styres korrekt felt for felt. Caching, som er enkelt i REST, bliver også mere indviklet.
Hvorfor anbefales REST som standard?
Fordi det rækker i de fleste tilfælde og koster mindst. REST har en moden værktøjskæde, enkel caching via nettets egen infrastruktur og en struktur som de fleste udviklere kender. Hvis behovet for fleksible datavisninger ikke er påvist, tilføjer GraphQL kompleksitet uden at løse et reelt problem, og så er REST det billigere valg.
Kan man bruge både REST og GraphQL?
Ja, det er almindeligt. Mange produkter har et REST-API til det meste og tilføjer GraphQL netop der hvor flere klienter har brug for fleksible datavisninger, eller omvendt. Valget behøver ikke at være et trosspørgsmål for hele systemet. Det kan afgøres behov for behov, hvor hver del bruger det der passer den bedst.