Ämnesområden

Vad är GraphQL?

GraphQL är i grunden ett frågespråk (skapat av Facebook) för att hämta och ändra data på en server, och för att prenumerera på ändringar. I stället för att göra flera olika API-anrop, som i REST, så ställs en fråga efter alla data som behövs. Det innebär avsevärt färre API-anrop än med till exempel REST och gör det enklare för utvecklare att bygga applikationer med riktigt bra prestanda.

Det som utmärker GraphQL är att språket använder en beskrivning av den data du vill hämta i ditt API och i sin tur får du tillbaka exakt det du förfrågar om. 

Men för att förstå GraphQL är så måste man först förstå REST. 

REST vad är det?

Representational State Transfer (REST) eller RESTful webbtjänst är ett IT-arkitekturbegrepp som beskriver hur tjänster för maskin-till-maskin-kommunikation kan tillhandahållas via webbteknologi. Begreppet härrör från en avhandling av Roy Fielding, en av författarna till HTTP-specifikationen och har fått en snabb spridning inom systemutvecklingsområdet genom sin enkelhet. 

Med REST-API:er är det möjligt att läsa, hämta, uppdatera och radera data på en server genom en webbklient. Webbklienten gör då ett HTTP-anrop på servern som sedan svarar med status på om anropet har lyckats eller inte. När denna process sker interagerar webbklienten och servern utan att känna till varandra.

Att klienten och servern är oberoende av varandra är en av flera fördelar med ett REST-API. Det är enkelt att bygga och det kan användas av många utvecklare eftersom det är språkoberoende.

Oberoendet minskar behovet av specialiserade utvecklare. Det ger även möjlighet till cache av data för ökad prestanda. Det vill säga att första gången ett anrop görs kan svaret från servern sparas på klienten för upprepat bruk. Görs anropet flera gånger hämtas data direkt från klienten istället för på servern.

En nackdel med REST är att det är svårt att hämta specifik data utan flera anrop till servern. För att exempelvis hämta ut en lista med titeln och brödtexten på en användares inlägg på en blogg kan det krävas flera anrop till servern.

Först görs ett anrop för att hämta själva användaren. Sedan ett till anrop för att hämta inläggen och dess data. Att inte kunna hämta specifikt data utan flera anrop kan leda till ett överskott av data där du utöver titeln och texten på inläggen även får irrelevant information för ditt ändamål.

Likaså kan det leda till ett underskott av data. Om anropet på inläggen enbart hade gett ut en lista på inläggens id:n, hade ett tredje anrop behövts för att hämta ut datan du vill åt.

Under utvecklingen av en webbapplikation där många anrop görs kan detta göra REST-strukturen mer komplex. Antalet anrop påverkar också prestandan på enheterna som applikationen körs på. En långsam server behöver mer tid på sig att svara och en långsam enhet behöver mer tid att både hämta och visa ut svaret. 

Mer om GraphQL

Typisk användning är där en webbläsare först hämtar och fyller i en webbsida med användaranpassad information, sedan sänder tillbaka ändringar utifrån användarens inmatning och sedan fortlöpande mottar rapporterar från servern när relevant information ändrats. Främsta unika egenskap är frågespråket som kan efterfråga hierarkiska data med relationer och få dessa i urval levererade i samma struktur som de efterfrågas.

För att förklara GraphQL kan nedan bild användas. Cirklarna i bilden nedan kallas för “nodes” och linjerna emellan vi ser representerar “edges”, vilket ansluter två noder sinsemellan och skapar en relation. Med hjälp av GraphQL kan vilken data som helst i nedanstående figur hanteras i en och samma fråga.

Publicering och dokumentation av GraphQL-API:er

Med GraphQL Schema Definition Language (SDL) kan API:et visualiseras och överblickas enklare. Det finns flera verktyg för detta:

graphqlviz

https://github.com/sheerun/graphqlviz
https://raw.githubusercontent.com/sheerun/graphqlviz/master/demo.gif

GraphQL Visualizer

http://nathanrandal.com/graphql-visualizer

GraphQL Voyager

https://github.com/APIs-guru/graphql-voyager
https://raw.githubusercontent.com/APIs-guru/graphql-voyager/master/docs/demo-gif.gif 

När och för vem är REST bäst?

– När API:t skapas för en känd klient: Klientens behov av data är känt och ett skräddarsytt API effektiviserar utveckling och användning.

– När klienten eller dess utvecklare behöver ett enkelt gränssnitt: Flexibiliteten hos frågespråket behövs inte, utan komplicerar för vissa utvecklare eller typer av klienter.

– När andra datatyper än text behöver hämtas direkt: GraphQL har inte stöd för andra mediatyper än text, till exempel bilder, video, ljud, binärdata.

– När klientens behov av data styrs av en eller få och kända parametrar, till exempel datum, sorteringsordning och antal. Domänen och dess data kan vara så enkel till sin natur att få och enkla REST-anrop är optimalt.

– När klientens behov av data inte ändras till sin struktur, till exempel att samma sorts objekt hämtas och merparten av dess egenskaper används: Vissa tjänster och data är hård förankrade i standarder eller hävd och har därför låg förändringsgrad.

När är och för vem är GraphQL bäst?

– När klientens behov av objektens parametrar varierar, till exempel då bara få parametrar i stora objekt behövs: Om data behöver samlas ihop från flera typer av objekt måste ett REST-API skräddarsys för detta för att undvika onödig belastning på server och nätverk.

– När klientens behov av urval av objekt varierar eller är avancerat, till exempel urval via relationer mellan objekt: Domänen är komplex till struktur och har potentiellt hög omsättning av data, aktiv utveckling av server- och klientdel kan bromsas av fasta API:er.

– När klienten behöver göra följdfrågor mot servern baserat på en tidigare hämtning: Då data har djup struktur och/eller relationer mellan dessa eller då urvalskriterier är många eller har komplexa villkor.

Nackdelar med GraphQL

– GraphQL har inte stöd för cache.

– Datan som hämtas renderas bara i JSON-format.

– Det anses svårare att hantera fel med GraphQL.

– GraphQL är en ”relativt” ny teknik vilket gör att många CMS, affärssystem och andra applikationer fortfarande saknar stöd för GraphQL. Men det kommer, till exempel hos Sage X3 affärssystem. Läs mer om Sage X3 och GraphQL API här >

Användbara länkar

Bra och heltäckande av GraphQL finns här: https://www.howtographql.com/

Jämför Swagger och GraphQL här: http://www.diva-portal.org/smash/get/diva2:1217738/FULLTEXT01.pdf

Skillnaden mellan GraphQL och SPARQL här: https://www.it-swarm.net/sv/graphql/vad-ar-skillnaden-mellan-graphql-och-sparql/838835082/

Videon med historien bakom GraphQL: The Documentary ser du här

Fredrik Jansson Systemstodsbloggen   Fredrik Jansson, fredrik.jansson@systemstod.se


Läs fler blogginlägg på Systemstödsbloggen

Nytta med handdatorer >>
Att upphandla TA-system >>
Lagerhantering med handdatorer här >>


Dela: