GraphQL im Enterprise: Wann es Sinn macht und wann man bei REST bleiben sollte¶

GraphQL hat ein Jahrzehnt Produktionseinsatz hinter sich — von Facebook über Shopify bis Atlassian. Im Jahr 2026 ist es kein Hype mehr, sondern eine ausgereifte Technologie mit klaren Anwendungsfällen. Das Problem ist, dass die meisten Unternehmen es falsch einsetzen.

Was GraphQL löst (und was nicht)¶

Echte Vorteile¶

Eliminierung von Over-Fetching. Ein REST-Endpoint liefert das gesamte Objekt zurück. Ein mobiler Client braucht 3 von 50 Feldern. Mit GraphQL fragt er genau das an, was er braucht.

# Client selects exactly what it needs
query {
  customer(id: "123") {
    name
    email
    lastOrder {
      total
      status
    }
  }
}

Ein Endpoint, mehrere Quellen. Statt 5 REST-Aufrufen für ein Dashboard (Kunde + Bestellungen + Rechnung + Adresse + Präferenzen) eine einzige GraphQL-Abfrage.

Starke Typisierung. Das Schema ist ein Vertrag. Frontend und Backend wissen genau, was die API zurückgibt. Auto-generierte TypeScript-Typen, Validierung, Dokumentation kostenlos.

Evolution ohne Versionierung. Das Hinzufügen eines neuen Feldes bricht bestehende Clients nicht. Deprecation auf Feldebene, nicht ganzer Endpoints.

Was GraphQL nicht löst¶

• Server-Performance — verlagert Komplexität vom Client auf den Server. Das N+1-Problem ist real.
• Caching — HTTP-Caching funktioniert über URLs. GraphQL-POST-Requests umgehen es.
• Sicherheit — beliebige Abfragen = potenzieller DoS. Sie müssen Query Depth, Complexity Limits und Rate Limiting handhaben.
• Einfachheit — für CRUD-APIs ist REST einfacher und direkter.

Wann GraphQL im Enterprise: JA¶

1. BFF (Backend for Frontend) Schicht¶

Sie haben Microservices mit REST-APIs und müssen Daten für das Frontend aggregieren. GraphQL als BFF-Schicht ist ideal:

Mobile App ──→ GraphQL BFF ──→ User Service (REST)
Web App   ──→ GraphQL BFF ──→ Order Service (REST)
                             ──→ Payment Service (REST)

Frontend-Teams definieren Abfragen nach Bedarf. Backend-Services bleiben REST (einfach, cachebar).

2. Mehrere Clients mit unterschiedlichen Anforderungen¶

Web braucht eine detaillierte Ansicht, Mobil eine kompakte, IoT-Geräte minimale Daten. Ein GraphQL-Endpoint bedient alle ohne Custom Endpoints.

3. Sich schnell ändernde Produktanforderungen¶

Ein Startup oder Produkt in der Frühphase, bei dem sich das Schema wöchentlich ändert. GraphQL ermöglicht Frontend-Entwicklern, zu iterieren, ohne auf das Backend zu warten.

4. Data Mesh / Federation¶

Eine große Organisation mit Dutzenden von Teams. Apollo Federation oder eine ähnliche Lösung ermöglicht jedem Team, seinen Teil des Graphen zu besitzen:

# Team A owns User
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String!
}

# Team B extends User with orders
extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}

Wann GraphQL: NEIN¶

CRUD-API für interne Services¶

Sie haben einen Microservice, der CRUD auf einer einzelnen Entität durchführt. REST ist einfacher, schneller zu implementieren, besser cachebar.

High-Throughput Services¶

API mit Millionen von Requests pro Sekunde, wo jede Millisekunde zählt. GraphQL-Parsing und Validierung fügen Overhead hinzu. gRPC ist die bessere Wahl.

Datei-Upload / Streaming¶

GraphQL hat keine native Unterstützung für Binärdaten. Multipart Upload existiert (Spezifikation), aber es ist ein Hack.

Einfaches Backend, ein einziger Client¶

Wenn Sie ein Frontend und ein einfaches Backend haben, fügt GraphQL Komplexität ohne Nutzen hinzu.

Produktionsarchitektur¶

Schema-Design¶

Schema-First-Ansatz ist der Standard im Enterprise:

1. Entwerfen Sie das Schema mit dem Produktteam
2. Generieren Sie Typen für Backend und Frontend
3. Implementieren Sie Resolver
4. Schema ist ein Vertrag — Änderungen über PR-Review

# Schema as a contract
type Query {
  """Returns customer by ID. Requires auth scope: customer:read"""
  customer(id: ID!): Customer

  """Full-text customer search. Max 100 results."""
  searchCustomers(query: String!, limit: Int = 20): CustomerConnection!
}

type Customer {
  id: ID!
  name: String!
  email: String!
  createdAt: DateTime!
  orders(first: Int = 10, after: String): OrderConnection!
  # deprecated field — use `name` instead
  fullName: String @deprecated(reason: "Use `name` field")
}

N+1-Lösung: DataLoader¶

Das häufigste Performance-Problem. Lösung: DataLoader Pattern (Batching + Caching):

# Without DataLoader: N+1 queries
# customer.orders → SELECT * FROM orders WHERE customer_id = 1
# customer.orders → SELECT * FROM orders WHERE customer_id = 2
# ... N dotazů

# With DataLoader: 1 query
# batch_load_orders([1, 2, 3, ...]) →
# SELECT * FROM orders WHERE customer_id IN (1, 2, 3, ...)

Security Hardening¶

In der Produktion MÜSSEN Sie folgendes adressieren:

Query Depth Limiting — Begrenzung der Verschachtelungstiefe von Abfragen (typischerweise max. 10):

# This would pass without a limit and kill the server:
query {
  user {
    orders {
      items {
        product {
          reviews {
            author {
              orders {
                # ... infinitely
              }
            }
          }
        }
      }
    }
  }
}

Query Complexity Analysis — jedes Feld hat Kosten, die Summe darf das Limit nicht überschreiten.

Persisted Queries — in der Produktion akzeptieren Sie keine beliebigen Abfragen. Der Client sendet einen Hash, der Server sucht die registrierte Abfrage. Eliminiert Injection und DoS.

Rate Limiting — pro Feld oder pro Operation, nicht pro Request.

Monitoring¶

GraphQL-Endpoints geben immer HTTP 200 zurück (auch bei Fehlern). Standard-Monitoring funktioniert nicht. Sie brauchen:

• Per-Resolver Metriken — Latenz, Error Rate auf Feldebene
• Query Complexity Tracking — durchschnittliche/maximale Abfragekomplexität
• Slow Query Log — Abfragen über dem Schwellenwert
• Field Usage Analytics — welche Felder niemand nutzt → Kandidaten für Deprecation

Tools: Apollo Studio, GraphQL Hive (Open-Source), Grafana + Custom Exporter.

Technologien 2026¶

Kategorie	Empfehlung
Server (Node.js)	Apollo Server 4, Yoga (Envelop)
Server (JVM)	Netflix DGS, Spring for GraphQL
Server (Python)	Strawberry, Ariadne
Server (.NET)	Hot Chocolate
Federation	Apollo Federation 2, Cosmo Router
Client	Apollo Client, urql, Relay
Codegen	GraphQL Code Generator
Monitoring	Apollo Studio, GraphQL Hive

Empfohlener Ansatz für tschechische Unternehmen¶

1. Beginnen Sie mit einer BFF-Schicht — lassen Sie Backend-Services auf REST, fügen Sie eine GraphQL-Aggregationsschicht hinzu
2. Schema-First — entwerfen Sie das Schema zusammen mit dem Frontend-Team
3. Persisted Queries von Anfang an — Sicherheit und Performance
4. DataLoader immer — ohne Ausnahme, auch für „einfache” Resolver
5. Federation erst wenn nötig — nicht voreilig, die Komplexität ist real

GraphQL ist kein Ersatz für REST. Es ist eine Ergänzung für spezifische Anwendungsfälle. Setzen Sie es dort ein, wo es ein reales Problem löst, und lassen Sie REST dort, wo es funktioniert.

---

CORE SYSTEMS entwirft und implementiert API-Architekturen für Enterprise-Kunden — REST, GraphQL und gRPC. Kontaktieren Sie uns für eine Architekturberatung.