REST vs GraphQL: Vilket API-val passar din svenska arbetsplats?

Den moderna digitala världen bygger helt och hållet på att olika system kan prata med varandra. Din mobilapp måste prata med företagets databas, och din e-handel måste prata med betaltjänsten Klarna. Hur sker detta samtal? Genom ett API (Application Programming Interface) – gränssnittet där data utbyts. Men hur man ska strukturera detta API är en av de mest omdebatterade frågorna på svenska IT-avdelningar idag. I det ena ringhörnet står den klassiska giganten REST. I det andra ringhörnet utmanaren GraphQL. Beroende på vilken svensk arbetsplats du kliver in på, kommer du att behöva bemästra det ena eller det andra, och ibland båda.

REST API – den pålitliga industristandarden

I över tjugo år har REST (Representational State Transfer) varit industristandarden. Det svenska arvet inom telekom och storföretag som Ericsson har byggt en stark kultur kring strukturerade och förutsägbara system. REST är extremt strukturerat. Det bygger på att man har specifika ändpunkter (endpoints) representerade av URL:er.

Om du bygger en app för att läsa böcker, och frontend vill ha information om en författare, gör den ett "GET-anrop" till `api/authors/1`. Om den sedan vill ha böckerna författaren skrivit, måste den kanske göra ett nytt anrop till `api/authors/1/books`. Varje ändpunkt är ansvarig för sin specifika data. Systemet är tillståndslöst (stateless), extremt enkelt att förstå och, framför allt, fantastiskt bra på att cachelagra data för att spara prestanda. Om du börjar jobba på en svensk bank, en myndighet eller ett stort industriellt företag, kommer deras system med 99 procents sannolikhet att tala REST.

Problemet: Överhämtning och Underhämtning

När smartphones slog igenom började REST få problem. Varje byte av mobildata kostade tid. Problemet med REST är att backend-utvecklarna bestämmer exakt vad som skickas i svaret (nyttolasten/payload). Om frontend bara behöver veta namnet på författaren för att visa det i appen, och ropar på `api/authors/1`, kanske servern skickar tillbaka författarens namn, ålder, adress, och en hel biografi. Appen laddar ner massor av onödig data som den bara kastar bort. Detta kallas överhämtning (Over-fetching).

Motsatsen är underhämtning (Under-fetching), när ett anrop inte ger tillräckligt med information och frontend måste göra tre, fyra extra anrop bara för att rita upp en enda sida. I takt med att svenska företag ville bygga snabbare och mer responsiva appar för den globala marknaden, blev detta ett problem.

GraphQL – Frontends räddare i nöden?

Facebooks svar på detta problem var GraphQL (Graph Query Language), som snabbt plockades upp av innovativa svenska startups och mediabolag. Skillnaden är radikal. Istället för att ha hundratals ändpunkter, har GraphQL oftast bara en enda ändpunkt. Istället för att backend bestämmer vad som skickas, skickar frontend en komplex förfrågan (query) som säger exakt vad den vill ha, och ingenting annat.

"Ge mig författare nummer 1, men ge mig bara namnet. Och hämta samtidigt hens tre populäraste böcker, men jag behöver bara boktiteln."

Servern svarar exakt med den begärda datan i en smidig JSON-struktur. Inget överhämtande, inget underhämtande. För svenska frontend-team är GraphQL (ofta via verktyg som Apollo) en befrielse. De behöver inte längre be backend-teamet bygga nya, specifika ändpunkter varje gång appens design ändras. De hämtar bara det de behöver.

Den svenska mikrotjänst-utmaningen

Varför har inte alla svenska företag bytt till GraphQL då? Svaret stavas mikrotjänster (Microservices). Många stora svenska tech-jättar (däribland Spotify, som spred 'Spotify-modellen' över världen) bygger sina system i små, isolerade delar (mikrotjänster) som underhålls av oberoende team. En tjänst hanterar betalningar, en annan spellistor, en tredje användarkonton.

Dessa mikrotjänster måste prata med varandra i hög hastighet, och där är REST ofta överlägset enklast och mest pålitligt. Att bygga in GraphQL centralt i en komplex mikrotjänst-arkitektur kräver tunga verktyg som 'Apollo Federation', vilket är svårt att implementera och kan bli en prestandamardröm om utvecklarna gör misstag och skapar förfrågningar som kraschar databasen.

Vilket bör du kunna?

På den svenska arbetsmarknaden är svaret tydligt: du behöver förstå båda, men du värderas ofta högre beroende på din roll. Om du är en renodlad backend-utvecklare, eller jobbar mycket med infrastruktur och mikrotjänster, förväntas din kunskap inom REST och systemintegration vara monumental. Om du är frontend-utvecklare, eller en "fullstack" som söker jobb på en snabbrörlig startup som bygger mobilappar, kommer din förståelse för GraphQL att vara en enorm fördel. Svenska företag uppskattar utvecklare som är tekniskt agnostiska – det vill säga de som inser att inget verktyg är perfekt, utan att man måste välja rätt API-arkitektur för rätt affärsproblem.