REST eller GraphQL?

Få tekniska val blir så laddade som REST mot GraphQL. Det talas om dem nästan som livsåskådningar, men för den som ska bygga en produkt är frågan mer nykter: vilket sätt att bygga API:et ger minst krångel för det behov ni faktiskt har? Här är skillnaderna i praktiska konsekvenser, utan religion – och en tydlig rekommendation att utgå från.

Vad de två faktiskt gör

Ett API är kontaktytan där system hämtar och skickar data. REST och GraphQL är två olika sätt att utforma den ytan.

Med REST anropar klienten färdiga adresser, endpoints, som var och en returnerar en bestämd datamängd. Vill appen ha en användare hämtar den en adress för användare; vill den ha användarens beställningar hämtar den en annan. Servern bestämmer vad varje adress returnerar, och strukturen är förutsägbar.

Med GraphQL finns i stället en enda ingång dit klienten skickar en fråga om exakt de fält den vill ha. Behöver appen bara en användares namn och e-post frågar den efter just det, i ett enda anrop, och får inte mer. Kontrollen över vad som hämtas flyttas från servern till klienten.

När GraphQL lyser

GraphQL löser ett konkret problem: att olika klienter behöver olika vyer av samma data. En mobilapp vill ha en liten, bantad datamängd för att spara på uppkoppling. En webb vill ha mer. En partnerintegration vill ha något helt annat. Med REST tenderar detta att leda till antingen många specialanpassade endpoints eller till att alla hämtar för mycket eller för lite.

Här är GraphQL i sitt esse. Varje klient frågar efter precis det den behöver, och nya behov kan ofta mötas utan att servern måste bygga en ny endpoint varje gång. Har ni flera olika konsumenter av samma data som utvecklas i olika takt, ger det en flexibilitet som REST har svårt att matcha.

Vad GraphQL kostar

Den flexibiliteten är inte gratis. En GraphQL-server är mer komplex att bygga och drifta, och komplexiteten koncentreras till två områden.

Det första är prestanda. När klienten fritt kan fråga efter djupt nästlad data kan en enda till synes oskyldig fråga tvinga servern att göra tungt arbete. Att skydda sig mot det kräver medvetet arbete som REST sällan tvingar fram.

Det andra är säkerhet. Med fria frågor måste åtkomsten styras noggrant, ofta fält för fält, så att en klient inte kan fråga sig till data den inte får se. Ytan att tänka igenom blir större. Till detta kommer att cachning – att spara svar för att slippa räkna om dem – är enkelt och väl beprövat i REST via webbens egen infrastruktur, men mer involverat i GraphQL.

Rekommendationen: REST som default

Väg samman detta och en tydlig hållning framträder: använd REST som förval, och nå efter GraphQL först när behovet är bevisat. REST räcker för de allra flesta API:er, kostar minst i komplexitet och vilar på en mogen verktygskedja som de flesta utvecklare redan behärskar. Enkel cachning och förutsägbar struktur är värden man inte ska ge upp utan skäl.

GraphQL blir rätt när du kan peka på det faktiska problemet det löser – flera klienter med olika datavyer som annars leder till krångel. Kan du inte det, lägger GraphQL till server- och säkerhetskomplexitet utan att betala tillbaka det.

Valet behöver inte heller gälla hela systemet. Många produkter kör REST för det mesta och lägger till GraphQL just där flera klienter kräver flexibilitet. Det kan avgöras per behov snarare än som en trosfråga.

Vi på Weapp bygger båda och hjälper till att avgöra vilket som passar er produkt – utan att välja sida på förhand. Titta på våra tjänster eller hör av dig, så tittar vi på era faktiska behov och landar i rätt val.