Gibt es Nachteile von GraphQL? [geschlossen]

Alle Artikel über GraphQL werden Ihnen sagen, wie wunderbar es ist, aber gibt es irgendwelche Nachteile oder Mängel? Danke dir.

Nachteile:

• Sie müssen lernen, wie Sie GraphQL einrichten. Das Ökosystem entwickelt sich immer noch schnell, so dass Sie Schritt halten müssen.
• Sie müssen die Abfragen vom Client senden. Sie können nur Zeichenfolgen senden. Wenn Sie jedoch mehr Komfort und Caching wünschen, verwenden Sie eine Clientbibliothek -> zusätzlichen Code in Ihrem Client
• Sie müssen das Schema vorher definieren => zusätzliche Arbeit, bevor Sie Ergebnisse erhalten
• Sie benötigen einen graphql-Endpunkt auf Ihrem Server => neue Bibliotheken , die Sie noch nicht kennen
• Graphql-Abfragen sind mehr Bytes als nur ein REST-Endpunkt
• Der Server muss mehr Verarbeitung durchführen , um die Abfrage zu analysieren und die Parameter zu überprüfen

Dies wird jedoch mehr als konterkariert:

• GraphQL ist nicht so schwer zu lernen
• Der zusätzliche Code beträgt nur wenige KB
• Indem Sie ein Schema definieren, verhindern Sie viel mehr Arbeit, nachdem Sie Fehler behoben und haarige Upgrades durchgeführt haben
• Es gibt viele Leute, die zu GraphQL wechseln, so dass sich ein reichhaltiges Ökosystem mit hervorragenden Werkzeugen entwickelt
• Wenn Sie in der Produktion persistente Abfragen verwenden (indem Sie GraphQL-Abfragen einfach durch eine ID und Parameter ersetzen), senden Sie tatsächlich weniger Bytes als mit REST
• Die zusätzliche Verarbeitung für eingehende Anfragen ist vernachlässigbar
• Die Bereitstellung einer sauberen Entkopplung von API und Backend ermöglicht eine viel schnellere Iteration bei Backend-Verbesserungen

Ich habe einige wichtige Bedenken für alle gefunden, die über die Verwendung von GraphQL nachdenken , und bis jetzt sind die wichtigsten Punkte:

Abfrage in unbestimmter Tiefe : GraphQL kann nicht in unbestimmter Tiefe abfragen. Wenn Sie also einen Baum haben und einen Zweig zurückgeben möchten, ohne die Tiefe zu kennen, müssen Sie eine Paginierung durchführen.

Spezifische Antwortstruktur : In GraphQL entspricht die Antwort der Form der Abfrage. Wenn Sie also in einer sehr spezifischen Struktur antworten müssen, müssen Sie eine Transformationsebene hinzufügen, um die Antwort neu zu formen.

Cache auf Netzwerkebene : Aufgrund der üblichen Verwendung von GraphQL über HTTP (ein POST auf einem einzelnen Endpunkt) wird der Cache auf Netzwerkebene schwierig. Eine Möglichkeit, dies zu lösen, ist die Verwendung von persistierten Abfragen.

Datei - Upload - Handhabung : Es gibt nichts über Datei - Upload in der GraphQL Spezifikation und Mutationen keine Dateien in den Argumenten akzeptieren. Um dies zu lösen, können Sie Dateien mit anderen APIs (wie REST) ​​hochladen und die URL der hochgeladenen Datei an die GraphQL-Mutation übergeben oder die Datei in den Ausführungskontext einfügen, sodass die Datei in den Resolver-Funktionen enthalten ist.

Unvorhersehbare Ausführung : Die Natur von GraphQL besteht darin, dass Sie die Kombination beliebiger Felder abfragen können. Diese Flexibilität ist jedoch nicht kostenlos. Es gibt einige Bedenken, die gut zu wissen sind, wie Leistung und N + 1-Abfragen.

Supereinfache APIs : Wenn Sie einen Service haben, der eine wirklich einfache API verfügbar macht, fügt GraphQL nur eine zusätzliche Komplexität hinzu, sodass eine einfache REST-API besser sein kann.

Das größte Problem , dass ich mit graphQL also sehen , ob Sie mit relationaler Datenbank verwenden , ist mit beitritt .

1. Die Tatsache, dass Sie einige Felder zulassen / nicht zulassen können, macht Verknüpfungen nicht trivial (nicht einfach). Was zu zusätzlichen Anfragen führt.

2. Auch verschachtelte Abfragen in graphql führen zu zirkulären Abfragen und können den Server zum Absturz bringen . Besondere Vorsicht ist geboten.

3. Die Ratenbegrenzung von Anrufen wird schwierig, da der Benutzer jetzt mehrere Abfragen in einem Anruf auslösen kann.

TIPP : Verwenden Sie Facebook-Dataloader die Anzahl der Abfragen bei javascript / Knoten zu reduzieren

Es wird von Jahr zu Jahr besser und im Moment wächst die Community von GraphQL und infolgedessen gibt es viel mehr Lösungen für viele Probleme, die in anderen Antworten zuvor hervorgehoben wurden. Aber um zuzugeben, was Unternehmen immer noch davon abhält, alle Ressourcen auf GraphQL zu übertragen, möchte ich einige Probleme und Lösungen auflisten, gefolgt von ungelösten.

• Cache auf Netzwerkebene - wie Bruno sagte, handelt es sich um persistierte Abfragen, und natürlich können Sie auf einem Client zwischenspeichern, und niemand hält Sie davon ab, das Caching auf Datenbankebene oder sogar Redis zu verwenden. Da GraphQL jedoch nur einen Endpunkt hat und jede Abfrage anders ist, ist diese Art der Zwischenspeicherung viel komplizierter als bei REST.
• Verschachtelte Abfragen in GraphQL führen zu zirkulären Abfragen und können den Server zum Absturz bringen - bei einer Vielzahl von Lösungen kein Problem mehr. Einige von ihnen sind hier aufgelistet
• Datei - Upload - Handling - wir haben bereits viele von Lösungen für sie

Es gibt jedoch noch einige weitere Fälle, die als Nachteile gewertet werden können:

• Übermäßiges Boilerplate (damit meine ich, dass Sie zum Erstellen einer neuen Abfrage beispielsweise Schema, Resolver und innerhalb des Resolvers definieren müssen, um GraphQL explizit zu sagen, wie Ihre Daten und Felder darin aufgelöst werden sollen. Erstellen Sie auf der Clientseite eine Abfrage mit genau zugehörigen Feldern diese Daten)
• Fehlerbehandlung - Ich muss sagen, dass dies eher mit dem Vergleich mit REST zusammenhängt. Hier ist es mit Apollo möglich,aber gleichzeitig ist es viel komplizierter als in REST
• Authentifizierung und Autorisierung - aber wie gesagt Gemeinschaft mit hervorragender Geschwindigkeiterhöhenund es gibt bereits Paar von Lösungen für dieses Ziel.

Zusammenfassend ist GraphQL nur ein Werkzeug für bestimmte Ziele und mit Sicherheit kein Patentrezept für alle Probleme und natürlich kein Ersatz für REST.

Es ist wirklich großartig, einen einzigen Endpunkt zu haben und alle Daten verfügbar zu machen. Ich finde folgende Punkte, die für GraphQL berücksichtigt werden müssen:

1. Die Implementierung des Herunterladens / Hochladens von Dateien wird schwierig (die Konvertierung in einen String ist möglicherweise nicht die beste Option für große Dateien).
2. Viel Boilerplate- und Schema-Code sowohl im Frontend als auch im Backend.
3. Befolgen und unterstützen Sie die in der GraphQL-Spezifikation angegebene Paginierung.
4. Benutzerdefinierte Reihenfolge und Priorisierungslogik für die Reihenfolge von Feldern zulassen. Beispiel, wenn wir Benutzerdaten und zugehörige Gruppen und Rollen abrufen. Ein Benutzer kann die Daten basierend auf Benutzername, Gruppenname oder Rollennamen mehrfach sortieren.
5. Authentifizierung und Autorisierung hängen vom Backend-Framework ab.
6. Stellen Sie sicher, dass die Backend-Optimierung und die Datenbankunterstützung zum Auslösen einer einzelnen Abfrage für jeden graphql-Befehl schwierig werden.

Auch sollte man die Profis nach ihrer Implementierung berücksichtigen:

1. Sehr flexibel, um neue Elemente zu unterstützen und vorhandenes Verhalten zu aktualisieren.

2. Einfache Hinzufügung von Bedingungen mithilfe von Argumenten und benutzerdefinierter Reihenfolge nach der Implementierung

3. Verwenden Sie viele benutzerdefinierte Filter und entfernen Sie alle Aktionen, die erstellt werden müssen. Beispiel: Ein Benutzer kann ID, Name usw. als Argumente haben und die Filterung durchführen. Zusätzlich können die Filter auch auf die Gruppen in den Benutzern angewendet werden.

4. Einfaches Testen der API durch Erstellen von Dateien mit allen GraphQL-Abfragen und -Mutationen.
5. Mutationen sind einfach und leicht zu implementieren, sobald das Konzept verstanden wurde.
6. Leistungsstarke Methode zum Abrufen mehrerer Datentiefen.
7. Die Unterstützung der Voyager- und GraphiQL-Benutzeroberfläche oder des Spielplatzes erleichtert die Anzeige und Verwendung.
8. Einfache Dokumentation beim Definieren des Schemas mit gültigen Beschreibungsmethoden.

Ich denke, dass Grafik im Moment Teil der Backend-Architektur sein muss, für das Hochladen von Dateien haben Sie immer noch eine reguläre API