DailydoseofWeb schrieb am 21.07.2018 20:20:
Hier wird ins Feld geführt, dass GraphQL lediglich einen Request braucht, während man bei REST insgesamt 3 Requests brauchen würde. Tatsächlich ist das Beispiel falsch, da von einem spezifischen Verhalten bei dem REST Beispiel ausgegangen wird, was keinesfalls vorgeschrieben ist. Hier wird davon ausgegangen, dass über die Schnittstelle der User, seine Posts und seine Follower einzeln angefordert werden müssen.
Das Beispiel ist nicht falsch.
Die Struktur der URIs ist bei einer REST Architektur im Prinzip schon vorgegeben, nur nicht ordentlich formal spezifiziert.
Objekte entsprechen Ressourcen, Unterobjekte sind somit Unterressourcen.
Wenn man eine REST Schnittstelle hat, würde das genauso aussehen. Wenn's nicht so aussieht ist's keine REST Schnittstelle… ;-)
Das GraphQL Beispiel weiter unten impliziert allerdings, dass diese Daten auch Teil des User-Objektes sind, daher eigentlich auch von der REST Schnittstelle beim Abfragen des Users zurückgegeben werden müssen. Entweder geht man in dem Beispiel von einem unterschiedlichen Datenmodell aus, oder es gibt Details, die nicht erwähnt sind.
Ich glaube Du hast das Konzept noch nicht ganz kapiert. Die gezeigte GraphQL Abfrage impliziert keineswegs, dass Daten wie Follower Teil irgendwelcher User-Objekte (die es ĂĽbrigens so gar nicht geben muss) sind.
Der ganze Gag an GraphQL ist, dass die Angeforderte Datenstruktur nicht vorher vorgegeben ist. D.H. Du kannst z.B. verschiedene "User-Objekte" liefern lassen (z.B. nur mit einem Feld für Namen, aber auch mit allen möglichen anderen Feldern, und verknüpften Daten).
Das ist Tatsächlich so wie mit einer SQL Abfrage. Um ein Resultset wie in dem Beispiel zu erhalten, müssten bei einer relationalen Datenbank die Informationen zu den Followern auch nicht in der User-Tabelle stehen! Sogar ganz im Gegenteil, das wäre arg falsch. Man würde hingegen die User-Tabelle über eine Cross-Tabelle, die die Verknüpfung zu den Followern enthält, wahrscheinlich mit sich selbst joinen. Das man auch Informationen zu den Followern im Ergebnis sehen will, wird hierbei in der SQL Query explizit beschrieben. Man könnte aber auch ggf. andere Tabellen joinen, mit Unions könnte man Teile von anderen Tabellen "dran kleben", und man ist natürlich frei, Spalten zu wählen, oder auch "virtuelle" Spalten durch Aggregatsfunktionen berechnen zu lassen.
GraphQL ist grundsätzlich recht ähnlich, da es auch eine Abfragesprache ist. GraphQL funktioniert halt nur nicht auf Tabellen, sondern auf Objekten in einem Graphen. Aber das Konzept der getrennten Datenstrukturdefinition, und flexibler ad hoc Queries darauf, ist das gleiche wie bei SQL.
Ăśbrigens gibt es ein Framework das gerade stark gehyped wird, mit dem man direkt SQL DBs mithilfe von GraphQL ĂĽber eine Web-API anzapfen kann:
https://www.prisma.io/
Einfache Backends für die heute typischen Webclients kann man damit mit ein paar Zeilen deklarativen Code implementieren. Das Framework stellt dabei nicht nur eine Schnittstelle zur DB bereit, sondern bringt auch typische API Backend Funktionalität gleich mit. Dabei ist die Geschichte von Haus aus performant (JVM), und skaliert auch schön horizontal out-of-the-box. Ich glaube es gibt kaum etwas ähnliches, mit dem man derartig einfach eine API mit einer DB dahinter in die Cloud stellen kann!
Letztendlich könnte man hier mit REST auch den selben Effekt erzielen.
Nein, eben nicht.
Man kann natürlich alle Daten, so wie sie für genau die gewünschte Query benötigt werden Serverseitig aggregieren. Das was aber dabei herauskommt ist keine REST Schnittstelle mehr! Das ist dann eine custom "JSON-HTTP-RPC" Schnittstelle. So etwas ist zwar effizient, aber recht inflexibel. (S. Artikel ;-))
Deswegen hat man ja REST ersonnen. Das braucht aber dann wegen der erhöhten Flexibilität mehrere Requests, und ist auch ätzend weiterzuentwickeln (wird ganz schnell furchtbar komplex, wenn man es "richtig" macht, und nicht zwischenzeitlich auf "JSON-HTTP-RPC" zurückfällt – weswegen es übrigens auch kaum echte REST Schnittstellen in the wild gibt…).
So hat man GraphQL erfunden. Aber genau diese Entwicklung ist ja schon sehr gut im Artikel beschreiben worden. :-)