Seite 12 - GraphQl

Wenn die Schreibseite eines Systems in einem Event Store lebt, muss die Leseseite nicht dasselbe Datenmodell verwenden. GraphQL und Event Sourcing passen erstaunlich gut zusammen, weil GraphQL-Queries genau das leisten, was CQRS-Lesemodelle brauchen, flexible, projektionsbasierte Abfragen ohne den Event-Strom selbst zu berühren.

API Platform liefert GraphQL-Unterstützung praktisch out of the box, bringt dafür aber einen kompletten Ressourcen-, Filter- und Serialisierungs-Stack mit, der nicht jedes Projekt braucht. Wer nur eine schlanke GraphQL-Schnittstelle über ein bestehendes Symfony-Projekt legen will, kommt mit der Basisbibliothek webonyx/graphql-php oft schneller und mit weniger Overhead ans Ziel, weil Schema und Resolver dort direkt und explizit definiert werden.

Ein öffentlich erreichbarer GraphQL-Endpunkt, der beliebige Mutationen akzeptiert, ist ein offenes Einfallstor für Datenmanipulation, Spam und automatisierte Angriffe. GraphQL Persisted Mutations schließen diese Lücke, indem nur eine serverseitig vorab genehmigte Liste von Operationen überhaupt ausgeführt werden darf, alles andere wird abgelehnt, bevor auch nur ein Resolver aufgerufen wird.

Das ursprüngliche GraphQL Playground von Prisma ist seit Jahren archiviert und bekommt keine Updates mehr, trotzdem läuft es in vielen Projekten noch als Standard-Explorer. Wer heute eine solide GraphQL Playground Alternative sucht, landet fast immer bei GraphiQL 2 oder Apollo Sandbox, zwei Tools mit unterschiedlicher Philosophie für Auth-Handling, Team-Collaboration und Self-Hosting.

Wer ein Headless CMS mit GraphQL anbindet, trifft eine Architektur-Entscheidung, die über Jahre hinweg Content-Modeling, Caching und Team-Workflows bestimmt. Strapi, Contentful und Magento GraphQL setzen dieselbe Spezifikation völlig unterschiedlich um, mit Konsequenzen für Query-Komplexität, Autorisierung und die Frage, wo Content endet und Commerce-Daten beginnen.

API Platform generiert GraphQL-Schemata automatisch aus PHP-Entities – das klingt nach der einfachsten Lösung. In der Praxis zeigen sich aber schnell Grenzen: komplexe Mutations, domänenspezifische Validierung, Performance-Probleme durch N+1 und fehlende Kontrolle über das generierte Schema. Dieser Artikel zeigt, wann API Platform GraphQL ausreicht und wann es erweitert oder ersetzt werden muss.

Das richtige Tool macht den Unterschied zwischen blindem Entwickeln und strukturierter API-Pflege. GraphiQL, Apollo Studio, GraphQL Hive und Inspector decken unterschiedliche Phasen des API-Lebenszyklus ab – von der explorativen Entwicklung bis zum produktiven Schema-Management im Team.

Introspection ist eine der elegantesten Eigenschaften von GraphQL, denn sie erlaubt es, das komplette Schema per Query abzufragen. Genau das macht sie in Produktion riskant: Jeder, der die API kennt, kann interne Feldnamen, Mutationen mit Zugriff auf sensible Daten und sogar Deprecation-Kommentare auslesen, ohne einen einzigen Endpunkt zu erraten. Wer Introspection nicht bewusst absichert, liefert Angreifern die vollständige Landkarte der eigenen API.

Eigene Felder in den Customer-Typen integrieren, Resolver mit Token-Validierung absichern, Extension Attributes korrekt exponieren und sensible Daten auf Feldebene schützen – alles in einem durchgängigen Praxisbeitrag.

Eine bestehende REST-API auf einen Schlag durch GraphQL zu ersetzen, ist der sicherste Weg, Produktionsausfälle zu provozieren. Mit einer BFF-Schicht, dem Strangler-Fig-Pattern und einem klaren Rollout-Plan lässt sich REST zu GraphQL migrieren, während beide Protokolle monatelang parallel und risikofrei koexistieren.