GraphQL vs. REST: Fordele og forskelle i e-handel (2027)

GraphQL vs. REST handler om to forskellige tilgange til API'er. REST er en arkitekturstil til API'er (Application Programming Interfaces), som typisk bruger flere faste endpoints, der hver returnerer data i et bestemt format. GraphQL er et forespørgselssprog til API'er, hvor klienten via ét endpoint kan angive præcis, hvilke data der skal hentes i en enkelt forespørgsel.

Valget mellem REST og GraphQL har betydning for dit website på flere områder, bl.a. hvor meget data der overføres mellem systemerne, hvor mange forespørgsler der skal til for at indlæse en side, og hvordan dine integrationer kan videreudvikles. I oktober 2024 gjorde Shopify GraphQL til vores primære API. I løbet af det foregående år fordoblede vi grænserne for GraphQL-forespørgsler og reducerede omkostningerne ved forbindelsesbaserede forespørgsler med 75 %.

I denne guide gennemgår vi forskellene mellem GraphQL og REST og forklarer, hvornår de forskellige løsninger er mest velegnede. Du får også hjælp til at vurdere, hvilken løsning der passer bedst til din virksomheds behov.

REST: Den traditionelle tilgang

Et e-handels-API gør det muligt for forskellige systemer at udveksle data. En klient sender en forespørgsel til et endpoint på en server, som derefter returnerer de ønskede data.

REST står for Representational State Transfer, og API'er, der bygger på denne arkitekturstil, kaldes RESTful API'er eller REST API'er. De har eksisteret siden begyndelsen af 2000'erne og blev hurtigt standarden for webtjenester, fordi de bruger velkendte HTTP-metoder som GET, POST, PUT og DELETE til at udveksle data.

REST har flere fordele, som er med til at forklare, hvorfor det stadig er så udbredt:

• Forudsigelige endpoints: Hver ressource har sin egen URL. Eksempelvis henviser /products/123 altid til den samme ressource.
• Bred understøttelse: REST understøttes af stort set alle programmeringssprog, API-gateways og overvågningsværktøjer.
• Velkendte HTTP-statuskoder: Statuskoder som 404 og 429 fortæller klienten, hvad der er sket, uden at den behøver at analysere svarets indhold.
• Indbygget HTTP-caching: Da GET-forespørgsler bruger URL'er til at identificere ressourcer, kan browsere, content delivery networks (CDN'er) og proxyservere cache svar uden yderligere tilpasninger.

REST egner sig fortsat godt til enkle operationer med individuelle ressourcer samt til webhooks, filoverførsler, offentligt tilgængelige data med læseadgang og integrationer, hvor samarbejdspartnerens systemer er baseret på REST. Ifølge Postmans rapport "State of the API" fra 2025 bruger 93 % af de adspurgte teams stadig REST.

REST har dog også visse begrænsninger, især i applikationer med høje krav til ydeevne. REST-endpoints returnerer typisk data i en foruddefineret struktur, hvilket kan føre til to problemer:

• Overfetching: Et endpoint returnerer fx alle oplysninger om et produkt, selvom klienten kun har brug for lagerstatus.
• Underfetching: Et endpoint returnerer ikke alle de nødvendige oplysninger, så klienten må sende flere forespørgsler til forskellige endpoints for at hente de data, der skal bruges til at vise en side.

Begge problemer kan opstå på den samme side.

Efterhånden som mobilteknologi og cloud computing blev mere udbredt i 2000'erne og begyndelsen af 2010'erne, blev disse begrænsninger mere mærkbare. Behovet for hurtigere og mere effektive løsninger fik en virksomhed til at udvikle et nyt alternativ.

GraphQL: Et mere effektivt alternativ

Facebook begyndte at udvikle GraphQL i 2012 i forbindelse med en større omlægning af virksomhedens native mobilapps og gjorde teknologien til open source i 2015. I 2019 blev GraphQL Foundation etableret under Linux Foundation for at understøtte den videre udvikling af GraphQL. I dag bruges teknologien af store webplatforme verden over.

GraphQL blev udviklet til bl.a. at løse problemerne med overfetching og underfetching, som kan opstå med REST API'er. Med GraphQL kan klienten selv angive, hvilke data den har brug for, og serveren returnerer kun de efterspurgte oplysninger.

Sådan fungerer et GraphQL-skema

Et GraphQL-API bygger på et skema, der definerer de forskellige datatyper i systemet, fx Product, Variant, Order og Customer, og hvilke felter der er tilgængelige for hver type. Skemaet beskriver også relationerne mellem de forskellige datatyper, så en enkelt forespørgsel kan hente oplysninger om eksempelvis en ordre, dens ordrelinjer og de tilhørende produkter.

GraphQL understøtter tre typer operationer:

• Queries henter data.
• Mutations opretter, opdaterer eller sletter data.
• Subscriptions sender opdateringer til klienten, når data ændrer sig.

GraphQL-skemaet er stærkt typet, hvilket betyder, at serveren kan validere forespørgsler, inden de udføres. Hvis en forespørgsel fx indeholder et felt, der ikke findes i skemaet, bliver den afvist.

Skemaet understøtter også introspektion, så en klient kan hente oplysninger om API'ets egne typer og felter. Det gør det bl.a. muligt at bruge autofuldførelse i værktøjer som GraphiQL og få vist fejl direkte i udviklingsmiljøet (IDE), inden en forespørgsel udføres.

Her er et eksempel på en GraphQL-forespørgsel til en webshop. Den henter et produkts titel, de første to varianter med pris og tilgængelighed samt produktets fremhævede billede:

{ product(handle: "trail-runner") { title featuredImage { url } variants(first: 2) { nodes { title price { amount currencyCode } availableForSale } } } }

Svaret følger samme struktur som forespørgslen. Felter, som klienten ikke har efterspurgt, fx produktbeskrivelser, tags eller SEO-metadata, bliver ikke returneret. Med et REST API modtager klienten derimod typisk et foruddefineret datasæt fra produktets endpoint og kan være nødt til at sende yderligere forespørgsler for at hente oplysninger, der ikke indgår i svaret, fx metafelter.

GraphQL er blevet populært, fordi mange virksomheder står over for den samme udfordring, som Facebook oprindeligt forsøgte at løse: at udvikle komplekse applikationer med store mængder data uden at gå på kompromis med hastighed og stabilitet. Det gælder både mindre webshops og store internationale virksomheder.

Seks fordele ved at bruge GraphQL til e-handel i større skala

GraphQL vs. REST kan umiddelbart virke som et spørgsmål om mindre tekniske forskelle, men valget af API spiller en vigtig rolle i driften af en webshop. Ligesom fundamentet under et hus kan valget af API være med til at skabe langsigtet stabilitet eller føre til udfordringer, efterhånden som du bygger videre på din løsning. De udfordringer bliver især tydelige, når forretningen vokser, og de er ofte særligt mærkbare i e-handel for større virksomheder.

Her er en oversigt over de vigtigste forskelle:

GraphQL er fleksibelt, men har også nogle ulemper. Fordi klienten selv former forespørgslen, kan én dårligt skrevet forespørgsel være langt mere ressourcekrævende end et typisk REST-kald. Serveren skal også håndtere resolvers og beskytte sig mod dybt indlejrede forespørgsler, som kan udløse mange databaseopslag.

Teams i større virksomheder, der tager GraphQL i brug, har derfor brug for klare retningslinjer for både skemadesign og forespørgselsadfærd. Det kan bl.a. være grænser for forespørgselsomkostninger, maksimumdybde og fælles ejerskab af skemaet. Sørg derfor for, at disse krav er med, når du vælger enterprise-software.

Afsnittene nedenfor gennemgår de fordele, der gør GraphQL til et stærkt valg i de situationer, hvor teknologien passer bedst, herunder forskellige klienttyper, forbundne datamodeller, flere datakilder og shoppingoplevelser med høje krav til ydeevne.

1. Velegnet til komplekse data

I større e-handelsvirksomheder er data ofte tæt forbundet og kan visualiseres som et netværk eller en graf. Et produkt har forskellige varianter, og hver variant kan være på lager flere steder. En ordre er knyttet til kunder, rabatter og leverancer, mens en B2B-konto har sine egne prislister og betalingsbetingelser. REST organiserer typisk disse data i separate endpoints for hver ressource. Efterhånden som datamodellen bliver mere kompleks, kan det kræve flere API-kald at samle alle de nødvendige oplysninger i én visning. Det kan føre til længere svartider.

GraphQL er udviklet til at håndtere denne type data. Et skema beskriver relationerne direkte, så en enkelt forespørgsel kan hente præcis de oplysninger, der er behov for. Derfor spiller GraphQL en central rolle i Shopifys samlede datamodel.

Tecovas, der sælger westernbeklædning og -udstyr, havde brug for en platform med stærke API'er og gode muligheder for tilpasning. "Jeg leder efter systemer, der kan håndtere de grundlæggende opgaver, men som samtidig giver os mulighed for at udvide funktionaliteten, har et solidt udvalg af API'er og kan tilpasses vores specifikke forretningsprocesser", fortæller Kevin Harwood, CTO hos Tecovas.

Tecovas bruger Shopify POS som en del af et fuldt integreret lagerstyringssystem. Medarbejderne kan hurtigt tjekke den aktuelle lagerstatus, når en kunde spørger efter en bestemt vare. Virksomhedens specialtilpassede webshopfrontend er bygget med Shopify Hydrogen, som bruger GraphQL Storefront API til at hente oplysninger om produkter, kollektioner og indkøbskurve.

2. Mindre dataoverførsel

REST-endpoints returnerer typisk data i en fast struktur, som kan indeholde flere oplysninger, end klienten har brug for (overfetching). Det betyder, at der overføres unødvendige data, hvilket kan føre til længere svartider.

I større webshops kan selv få millisekunder gøre en forskel. Ifølge en undersøgelse fra Shopify hænger en stigning i responstiden på 32 millisekunder sammen med et fald i konverteringsraten på omkring 1,5 %.

Med GraphQL kan klienten nøjes med at hente de felter, den har brug for. Det kan reducere mængden af data, der overføres, mindske båndbreddeforbruget og forbedre ydeevnen.

3. Færre forespørgsler til serveren

REST-endpoints returnerer typisk foruddefinerede datastrukturer, og derfor kan det være nødvendigt at sende flere forespørgsler for at hente alle oplysninger til en enkelt visning (underfetching). Hver forespørgsel kræver kommunikation mellem klienten og serveren, hvilket kan øge den samlede svartid.

En produktside er et godt eksempel. I Shopifys REST Admin API returnerer produktets endpoint et fast datasæt, mens relaterede oplysninger som metafelter kræver yderligere forespørgsler. Det kan derfor være nødvendigt at kalde flere endpoints for at hente alle oplysninger til en komplet produktvisning, selvom hvert svar også indeholder data, som siden ikke bruger. Med GraphQL kan de samme oplysninger hentes i én forespørgsel, hvor klienten kun angiver de nødvendige felter.

Forestil dig så, at det samme skal gøres ved synkronisering af et helt produktkatalog, i en integration med et ERP-system (Enterprise Resource Planning) eller i en POS-app, der kontrollerer lagerstatus i realtid. Her kan forskellen blive betydelig. Færre forespørgsler til serveren kan give hurtigere indlæsningstider og en mere smidig brugeroplevelse.

4. Bedre udvikleroplevelse

REST har eksisteret i mange år og er derfor velkendt blandt udviklere. GraphQL kan kræve lidt mere arbejde i begyndelsen, men tilbyder til gengæld en række værktøjer, der gør udviklingsarbejdet nemmere. Det stærkt typede skema fungerer som dokumentation, så udviklere kan udforske et API, bruge autofuldførelse og opdage fejl, inden en forespørgsel udføres. Skemaets faste typer og regler er også med til at sikre konsistens i data over tid.

Der er dog nogle forhold, som større virksomheder bør være opmærksomme på:

• Fejlhåndtering: GraphQL kan returnere HTTP 200, selvom dele af en forespørgsel fejler. I sådanne tilfælde kan svaret indeholde et errors-array med oplysninger om fejlene. Shopifys GraphQL Admin API dokumenterer denne forskel. Klienten skal derfor kontrollere svarets indhold og ikke kun HTTP-statuskoden.
• Kompleksitet på serveren: GraphQL bruger resolvers til at hente data til de enkelte felter. Hvis de ikke er implementeret effektivt, kan det resultere i en separat databaseforespørgsel for hvert element på en liste, også kendt som N+1-problemet. Problemet kan håndteres med batching og caching, men det kræver ekstra udviklingsarbejde.
• Styring: Da klienterne selv definerer deres forespørgsler, skal API-ejeren fastsætte grænser for, hvor ressourcekrævende eller komplekse de må være. Ændringer i skemaet skal også koordineres mellem de relevante teams. Shopifys GraphQL Admin API bruger fx beregnede forespørgselsomkostninger til at begrænse belastningen i stedet for blot at tælle antallet af forespørgsler.

5. Nemmere videreudvikling af API'er

GraphQL vs. REST handler ikke kun om datahentning og ydeevne. Der er også forskel på, hvordan API'erne kan videreudvikles over tid. Med REST kræver ændringer i et svars struktur, som bryder bagudkompatibiliteten, typisk en ny API-version (fx /v2/) og en overgangsperiode, hvor klienterne kan tilpasses.

GraphQL er designet, så skemaet kan videreudvikles uden nødvendigvis at oprette en ny API-version. Nye felter kan tilføjes, uden at eksisterende klienter påvirkes, fordi de kun modtager de felter, de har bedt om. Felter, der skal udfases, kan markeres med et særligt direktiv. De fungerer fortsat, men udviklerne får en advarsel i deres værktøjer. Når et felt fjernes helt, vil forespørgsler, der bruger feltet, blive afvist under valideringen.

Det betyder dog ikke, at GraphQL helt eliminerer ændringer, der bryder bagudkompatibiliteten. Shopify udgiver fortsat nye API-versioner hvert kvartal. Fordelen ved GraphQL er, at almindelige ændringer og tilføjelser til skemaet ofte kan foretages uden at kræve en ny version af hele API'et.

6. Bedre ydeevne

Men hvad betyder alle disse fordele for ydeevnen i praksis? En analyse fra Shopify baseret på næsten 200.000 offentligt tilgængelige datapunkter viste, at Shopify-webshops blev indlæst op til 2,4 gange hurtigere og i gennemsnit 1,8 gange hurtigere end webshops på andre platforme.

GraphQL er dog kun én af de faktorer, der bidrager til Shopifys hastighed. Platformens samlede ydeevne afhænger også af global hosting, CDN, browser-caching, komprimering og billedoptimering. GraphQL kan reducere mængden af data, der skal overføres, og antallet af forespørgsler til serveren, mens platformens øvrige infrastruktur er med til at sikre, at resten af siden indlæses hurtigt.

Shopify og GraphQL

Shopify begyndte at bruge GraphQL, kort efter at Facebook gjorde teknologien offentligt tilgængelig. Dengang fandtes der kun få etablerede anbefalinger og metoder, så vi var nogle af de første til at tage GraphQL i brug og måtte lære teknologien at kende fra bunden. Siden er GraphQL blevet langt mere udbredt og spiller i dag en endnu vigtigere rolle i Shopifys infrastruktur. Det har også givet Shopify-webshops en række fordele.

I oktober 2024 annoncerede vi, at GraphQL fremover ville være vores primære API. Siden den 1. april 2025 har alle nye offentlige apps, der indsendes til Shopify App Store, skullet bruge GraphQL Admin API. REST Admin API har fået legacy-status, men fungerer fortsat. Nye platformfunktioner lanceres først via GraphQL. Nogle funktioner, herunder understøttelse af op til 2.000 produktvarianter og metaobjekter, er kun tilgængelige via GraphQL.

Shopifys Storefront API er baseret på GraphQL, og Admin API er også tilgængeligt via GraphQL. Værktøjer som Shopify Functions, UI extensions og App Bridge bruger også GraphQL til centrale funktioner og dataadgang.

Brug af REST og GraphQL under en migrering

Når en større virksomhed moderniserer sin e-handelsplatform, behøver alle integrationer ikke at blive flyttet på én gang. REST og GraphQL kan bruges sideløbende i en overgangsperiode, og det var netop den tilgang, Skullcandy valgte.

Skullcandy migrerede til Shopify på 90 dage. Virksomheden erstattede en specialudviklet betalingsproces i fem trin med Shopify Checkout og udfasede et separat PIM-system (Product Information Management) til håndtering af produktinformation. Ordrebehandlingen foregår via REST API'er og webhooks, mens større lageropdateringer håndteres via GraphQL API. Det gør det muligt at opdatere hundredvis af lagerposter i én forespørgsel i stedet for én ad gangen. Begge API-typer bruges også til at understøtte nye apps.

Resultaterne viste sig hurtigt efter overgangen til Shopify. Allerede dagen efter lanceringen var indlæsningstiden for Skullcandys forside faldet fra 2,8 til 0,8 sekunder. I virksomhedens første fulde julesæson på Shopify steg omsætningen med op til 45 % sammenlignet med året før. Ved den største produktlancering steg antallet af besøg med 200 %, uden at det medførte problemer med ydeevnen.

Hvornår skal du vælge GraphQL vs. REST?

Shopify understøtter fortsat både REST og GraphQL, men hvilken løsning der er bedst, afhænger af, hvad du skal bruge API'et til.

Vælg GraphQL, når du arbejder med:

• Komplekse datamodeller: Produkter med mange varianter, lagerbeholdning på flere lokationer, B2B-prislister eller metaobjekter, hvor oplysningerne skal hentes samlet.
• Forskellige klienttyper: Webshops, mobilapps, POS-systemer og AI-agenter, der hver har brug for forskellige dele af de samme data.
• Specialtilpassede webshops: Headless-løsninger bygget med Hydrogen eller et andet framework, hvor det er vigtigt at begrænse antallet af forespørgsler for at sikre hurtig indlæsning.
• Langsigtede integrationer: Integrationer med ERP-systemer, ordrestyringssystemer (OMS) og PIM-systemer, der skal kunne videreudvikles over flere år uden at skabe kompatibilitetsproblemer.

REST er fortsat velegnet, når:

• Du skal udføre en enkel operation, hvor du læser eller ændrer data for en enkelt ressource.
• En samarbejdspartners systemer kræver REST, eller du har en eksisterende integration, der fungerer stabilt.
• Du arbejder med webhooks eller filoverførsler.

Du kan også bruge REST og GraphQL sideløbende under en migrering. Eksisterende REST-integrationer kan fortsætte med at fungere, mens nye løsninger udvikles med GraphQL. Det er ofte mest fordelagtigt at starte med de integrationer, der håndterer flest forespørgsler eller de mest komplekse data, da det er her, forbedringerne kan være størst. Planlæg derfor migreringen som en del af en større it-modernisering frem for at forsøge at omskrive alle integrationer på én gang.

For større virksomheder, der bruger Shopify, er GraphQL ofte det oplagte valg til nye og komplekse integrationer. Det er her, nye platformfunktioner først bliver tilgængelige, og teknologien spiller en central rolle i Shopifys egne udviklerværktøjer.