Vad är GraphQL?

För att bäst förstå vad GraphQL är måste vi först förstå var vi kommer ifrån. När man vill att två program ska prata med varandra behöver man komma överens om en gemensam standard för kommunikationen.

Det finns många olika standarder för kommunikation men en av de vanligaste på senare år är en standard som kallar för REST. Förkortningen står för “Representational State Transfer” och fokus är på att undvika att programmen behöver ta hänsyn till hur det andra programmet fungerar internt.

Det man gör istället är att man skapar ett api med så kallade “resurser” där varje resurs har sin egen url som kan anropas med olika metoder så som “POST”, “GET” eller “DELETE”. För att göra det mer konkret kan vi ta ett hypotetisk exempel där man skapat en tjänst för en inköpslista. Du kan på den här tjänsten skicka en POST-request som innehåller ordet “mjölk” till example.com/list för att lägga till mjölk till inköpslistan.

Varför behövs då GraphQL?

Det här låter ju enkelt och bra så varför skulle vi behöva GraphQL? Om man bara har ett fåtal resurser och alltid behöver samma typ av information fungerar REST utan problem. Problemet uppstår när man har många olika resurser och man behöver olika information på i olika delar av applikationen eller för olika klienter. Ett exempel är att man har en tjänst som har en webbapp och en mobil-app. Då kan det hända att man tex behöver mindre information till mobil-appen jämfört med webbappen.

Det finns olika sätt att lösa det problemet. Den enklaste lösningen är att man helt enkelt bara visar mindre information på mobilen trots att man få all information skickad till mobil-appen. Nackdelen med denna lösning är att man skickar mer information än vad som behövs vilket gör tjänsten långsammare än nödvändigt. Ett annat alternativ är att man skickar med parametrar i förfrågan med mer information om vad servern ska skicka tillbaka. Nackdelen med det är servern nu blir tvungen att ta hänsyn till det och kunna förstå dessa parametrar vilket gör API:et mindre oberoende från klienten.

GraphQL löser dessa problem genom att man tillhandahåller en enda endpoint till klienten där klienten kan specificera exakt vilken information man vill ha tillbaka. Då kan man på ett standardiserat sätt få ett API som undviker att skicka information som klienten inte behöver. Så här kan en GraphQL request till ett api för en att göra lista se ut:

query {
     todo {
       allTodos {
         id
         name
         date
       }
     }
   }

Och om du tex inte behöver datumet på en annan request kan du enkelt modifera request:en och endast hämta informationen som du behöver. Det gör du genom att bara ta bort "date" från request:en så här:

query {
     todo {
       allTodos {
         id
         name
       }
     }
   }

Finns det några nackdelar med GraphQL?

Om nu GraphQL löser dessa problem varför använder inte alla alltid GraphQL? Det finns nackdelar med GraphQL. Det är ofta lite krångligare att skapa ett GraphQL-API jmf att skapa ett REST-api så om man endast har ett fåtal resurser och alltid behöver samma typ av information är det ofta bättre att använda sig av ett REST-api. En annan nackdel med GraphQL är att det kan vara svårare att testa och hitta buggar eftersom att det blir svårare att förutse vad som händer när det är klienten som bestämmer vilken information som ska skickas.

Så när ska man använda GraphQL?

Det finns inget svar som gäller i alla sitautioner men om ditt api tex kan behöva skicka olika information till olika klienter kan GraphQL vara lämpligt att överväga.