- GraphQL versucht, das Problem des Overfetching zu lösen, aber in den meisten Enterprise-Umgebungen wurde dieses Problem bereits auf andere Weise gelöst
- In Unternehmenssystemen, in denen eine BFF-Architektur (Backend for Frontend) verbreitet ist, schrumpfen die wichtigsten Vorteile von GraphQL erheblich
- Durch Implementierungskomplexität, geringere Observability, Caching-Probleme, ID-Einschränkungen und umständliche Dateiverarbeitung steigen die Kosten im realen Betrieb deutlich
- REST ist einfach und schnell, und Fehlerbehandlung sowie Onboarding sind leichter, was es in großen Teamumgebungen effizienter macht
- Fazit: GraphQL ist in bestimmten Situationen nützlich, für die meisten Enterprise-Anwendungen aber eine überzogene Wahl
Das Problem, das GraphQL lösen will
- Das Kernziel von GraphQL ist die Vermeidung von Overfetching (unnötig übermäßige Datenabfragen)
- Clients fordern nur die Felder an, die sie benötigen, wodurch unnötige Datenübertragung reduziert wird
- Ein Vorteil ist, dass nicht bei jeder neuen UI-Anforderung Änderungen am Backend nötig sind
- In der Praxis passt dieses Idealbild jedoch nicht zur komplexen Realität
Overfetching ist durch BFF oft bereits gelöst
- Die meisten Enterprise-Frontends verwenden bereits eine BFF-Schicht (Backend for Frontend)
- Sie kombiniert Daten passend zur UI, bündelt mehrere Downstream-Aufrufe und verbirgt Backend-Komplexität
- Ein REST-basiertes BFF kann bereits nur die benötigten Daten zurückgeben, wodurch sich der Vorteil von GraphQL doppelt
- Wenn eine GraphQL-Schicht Daten aus einer REST-API holt, wandert das Overfetching lediglich eine Ebene nach unten
- GraphQL kann nützlich sein, wenn mehrere Seiten denselben Endpunkt gemeinsam nutzen, aber
- dieser Vorteil bedeutet oft nur, für ein paar eingesparte Kilobyte deutlich mehr Einrichtungs- und Wartungsaufwand in Kauf zu nehmen
Implementierungskomplexität und sinkende Produktivität
- GraphQL ist im Vergleich zu REST deutlich aufwendiger und komplexer in der Implementierung
- Zusätzliche Arbeit für Schema, Typen, Resolver und die Definition von Datenquellen ist erforderlich
- Außerdem entsteht Aufwand, Schema und Client synchron zu halten
- GraphQL optimiert den Konsum (Bequemlichkeit für Clients), opfert dafür aber die Produktion (Geschwindigkeit der Serverentwicklung)
- In Enterprise-Umgebungen sind Entwicklungsgeschwindigkeit und Einfachheit wichtiger
Probleme bei Observability und Monitoring
- Das HTTP-Statuscode-System von GraphQL ist inkonsistent
- Selbst in einer 200-Antwort können Fehler enthalten sein, was die Unterscheidung von Erfolg und Misserfolg im Monitoring erschwert
- REST ist durch 2XX/4XX/5XX klar getrennt, wodurch Dashboard-Filterung intuitiv bleibt
- Mit Apollo und ähnlichen Tools lässt sich das anpassen, aber das verursacht zusätzliche Konfiguration und mentale Belastung
- Bei der Reaktion auf Störungen im Betrieb ist es schwieriger und komplexer, Probleme zu identifizieren als bei REST
Praktische Grenzen des Cachings
- Das normalized caching von Apollo ist theoretisch stark, in der Praxis jedoch fragil und komplex
- Selbst Queries, die sich nur in einem einzigen Feld unterscheiden, werden separat behandelt und müssen manuell verknüpft werden
- Cache-Debugging wird schnell zu einem eigenen Problemfeld
- REST kann dagegen einfach die vollständige Antwort cachen und ist dadurch stabiler und leichter wartbar
Das Problem mit ID-Feld-Einschränkungen
- Apollo geht davon aus, dass alle Objekte ein Feld id oder _id besitzen
- Viele Enterprise-APIs haben jedoch keine eindeutigen IDs oder keine globalen Identifikatoren
- Um das auszugleichen, muss das BFF Logik zur Erzeugung lokaler IDs hinzufügen
- Das führt letztlich zu mehr unnötigen Feldern und zusätzlicher Logik, wodurch der Nutzen gegen Overfetching geschmälert wird
Ineffizienz bei Datei-Uploads und -Downloads
- GraphQL ist für die Verarbeitung binärer Daten ungeeignet
- In der Praxis wird meist nur eine Download-URL zurückgegeben, während die Datei selbst per REST übertragen wird
- Wenn große Datenmengen wie PDFs in GraphQL-Antworten eingebettet werden, führt das zu Leistungseinbußen
- Dadurch zerbricht das GraphQL-Ideal einer „einzigen API“
Onboarding und Lernkurve
- Die meisten Entwickler haben viel REST-Erfahrung, GraphQL muss dagegen erst gelernt werden
- Es müssen neue Konzepte wie Schema, Resolver, Query-Aufbau, Caching-Regeln und Fehlerbehandlung erlernt werden
- Dadurch verlangsamt sich das Onboarding im Team
- REST ist als „langweilige, aber hochskalierbare“ Herangehensweise für große Teams besser geeignet
Komplexität der Fehlerbehandlung
- Fehlerantworten in GraphQL sind komplex durch nullable Felder, partial data, ein
errors-Array und erweiterte Statuscodes
- Zusätzlich muss nachverfolgt werden, welcher Resolver fehlgeschlagen ist
- REST trennt dies einfach über 400/500 und ist dadurch leichter zu verstehen und zu debuggen
Fazit: GraphQL ist eine Nischentechnologie
- GraphQL ist in bestimmten Situationen ein sinnvolles Werkzeug
- In den meisten Enterprise-Umgebungen wurden die Probleme jedoch bereits mit BFF und REST gelöst
- Die eigentlichen Hauptthemen sind nicht Overfetching, sondern Observability, Zuverlässigkeit und Geschwindigkeit
- Letztlich löst GraphQL ein eng umrissenes Problem und verursacht dabei breitere Komplexität
- Das Fazit lautet: „GraphQL ist nicht schlecht, aber in den meisten Fällen nicht notwendig“
Noch keine Kommentare.