GraphQL vs REST -- Wann was verwenden

Facebook hat GraphQL 2015 als Open Source veröffentlicht, und seitdem ist ein enormer Hype entstanden. GitHub hat die GraphQL API v4 eingeführt, Shopify ebenfalls. Bedeutet das, dass REST tot ist? Keineswegs. Aber es gibt Szenarien, in denen GraphQL klar gewinnt.

Das Problem namens Over-Fetching¶

Ein klassischer REST-Endpoint GET /api/users/42 gibt das komplette Benutzerobjekt zurück – Name, E-Mail, Adresse, Bestellhistorie, Präferenzen. Eine mobile App braucht nur den Namen und den Avatar. Sie lädt 15 KB statt 200 B herunter. Multiplizieren Sie das mit Tausenden von Anfragen, und Sie haben ein Problem.

GraphQL löst Over-Fetching elegant: Der Client definiert, was er will. Der Server liefert genau die angeforderten Felder. Nichts mehr.

Under-Fetching und das N+1-Problem¶

Das umgekehrte Problem: Sie brauchen einen Benutzer, seine Bestellungen und zu jeder Bestellung die Produkte. In REST bedeutet das drei Endpoints und eine Kaskade von Anfragen. In GraphQL eine Abfrage:

{
  user(id: 42) {
    name
    avatar
    orders(last: 5) {
      id
      total
      items {
        product { name, price }
        quantity
      }
    }
  }
}

Eine Anfrage, genau die Daten, die Sie brauchen. Für mobile Clients und komplexe UIs ist das ein Game-Changer.

Typsystem und Introspektion¶

GraphQL hat ein starkes Typsystem, das durch ein Schema definiert wird. Jedes Feld hat einen Typ, jedes Argument wird validiert. Das Schema dient gleichzeitig als Dokumentation – GraphiQL (interaktiver Playground) zeigt Ihnen alle verfügbaren Queries, Mutations und Typen. Kein Swagger, kein Postman – das Schema ist die Single Source of Truth.

type User {
  id: ID!
  name: String!
  email: String!
  orders(last: Int): [Order!]!
}

type Order {
  id: ID!
  total: Float!
  items: [OrderItem!]!
  createdAt: DateTime!
}

type Query {
  user(id: ID!): User
  users(filter: UserFilter): [User!]!
}

Wo REST immer noch gewinnt¶

HTTP-Caching – REST-Endpoints haben URLs, die sich natürlich cachen lassen (CDN, Browser-Cache, Reverse Proxy). GraphQL sendet POST-Anfragen an einen einzelnen Endpoint – Caching ist deutlich komplexer. Apollo Client löst Client-seitiges Caching, aber CDN? Schwierig.

Einfachheit – Eine REST-API für CRUD-Operationen auf einer einzelnen Ressource ist trivial. GET, POST, PUT, DELETE – jeder Entwickler kennt das. GraphQL fügt eine Resolver-Schicht, Schema-Definition und Query-Complexity-Analyse hinzu. Für ein einfaches Backend ist das Overhead.

Datei-Upload – REST: Multipart-Form. GraphQL: Es gibt keinen Standard in der Spec; Workarounds existieren (Multipart Request Spec), aber es ist nicht nativ.

Fehlerbehandlung – REST gibt HTTP-Statuscodes zurück. GraphQL gibt immer 200 OK zurück, mit Fehlern im Response Body. Für Monitoring und Alerting ist das weniger intuitiv.

Wann auf GraphQL wechseln¶

Haben Sie mehrere Clients (Web, iOS, Android) mit unterschiedlichen Datenanforderungen? GraphQL. Haben Sie komplexe relationale Daten mit verschachtelten Objekten? GraphQL. Haben Sie einen einfachen Client und eine CRUD-API? Bleiben Sie bei REST.

Wir haben GraphQL in einem Projekt mit React-Frontend und mobiler App eingesetzt. Drei Monate nach der Migration: 40 % weniger API-Anfragen von der mobilen App, und das Frontend-Team definiert seine eigenen Queries, ohne auf das Backend warten zu müssen. Win-win.

Ökosystem-Tools (2017)¶

Server: Apollo Server (Node.js), graphql-java, Graphene (Python). Client: Apollo Client, Relay (Facebook). Tooling: GraphiQL, eslint-plugin-graphql, graphql-code-generator (TypeScript-Typen aus dem Schema).

Das Ökosystem wächst schnell. Apollo ist der De-facto-Standard für JavaScript. Relay ist leistungsfähiger, aber komplexer – wir empfehlen, mit Apollo zu beginnen.

Praktische Tipps aus dem Einsatz¶

• Query Complexity Limiting – ohne das kann jeder eine verschachtelte Query senden, die Ihre Datenbank in die Knie zwingt
• DataLoader-Pattern – löst das N+1-Problem auf Resolver-Ebene (Batching + Caching)
• Persisted Queries – der Client sendet einen Hash statt des vollständigen Query-Strings (Sicherheit + Performance)
• Schema-first vs. Code-first – wir bevorzugen Schema-first für bessere Lesbarkeit
• Versionierung – GraphQL-Schemas werden nicht per URL versioniert (/v1, /v2); Felder werden als deprecated markiert und neue hinzugefügt

GraphQL ist kein REST-Ersatz – Es ist eine Alternative¶

Verwenden Sie GraphQL dort, wo es ein reales Problem löst: komplexe Daten, mehrere Clients, Over-Fetching. Für einfache CRUD-APIs, Webhooks und Server-to-Server-Kommunikation ist REST weiterhin eine ausgezeichnete Wahl. Die beste Architektur? Oft ein Hybrid – REST für einfache Endpoints, GraphQL für komplexe Queries.