GraphQL

Erfunden von Facebook. Du definierst ein Schema (Typen): type User { name: String, friends: [User] }. Das Frontend-Team liebt es, weil sie das Backend-Team nicht mehr nerven müssen ("Baut mir bitte einen Endpoint für Mobile, der nur den Namen liefert!"). Sie schreiben einfach eine andere Query.

Praxisroutine

In der Praxis lernst du GraphQL, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. N+1 Problem

Die Performance-Falle. Query: "Gib mir 10 User und deren Freunde." Der Server lädt 1x User-Liste (SQL). Dann macht er für jeden der 10 User eine extra SQL-Abfrage für die Freunde. 1 + 10 = 11 Queries. Bei 1000 Usern bricht die DB zusammen. Lösung: DataLoader (Batching). Er sammelt alle IDs und macht eine Abfrage: SELECT * FROM friends WHERE user_id IN (...).

2. Caching

REST ist einfach zu cachen (per URL). /user/1 ist immer gleich. GraphQL läuft immer über POST /graphql. Für den Browser sieht jede Anfrage gleich aus. Caching muss also in der App (Client-Side Caching wie Apollo Client) passieren, nicht im Netzwerk.

1. AST Analysis und Complexity Limits

GraphQL erlaubt der Frontend-App gnadenlose Macht. Was hindert den Client an einem "Denial-of-Service" (DoS), indem er eine 100-Level tiefe rekursive Abfrage schickt (user -> posts -> comments -> author -> posts ...)? Backend-Teams müssen im Resolver Complexity Estimation via Abstract Syntax Tree (AST) Routing parken. Bevor GraphQL die Query an die DB flutet, parst das Framework sie und weist jedem Feld Weightings zu (z.B. User = 1, Post = 5). Erreicht die Akkumulation in der Graph-Traverse z.B. 1000 Punkte, wird die Query hart verworfen. Ohne strenges Depth Limiting, Complexity Scoring und Rate Limiting wird ein öffentliches GraphQL-Gateway vom kleinsten Scrape-Skript in Millisekunden down gezogen.

2. Federation und The Supergraph (Apollo)

In Microservices ist ein Monolithisches GraphQL-Schema ein Anti-Pattern (das "God API" Problem). Die Lösung heißt GraphQL Federation (Apollo). Das Cart-Team deployed einen CartService, das Review-Team einen ReviewService. Beide haben eigene, kleine GraphQL-Endpoints. Ein vorgelagerter zentraler Apollo-Gateway reist als Architekt durch die Services, liest die Subgraphen und flickt sie zu einem "Supergraph" zusammen. Stellt der Client die komplexe Query { User { Name, CartTotal } }, trennt das Gateway die Query, leitet den ersten Branch an Serivce A, den zweiten Teil parallel an Service B, kombiniert JSON-Streams performant als Merge-Block in RAM, und schickt nur ein fertiges Päckchen zum Client aus.

3. Persisted Queries und Frontend-Compiling

GraphQL Queries in der HTTP POST-Payload sind enorm groß (oft hunderte Zeilen Strings). Das fraß Mobilfunk-Daten und zerstörte HTTP/GET basiertes CDN (Cloudflare) Caching, da POST nicht gecachet wird. Profis nutzen Persisted Queries. Beim Build-Schritt der React-App hashen Webpack/Relay-Compiler jede statische graphql-Query aus den Dateien (Hash: 3bcx9...). Die Mobile App schickt ab sofort nur noch via GET /graphql?hash=3bcx9 das Minimal-Kürzel. Der Server kennt das Dictionary, repliziert lokal die AST Query, und – weil es nun idempotent via GET agiert – glühen die Edge-Knoten auf Fastlys CDNs wieder perfekt.