Gibt es irgendwelche Nachteile von GraphQL?

Nachteile:

• Sie müssen lernen wie Sie GraphQL einrichten. Das Ökosystem entwickelt sich immer noch rasant weiter, sodass Sie Schritt halten müssen.
• Sie müssen die Abfragen vom Client senden, Sie können nur Zeichenfolgen senden, aber wenn Sie mehr Komfort und Caching möchten, verwenden Sie eine Clientbibliothek -> zusätzlicher 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, den Sie noch nicht kennen
• Graphql-Abfragen sind mehr Bytes als nur ein REST Endpunkt
• Der Server muss weitere Verarbeitung ausführen, um die Abfrage zu analysieren und die Parameter zu überprüfen

Diesen wird jedoch mehr als entgegengewirkt:

• GraphQL ist nicht so schwer zu lernen
• Der zusätzliche Code ist nur einige KB
• Indem Sie ein Schema definieren, werden Sie verhindern, dass danach viel mehr Arbeit anfällt Fehler beheben und haarige Upgrades ertragen
• Es gibt eine Menge Leute, die auf GraphQL umsteigen, so dass sich ein reiches Ökosystem mit hervorragenden Werkzeugen entwickelt
• Wenn Sie persistente Abfragen in der Produktion 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 eines saubere Entkopplung von API und Backend ermöglicht eine viel schnellere Iteration bei Backend-Verbesserungen

Ich habe einige wichtige Bedenken für alle, die GraphQL in Betracht ziehen gefunden, 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, werden Sie muss etwas paginieren.

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 dies tun Fügen Sie eine Transformationsebene hinzu, um die Antwort neu zu gestalten.

Cache auf Netzwerkebene : Aufgrund der üblichen Verwendung von GraphQL über HTTP (A POST auf einem einzelnen Endpunkt) Der Cache auf Netzwerkebene wird schwierig. Eine Möglichkeit zur Lösung besteht in der Verwendung von persistierten Abfragen.

Umgang mit dem Hochladen von Dateien : Die GraphQL-Spezifikation enthält keine Informationen zum Hochladen von Dateien, und Mutationen akzeptieren keine Dateien in den Argumenten. Um dieses Problem zu beheben, können Sie Dateien mithilfe anderer APIs (z. B. REST) ​​hochladen und die URL der hochgeladenen Datei an die GraphQL-Mutation übergeben oder die Datei im Ausführungskontext einfügen, sodass die Datei in den Resolver-Funktionen enthalten ist.

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

Super Simple APIs : Falls Sie einen Dienst haben, der eine wirklich einfache API verfügbar macht, wird GraphQL nur eine zusätzliche Komplexität hinzufügen, so dass ein einfaches REST API kann besser sein.

Das größte Problem, das ich mit graphQL sehe, wenn Sie mit relationalen Datenbanken arbeiten, ist mit Joins.

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

2. Auch verschachtelte Abfragen in graphql führen zu zirkulären Abfragen und können Absturz des Servers. Besondere Vorsicht ist geboten.

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

TIP : Verwenden Sie den Datenlader von Facebook, um die Anzahl der Abfragen bei Javascript/Node zu reduzieren

Es wird von Jahr zu Jahr besser und die Community von GraphQL wächst derzeit. Infolgedessen gibt es viel mehr Lösungen für viele Probleme, die bereits in anderen Antworten erwähnt wurden. Aber um zuzugeben, was Unternehmen noch davon abhält, alle Ressourcen auf GraphQL zu übertragen, möchte ich einige Probleme und Lösungen auflisten, denen ungelöste folgen.

• Cache auf Netzwerkebene - as Bruno sagte, dass es sich um persistierte Abfragen handelt und Sie natürlich auf einem Client zwischenspeichern können und niemand Sie daran hindert, 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 wesentlich komplizierter als bei REST.
• Verschachtelte Abfragen in GraphQL führen zu zirkulären Abfragen und können den Server zum Absturz bringen - Mit einer Vielzahl von Lösungen kein Problem mehr. Einige von ihnen sind aufgeführt hier
• Handling File Upload - wir haben bereits vieleLösungen dafür

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

• Übermaß an Boilerplate (damit meine ich, dass Sie für das Erstellen von beispielsweise neuen Abfragen Schema, Resolver und definieren müssen innerhalb des Resolvers, um GraphQL explizit mitzuteilen, wie Ihre Daten und Felder aufgelöst werden sollen, auf der Clientseite eine Abfrage mit genau den Daten entsprechenden Feldern erstellen)
• Fehlerbehandlung - Ich muss sagen, dass es mehr mit dem Vergleich mit REST zu tun hat. Hier ist es mit apollo möglich, aber gleichzeitig ist es viel komplizierter als in REST
• Authentifizierung und Autorisierung - aber wie gesagt, die Community wächst mit herausragender Geschwindigkeit und es gibt bereitsPaarvonLösungen für dieses Ziel.

Zusammenfassend lässt sich sagen, dass GraphQL nur ein Tool für bestimmte Ziele ist und mit Sicherheit kein Wundermittel 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 zu beachten sind:

1. Die Implementierung des Datei-Downloads/-Uploads wird schwierig (das Konvertieren in einen String ist möglicherweise nicht die beste Option für große Dateien).
2. Eine Menge Boilerplate- und Schema-Code sowohl im Frontend als auch im Backend.
3. Befolgen und unterstützen Sie die Paginierung in der GraphQL-Spezifikation.
4. Erlaube benutzerdefinierte Reihenfolge und Priorisierungslogik für die Reihenfolge der Felder. Beispiel, wenn wir Benutzerdaten und zugehörige Gruppen und Rollen abrufen. Ein Benutzer kann die Daten nach Benutzername, Gruppenname oder Rollenname sortieren.
5. Authentifizierung und Autorisierung hängen vom Backend-Framework ab.
6. Stellen Sie sicher, dass die Back-End-Optimierung und die Datenbankunterstützung zum Auslösen einer einzelnen Abfrage für jeden graphql-Befehl möglicherweise schwierig werden.

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

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

2. Einfach zu implementierende Bedingungen durch Argumente und benutzerdefinierte Reihenfolge

3. Verwenden Sie viele benutzerdefinierte Filter und entfernen Sie alle Aktionen, die erstellt werden müssen. Ein Benutzer kann beispielsweise ID, Name usw. als Argumente verwenden 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 unkompliziert und einfach umzusetzen, sobald das Konzept verstanden wurde.
6. Leistungsstarke Methode zum Abrufen mehrerer Datentiefen.
7. Die Unterstützung von Voyager und GraphiQL UI oder Playground erleichtert die Anzeige und Verwendung.
8. Einfache Dokumentation beim Definieren des Schemas mit gültigen Beschreibungsmethoden.

Ich denke, dass graphql im Moment Teil der Backend-Architektur sein muss