Warum ich nach 6 Jahren mit GraphQL aufgehört habe

• Nach 6 Jahren Einsatz seit 2018 bin ich zwar ein echter GraphQL-Enthusiast gewesen, inzwischen aber skeptisch geworden.
• Ich möchte erklären, warum ich GraphQL heute nicht mehr empfehle und was ich für die bessere Alternative halte.

Angriffsfläche

• GraphQL birgt das Risiko, durch das Offenlegen einer Abfragesprache die Angriffsfläche zu vergrößern.
• Besonders wichtig sind dabei Probleme rund um die Autorisierung.
  • Für jedes Feld sind angemessene Berechtigungsprüfungen erforderlich.
  • Bei einer REST API ist es einfacher, die Berechtigungen pro Endpoint zu prüfen.

Autorisierung

• Für jedes Feld müssen die Benutzerberechtigungen geprüft werden.
• Bei einer REST API ist es einfacher, die Berechtigungen pro Endpoint zu prüfen.

Rate Limiting

• GraphQL-Abfragen haben keine feste Größenbegrenzung und können den Server stark belasten.
• Eine mögliche Methode ist, die Komplexität von Abfragen zu schätzen und Queries zu begrenzen, die eine bestimmte Komplexität überschreiten.
• Bei einer REST API ist es einfacher, die Anzahl der Requests zu begrenzen.

Query-Parsing

• Fehlerhafte Query-Strings können dazu führen, dass der Server übermäßig viel Speicher verbraucht.
• Eine Möglichkeit ist, eine maximale Fehleranzahl festzulegen, um das Parsing abzubrechen.

Performance

Datenabruf und das N+1-Problem

• Field Resolver können externe Datenquellen mehrfach aufrufen.
• Mit dem Dataloader-Pattern lässt sich dieses Problem lösen.
• Bei REST ist es einfacher, das N+1-Problem im Controller zu lösen.

Autorisierung und das N+1-Problem

• Autorisierungscode kann das N+1-Problem verursachen.
• Bei REST tritt dieses Problem nicht auf.

Kopplung

• In GraphQL-Codebasen ist die Business-Logik stark an die Transportschicht gekoppelt.
• Integrationstests sind notwendig, und Debugging ist schwierig.

Komplexität

• Verschiedene Methoden zur Lösung von Sicherheits- und Performance-Problemen in GraphQL erhöhen die Komplexität der Codebasis.
• REST-Lösungen sind in der Regel einfacher.

Alternativen

• Empfohlen wird eine JSON-REST-API mit OpenAPI 3.0+.
• Wenn Clients in einer statisch typisierten Sprache geschrieben sind, kann OpenAPI die bessere Wahl sein.
• OpenAPI kann automatisch typsicheren Client-Code generieren.

Meinung von GN⁺

• GraphQL ist leistungsfähig, aber die Lösung von Sicherheits- und Performance-Problemen erfordert viel Aufwand.
• REST APIs sind vergleichsweise einfach und in vielen Fällen besser geeignet.
• OpenAPI bietet Typsicherheit und automatisierte Tools, die die Entwicklerproduktivität steigern können.
• Bei der Einführung von GraphQL sollten Sicherheits- und Performance-Probleme sorgfältig berücksichtigt werden.
• Es ist wichtig, die Vor- und Nachteile von REST und GraphQL zu vergleichen und die passende Technologie für das jeweilige Projekt auszuwählen.

[savvykang]

GraphQL ist irgendwie nervig (2022)

[yangeok]

Die Ära des RPC-Hypes beginnt.

[ahwjdekf]

Na klar … nur weil etwas schick und fancy daherkommt, sollte man nicht sofort zuschnappen und es in den Himmel loben. Jetzt ist wohl das ORM an der Reihe. Dein Ende ist auch nicht mehr fern …

[rockmkd]

ORMs gibt es inzwischen seit mehr als 20 Jahren ...

[cometkim]

2018 war PQ wohl auch nicht mehr besonders neu (tatsächlich wurde es schon empfohlen, als GraphQL erstmals vorgestellt wurde), daher ist es überraschend, dass man es 6 Jahre lang nicht ausprobiert hat...

[surfindia]

GraphQL komplett in Eigenregie zu implementieren, ist aus allen oben genannten Gründen in Bezug auf Komplexität und Stabilität schwierig. Es scheint besser zu sein, eine Layer wie Hasura oder PostGraphile über die Datenbank zu legen und je nach Bedarf entweder GraphQL oder REST zu dieser Layer hinzuzufügen.

[GN⁺]

Hacker-News-Kommentare

• Nach der Einführung von GraphQL traten viele Probleme auf. Wegen Berechtigungsverwaltung und Performance-Problemen möchte man es nicht mehr verwenden. Nur im Frontend kann es sinnvoll sein, aber die Integration mit dem Backend ist komplex.
• Nachdem man zuerst REST gelernt und dann gRPC ausprobiert hatte, wirkte eine typsichere API attraktiv. GraphQL bietet nicht viele Vorteile und ist nur nützlich, wenn es wie eine Datenbank funktioniert.
• Es wurde an zwei GraphQL-Projekten gearbeitet; anfangs begann alles klein, wurde mit der Zeit aber komplex. Debugging ist schwierig und es treten Performance-Probleme auf. REST und RPC sind einfacher und leichter zu verwalten.
• Als Gründer von Hasura hat man die Entwicklung der Nutzung von GraphQL beobachtet. GraphQL ist ohne eine Daten-Layer sehr schwer aufzubauen. GraphQL auf REST zu setzen ist ineffizient. Der wichtigste Anwendungsfall für GraphQL ist, wenn es mehrere Datenkonsumenten gibt.
• Frontend-Ingenieure speichern Queries in einer zentralen Bibliothek und verwenden sie wieder, was im Grunde bedeutet, GraphQL wie REST zu benutzen.
• Aus der Erfahrung mit OpenAPI, GraphQL, JSON/HTTP und gRPC heraus kann das Einschränken von GraphQL-Queries Performance- und Sicherheitsprobleme abmildern. Buf Connect ist für die meisten Projekte der passendste Kompromiss.
• Aus der Erfahrung mit GraphQL bei Facebook haben viele Menschen die Probleme gar nicht, die GraphQL eigentlich lösen soll. Facebook nutzt GraphQL, um Versionierung und komplexe Objektmodelle zu handhaben.
• Der Grund, warum GraphQL bei Facebook gut funktioniert, ist, dass alle Nutzer eingeloggt sind und Sicherheit in jedem Feld verankert ist. Bei einer SPA mit Login-Anforderungen kann GraphQL nützlich sein.
• Beim Einsatz von GraphQL war der erste Eindruck gut, am Ende waren jedoch viel zusätzliche Arbeit und Doppelungen nötig. Besser wäre es gewesen, mit JSON-RPC-artigen Endpunkten zu beginnen und die benötigten Funktionen schrittweise hinzuzufügen.
• In einem kleinen Projekt war fast alles an GraphQL gut. Mit Apollo Client und graphql-codegen wurden Typen und Funktionen für Vue 3 erzeugt. Es gab einige Probleme, aber auf Typebene wurden viele Fehler abgefangen.