Vad är GraphQL?
GraphQL är ett frågespråk för API:er där klienten själv anger exakt vilka fält den vill ha och får precis det i ett svar – varken mer eller mindre. Det löser problemet med att hämta för mycket eller för lite data, vanligt i mobilappar. GraphQL motiverar sin extra komplexitet främst när många klienter behöver olika, sammansatta datavyer.
GraphQL dyker upp i teknikdiskussioner som ett alternativ till det vanliga sättet att bygga API:er, ofta med en aura av att vara nyare och smartare. Idén bakom är faktiskt enkel och löser ett konkret problem, men den kommer med en kostnad som är lika viktig att förstå. Här är vad GraphQL är, vilket problem det löser och när det är värt sin komplexitet – utan hype.
Klienten frågar, servern svarar exakt
I ett vanligt API anropar klienten en färdig adress och får tillbaka den datamängd servern bestämt att den adressen ska ge. GraphQL vänder på kontrollen: här skickar klienten en fråga som beskriver exakt vilka fält den vill ha, och servern svarar med precis det – varken mer eller mindre.
Tänk på det som skillnaden mellan en fast meny och en beställning där du specificerar varje detalj. I stället för att ta emot en färdig rätt med tillbehör du kanske inte vill ha, ber du om exakt de delar du är ute efter. Behöver appen bara en användares namn och e-post frågar den efter just det, och får inte hela användarposten på köpet.
Svaret kommer dessutom i samma form som frågan, vilket gör det förutsägbart. Klienten vet vad den bad om och vet därför vad den får tillbaka.
Problemet det löser: över- och underhämtning
GraphQL uppstod ur ett verkligt irritationsmoment, tydligast i mobilappar, och det har två sidor.
Överhämtning är att ett anrop ger mer data än vad som behövs. Appen ville ha ett namn men får hela profilen med tjugo fält. Det slösar bandbredd och batteri, och över en mobiluppkoppling märks det.
Underhämtning är motsatsen. Ett anrop ger för lite, så appen måste göra flera anrop och pussla ihop svaren för att få det den behöver. Först en fråga om användaren, sedan en om användarens beställningar, sedan en om varje beställnings innehåll. Många turer fram och tillbaka gör appen långsam.
GraphQL löser båda på en gång. Eftersom klienten ber om exakt de fält den vill ha, i ett enda svar, försvinner både det överflödiga och behovet av att stapla anrop. En bantad, sammansatt datamängd hämtas i ett svep.
Ett minimalt exempel
Säg att appen vill visa en användares namn och titlarna på användarens senaste beställningar. Med GraphQL formulerar den en enda fråga som säger ungefär: ge mig den här användarens namn, och för varje beställning titeln. Frågan listar bara de fälten.
Servern svarar med precis det, och ingenting annat:
- namn: Anna Svensson
- beställningar: “Vinterjacka”, “Ryggsäck”, “Vattenflaska”
Ingen adress, ingen extra data om användaren, inga separata anrop för beställningarna. Klienten bad om en sammansatt vy och fick den i ett svar, format efter frågan.
När komplexiteten är värd det
Flexibiliteten är verklig, men den är inte gratis. En GraphQL-server är mer komplex att bygga och drifta, och kräver extra omsorg om både prestanda och säkerhet just för att klienten kan ställa fria frågor. Den kostnaden ska betalas av ett verkligt behov för att vara motiverad.
Tumregeln är att GraphQL lönar sig när många olika klienter behöver olika datavyer av samma information. Har ni en mobilapp, en webb och kanske partnerintegrationer som var och en vill ha olika fält, eller vyer som sätts samman ur flera källor, då betalar flexibiliteten tillbaka sig. Varje klient hämtar precis rätt data och kan utvecklas i egen takt utan att servern ständigt måste bygga nya adresser.
Är klienterna däremot få och databehoven enkla, motiverar GraphQL sällan sin komplexitet. Då gör ett vanligt, enklare API samma nytta till lägre kostnad. Föreslår någon GraphQL är därför den rimliga frågan: vilket konkret problem löser det här hos oss?
Vi på Weapp bygger både GraphQL och enklare API:er och hjälper till att avgöra vad som passar er produkt. Titta på våra tjänster eller hör av dig.
Vanliga frågor
Vad betyder det att GraphQL är ett frågespråk?
Att klienten formulerar en fråga som beskriver exakt vilken data den vill ha, ungefär som en beställning med en detaljerad specifikation. Servern svarar med precis det som efterfrågades, i samma form som frågan. Det skiljer sig från att bara anropa en färdig adress och få tillbaka vad servern nu råkar returnera – klienten styr innehållet själv.
Vad är över- och underhämtning?
Överhämtning är att ett anrop returnerar mer data än vad som behövs, vilket slösar bandbredd – särskilt kännbart i mobilappar. Underhämtning är motsatsen: ett anrop ger för lite, så flera anrop krävs för att få ihop det som behövs. Båda gör appar långsammare. GraphQL löser dem genom att låta klienten be om exakt rätt mängd i ett svar.
Är GraphQL bättre än REST?
Inte generellt, det beror på behovet. REST är enklare och räcker för de flesta API:er. GraphQL lyser när många olika klienter behöver olika datavyer av samma information, men adderar komplexitet i servern och säkerhetsarbetet. Att välja GraphQL utan det behovet är att betala för flexibilitet ni inte använder. Det handlar om rätt verktyg för situationen.
När lönar sig GraphQL?
När ni har många klienter – en mobilapp, en webb, kanske partnerintegrationer – som behöver olika fält ur samma data, eller vyer som sätts samman från flera källor. Då slipper varje klient över- eller underhämtning och kan utvecklas i egen takt. Är klienterna få och behoven enkla motiverar GraphQL sällan den extra komplexiteten det för med sig.
Behöver jag förstå GraphQL som beslutsfattare?
Inte i detalj, men det hjälper att känna igen när det är rätt fråga. Om era utvecklare föreslår GraphQL är det rimligt att fråga vilket konkret problem det löser – finns flera klienter med olika databehov? Kan de peka på det, är det troligen motiverat. Kan de inte, är enklare REST ofta det billigare och klokare valet.