Seite 2 - GraphQl

Pagination ist in GraphQL keine Kleinigkeit. Wer einfach Offset und Limit ins Schema schreibt, hat eine funktionierende Lösung – aber keine robuste. Cursor-basierte Pagination nach der Relay-Spezifikation ist aufwändiger, löst aber genau die Probleme, die Offset-Pagination bei wachsenden Datenmengen und parallelen Schreibzugriffen schafft.

Caching Strategien entscheiden darüber, wie oft eine React-Anwendung Daten neu lädt, wie schnell Änderungen sichtbar werden und wie viel Speicher der Client dafür verbraucht. SWR, TanStack Query und Apollo Client lösen dieselbe Grundaufgabe mit unterschiedlichen Caching Strategien, von einfachem Stale-While-Revalidate bis zur vollständigen Objektnormalisierung, mit spürbaren Konsequenzen für Konsistenz und Wartungsaufwand.

Wer GraphQL-APIs nur mit End-to-End-Tests absichert, bekommt eine langsame, brüchige Testsuite. Wer nur Unit-Tests schreibt, übersieht Fehler in der Schema-Komposition. Eine durchdachte GraphQL Testing Pyramide verteilt Testaufwand gezielt über Resolver-Ebene, Schema-Ebene und echte Nutzerflüsse, mit klaren Kriterien, welche Ebene welche Fehlerklasse abdeckt.

Ein offener GraphQL-Endpunkt erlaubt jedem Client, beliebige Queries gegen das Schema zu formulieren, auch solche, die nie für den produktiven Einsatz gedacht waren. Query-Whitelisting kehrt dieses Prinzip um: Nur vorab bekannte, geprüfte Queries werden ausgeführt, alles andere wird abgelehnt, bevor es den Resolver erreicht.

API Platform generiert aus jeder Ressource automatisch Queries und Mutations, doch sobald eine Aktion mehrere Ressourcen kombiniert oder Echtzeit Updates gefragt sind, braucht es einen eigenen GraphQL Resolver. Dieser Artikel zeigt, wie Query Resolver, Mutation Resolver mit dedizierten Input Klassen und Mercure basierte Subscriptions in API Platform zusammenspielen.

Ein Feld einfach aus dem Schema zu löschen ist keine Deprecation, sondern ein Breaking Change. Ein sauberer GraphQL Deprecation Workflow markiert Felder mit der @deprecated-Direktive, misst ihre tatsächliche Nutzung und entfernt sie erst, wenn die Daten zeigen, dass kein Konsument mehr betroffen ist.

Persisted Queries lösen zwei Probleme gleichzeitig: Sie reduzieren die übertragene Datenmenge und schließen eine Sicherheitslücke, die in öffentlichen GraphQL-APIs oft übersehen wird. Wer beliebige Queries akzeptiert, gibt Angreifern freie Hand. Wer nur bekannte Queries erlaubt, gewinnt Kontrolle — ohne Flexibilität komplett zu opfern.

Eine einzelne GraphQL-Mutation wirkt nach außen atomar, verbirgt innen aber oft mehrere Schreibschritte, Zahlungsbuchung, Lagerreservierung, Versandauftrag. Transaktionale Mutations in GraphQL müssen genau diese Mehrstufigkeit absichern, mit Unit of Work, Idempotency Keys und dem Saga-Pattern für verteilte Konsistenz.

Ein Schema mit drei verschiedenen Stilen für dieselbe Sache kostet jedes Team Zeit, Nerven und Vertrauen in die API. Klare GraphQL Naming Conventions für Typen, Felder, Mutations und Enums machen ein Schema selbsterklärend und lassen sich mit Style Guide und Linting dauerhaft im Team verankern.

Bei REST-APIs verlassen sich viele Teams auf simple Content-Type-Prüfungen oder auf die Annahme, dass Cross-Site-Requests ohnehin nur GET-Anfragen betreffen. GraphQL bündelt Queries und Mutations hinter einem einzigen POST-Endpunkt und macht diese Annahmen wertlos. Wer eine GraphQL-API mit Cookie-basierten Sessions betreibt, braucht einen expliziten CSRF-Schutz, der die Besonderheiten des einzelnen Endpunkts berücksichtigt.