REST vs GraphQL: Du har sandsynligvis ikke brug for GraphQL

GraphQL blev lanceret af Facebook i 2015 og har siden været det "moderne" valg for API-design. Men efter at have bygget API'er i begge paradigmer, er vores ærlige vurdering: de fleste projekter har ikke brug for GraphQL.

Hvad er forskellen?

REST: Ressource-baseret

REST eksponerer endpoints for hver ressource:

GET/api/users/123

POST/api/users

PUT/api/users/123

DELETE/api/users/123

GET/api/users/123/orders

Serveren bestemmer hvilke felter der returneres.

GraphQL: Query-baseret

GraphQL har ét endpoint hvor klienten specificerer præcis hvad den vil have:

query {
  user(id: 123) {
    name
    email
    orders {
      id
      total
    }
  }
}

Klienten bestemmer strukturen.

Hvornår GraphQL giver mening

GraphQL løser reelle problemer - bare ikke de problemer du sandsynligvis har.

Brug GraphQL når:

1. Du har mange forskellige klienter med vidt forskellige data-behov

Facebook har iOS, Android, web, React Native, embedded devices - alle med forskellige skærme og data-behov. Ét fleksibelt API giver mening.

Har du det? Sandsynligvis ikke. De fleste har én webapp og måske én mobilapp.

2. Du har dybt nested, relationelle data med komplekse queries

Sociale netværk, content management systemer, eller e-commerce med tusindvis af produkt-varianter.

3. Dit frontend-team vil have fuld kontrol over data

GraphQL giver frontend-udviklere frihed til at hente præcis hvad de skal bruge uden at vente på backend-ændringer.

4. Du har et dedikeret API-team

GraphQL kræver mere infrastruktur: schema management, query complexity analysis, caching strategi, performance monitoring.

Brug REST når:

1. Du bygger en standard webapp eller mobilapp

CRUD-operationer, brugerstyring, simple relationer. REST gør det med mindre kompleksitet.

2. Du har ét eller to klient-typer

Hvis alle dine klienter bruger de samme data nogenlunde ens, løser GraphQL et problem du ikke har.

3. Caching er vigtigt

REST's HTTP-baserede caching (CDN, browser cache, etags) virker out-of-the-box. GraphQL's POST-requests cacher ikke automatisk.

4. Dit team er lille

GraphQL har en læringskurve og vedligeholdelsesomkostninger. Små teams får mere ud af simpel REST.

De skjulte omkostninger ved GraphQL

1. N+1 Problem

Den klassiske GraphQL-fælde:

query {
  users {
    name
    posts {
      title
    }
  }
}

Uden DataLoader laver dette én query for users + én query per user for posts. 100 users = 101 database queries.

Løsning: DataLoader, men det er ekstra kompleksitet du skal bygge og vedligeholde.

2. Caching er svært

REST:

GET/api/users/123

Browseren og CDN cacher automatisk med Cache-Control headers.

GraphQL: Alle requests er POST til samme endpoint. Du skal implementere:

Persisted queries
Apollo Client cache
Server-side caching med Redis
Cache invalidation strategi

3. Rate limiting og sikkerhed

REST: Begræns requests per endpoint. Simpelt.

GraphQL: En enkelt query kan være billig eller ekstremt dyr:

query {
  users {
    posts {
      comments {
        author {
          posts {
            comments {
              # Nested doom
            }
          }
        }
      }
    }
  }
}

Du skal implementere query depth limiting, complexity analysis, og timeout handling.

Aspekt	REST	GraphQL
Over-fetching	Ja, server bestemmer	Nej, klient bestemmer
Under-fetching	Ja, multiple requests	Nej, én request
Caching	Indbygget i HTTP	Skal implementeres
Request overhead	Minimalt	Query parsing + validation
N+1 queries	Sjældent problem	Almindeligt problem

Over-fetching (få for meget data) er GraphQL's hovedargument. Men i praksis:

JSON parsing er hurtigt
Gzip komprimerer godt
Du kan lave separate REST endpoints for specifikke views

Vores anbefaling

Start med REST. Altid.

Simpelt at forstå - alle kender HTTP verbs og status codes
Simpelt at cache - CDN og browser-cache virker automatisk
Simpelt at sikre - rate limiting per endpoint
Simpelt at dokumentere - OpenAPI/Swagger er industristandard
Simpelt at debugge - curl og browser DevTools

Overvej GraphQL når:

Du har 3+ forskellige klient-platforme med forskellige data-behov
Dit frontend-team blokeres konstant af backend-ændringer
Du har et dedikeret API-team til at vedligeholde infrastrukturen
Over-fetching er et måleligt performance-problem, ikke teoretisk

BFF-mønsteret: Det bedste fra begge verdener

Mange teams bruger Backend for Frontend (BFF) i stedet for GraphQL:

Mobile App  → Mobile BFF  → Services
Web App     → Web BFF     → Services

Hver BFF er en tynd REST API der samler præcis de data klienten skal bruge. Du får:

Klient-specifik data uden GraphQL-kompleksitet
Simpel HTTP caching
Ingen ny query language at lære

Konklusion

GraphQL er et fantastisk værktøj - til de problemer det løser. Men "alle bruger det" er ikke en god grund til at vælge det.

Spørg dig selv:

Har jeg virkelig mange forskellige klienter med vidt forskellige behov?
Er over-fetching et måleligt problem i min app?
Har jeg ressourcer til at bygge og vedligeholde GraphQL-infrastruktur?

Hvis svaret er nej, så er REST det rigtige valg. Det er ikke gammeldags - det er pragmatisk.