Tycker du ditt GUI får ladda onödigt länge ibland? Har du kanske jobbat med frontend-utveckling och reagerat på hur ofta du måste göra kedjor av HTTP-anrop för att komma åt det lilla stycket av data? Eller har du suttit i en releaseprocess och blivit frustrerad över en trög väntan på att en backend-tjänst ska bli klar så att du kan slutföra din funktionalitet? Kanske har tanken slagit dig att REST är 20 år gammalt i en bransch där tekniker utvecklas snabbare än någonsin? Med den nya uppstickande tekniken GraphQL verkar det som att tiden är inne att byta ut vår gamla goda vän REST…

Vad är då problemet med REST?

REST, som blivit de facto standard för maskin till maskin-kommunikation inom modern systemutveckling togs fram för 20 år sedan. Utan att blinka tar en majoritet numera beslut om att deras system ska designas enligt denna princip då den är universal och har satt standarder som används världen över. REST utvecklas resursbaserat och data levereras genom gränssnitt bundna i vad som kan ses som en “en till en-relation” mellan URL och resurs.

REST har byggt upp stabila och universella tekniker för att underlätta felhantering, skalbarhet och såklart utvecklingen av API:er i stort. REST baseras på HTTPs-standarder såsom statuskoder och förknippas tätt med metoderna GET, POST, PUT och DELETE samt web caching baserat på unika URLer. Kort och gott ett fungerande koncept för att bygga upp API:er. Även om arbete görs för att fortsatt optimera prestandan på REST så finns det svårigheter i att lösa de problem som finns utan att bryta mot RESTs grundprinciper.

Vilka fördelaktiga alternativ finns?

Det nya alternativet GraphQL startade som ett internt projekt på Facebook 2012. Anledningen till att man kände ett behov av att utveckla ett nytt sätt att hämta data på var övergången till mer mobilanpassade applikationer. Med detta kommer också mer begränsade resurser i form av bland annat CPU och bandbredd. Vilket innebär att all överflödig data som ofta följer med i ett vanligt REST-anrop i längden blir väldigt kostsamt för användaren.

Det som särskiljer GraphQL från REST är att tekniken istället för flertalet integrationspunkter som returnerar fördefinierade objekt alltid hämtar datan från en och samma integrationspunkt med hjälp av förfrågningar. Med hjälp av detta kan anrop specificeras väldigt precist och hämta endast relevant data och därmed spara prestanda.

Principen för REST vs principen för GraphQL

Med GraphQL minskar stora mängder av hämtad data

Att gå från ett gammalt REST API till GraphQL leder som sagt till att du är kvitt problemet med överhämtning av data. Under 2018 introducerade Netflix en ny API-arkitektur som byggdes på GraphQL. Detta efter att deras plattform hade växt och blivit mer och mer komplex, vilket resulterade i att enkla sidor behövde hämta data från en mängd olika källor. Här stod man vid ett vägskäl, skapa flertalet REST API:er eller bara inse att den tiden är passé och helt enkelt introducera ett GraphQL-baserat system. Efter introduktionen av GraphQL så var nyttolasten mycket mindre – sidor som tidigare hade hämtat över 10MB data tog nu emot endast 200kB.

Kom igång med GraphQL

Likt andra nya, innoverande tekniker är GraphQL inte lämpat för alla tänkbara ändamål. GraphQL bör inte implementeras i alla system, precis som med många andra arkitekturella tekniska val. Tekniken har sina fördelar men för att underhålla ett GraphQL-projekt krävs eftertanke kombinerat med beredskapen på en något högre inlärningskurva än med REST. För att påbörja en övergång till GraphQL kan ett första steg vara att nya mikrotjänster i systemen använder sig av GraphQL, som då kan fungera som en uppsamlingspunkt för gamla REST API:er. Detta blir ett väldigt naturligt steg i att börja implementera en GraphQL-baserad miljö och behöver inte förorsaka en dyr migrering à la vattenfallsmodellen för att börja utnyttjas.

Ett annat första steg till en GraphQL-baserad API-struktur är att interna backend-tjänster i ett system kan interagera med varandra via GraphQL. Denna övergång kan ske oberoende av externa aktörer och ger ett snabbare, effektivare system mot omvärlden.

Med GraphQL hamnar frontend i fokus

Vid projekt där GraphQL är den primära metoden vid datahämtning blir det tydligt att frontend-utvecklare blir mer stimulerade och lägger fokus på sin främsta uppgift. Istället för att vänta in backend-tjänster och ovisshet kring på vilket format som data kommer, så blir utveckling klientdriven istället för resursdriven. I en studie från PayPal så visade det sig att frontend-utvecklare endast la en tredjedel av sin tid på faktiska frontend-relaterade uppgifter, resten gick åt till att integrera mot API:er. Med GraphQL så blev fokus ett helt annat, enorma mängder boilerplate-kod försvann samt en stor minskning i vanliga fel orsakade av otypad data som skickas från API:et.

GraphQL blir mer och mer använt i skrivande stund, såsom alla växande lösningar så förbättras tekniken kontinuerligt. GraphQL kommer med en prestandahöjning som förbättrar användarupplevelsen likväl utvecklingsupplevelsen avsevärt. Så med intentionerna av att ha ett väl fungerande IT-samhälle byggt på IoT och mikrotjänster är enligt oss REST inte längre lämpat och GraphQL bör vara ett solklart val!

Skriven av: Oskar Gustafsson och Alexander Lindahl

Vill du veta mer?

Kontakta forsaljning@forefront.se