GraphQL vs REST

REST-APIs stellen Ressourcen unter festen URLs bereit, sodass ein Bildschirm, der Nutzerdaten, die Beiträge dieses Nutzers und die Kommentare zu diesen Beiträgen benötigt, drei sequenzielle HTTP-Anfragen absetzen muss: GET /users/42, GET /users/42/posts, GET /posts/7/comments. Jede Antwort liefert alle vom Server definierten Felder – häufig 10 bis 20 Felder pro Objekt, obwohl der Client möglicherweise nur 3 oder 4 davon benötigt. Das Overfetching multipliziert sich über Mobilfunknetze hinweg, und die Wasserfallstruktur (jede Anfrage blockiert auf der vorherigen Antwort) erhöht die Latenz proportional zur Round-Trip-Zeit, typischerweise 50 bis 150 ms pro Hop bei einer 4G-Verbindung.

GraphQL fasst alle drei Anfragen in einem einzigen POST /graphql zusammen, der eine typisierte Abfrage trägt, die exakt die benötigten Felder benennt. Die Resolver-Schicht des Servers fächert die Abfrage parallel zu den Datenquellen auf und gibt eine einzige strukturierte JSON-Antwort zurück. Der Kompromiss besteht darin, dass HTTP-GET-Caching (CDN und Browser) ohne Automatic Persisted Queries (APQ) nicht mehr greift, da POST-Bodies standardmäßig nicht gecacht werden. Das N+1-Problem verlagert sich vom Client (mehrfache Fetches) auf den Server (Resolver-Aufrufe pro Element) und muss mit Batching-Werkzeugen wie Facebooks DataLoader gelöst werden, der N einzelne Datenbankabfragen zu einem einzigen IN-Clause-Aufruf zusammenführt. Typintrospektions, starke Schema-Verträge und Graphbeziehungen machen GraphQL attraktiv für Produktteams mit vielen Konsumentenschnittstellen, führen aber zu einem Schema-Governance-Aufwand, der bei einfachen REST-APIs nicht anfällt.