...
 
Commits (2)
......@@ -51,17 +51,15 @@ geringe Datenmengen übermittelt werden!
* **Nur die benötigten Daten werden übertragen**: Wenn wir genau spezifizieren können,
welche einzelnen Datenfelder benötigt werden, wird nur das nötige Minimum übertragen.
Im Gegensatz dazu werden bei REST grundsätzlich immer alle Daten einer "Ressource" übertragen, also **"all or nothing"**, sogenanntes **"over-fetching"**
Wenn beispielsweise nur ein Bild eines Künstlers angezeigt werden soll, würden auch alle anderen
Wenn beispielsweise nur ein Bild eines Künstlers angezeigt werden soll, würden auch alle anderen
Attribute mitgeschickt werden, anstatt nur ein Link zum Bild.
Als workaround könnte man einen weiteren REST Endpunkt mit genau dieser Funktionalität anbieten,
aber immer mit Extra Aufwand!
Es gäbe zwar auch die Möglichkeit, zum Beispiel verschiedene Repräsentationen per mime-type Auswahl (also, z.B. json order html) anzufordern, nur liegt die Kontrolle dann immer noch auf der Serverseite!
aber das bedeutet immer mit extra Aufwand!
Das ist bei GraphQL nicht mehr nötig!
Eingebaute Validierung: Außerdem kann nun auch schnell überprüft werden, ob ein angefordertes Attribut überhaupt existiert:
Fehler, dass ein erwartetes `Nachname` Feld "leer" bleibt, weil stattdessen `surname` benutzt werden müsste, sind damit Vergangenheit!
* **Eingebaute Validierung**: Außerdem kann nun auch schnell überprüft werden, ob ein angefordertes Attribut überhaupt existiert:
Fehler, dass ein erwartetes `Nachname` Feld "leer" bleibt, weil stattdessen `surname` benutzt werden müsste, sind damit Vergangenheit!
<!-- later
Die Übertragung der Daten aus unserem Beispiel lässt sich schematisch ungefähr so darstellen:
......@@ -94,30 +92,17 @@ Woher weis man aber welche Attribute zu Verfügung stehen?
GraphQL besitzt ein Schema, das aus einer Liste von **Typ-Definitionen** der Entitäten mit ihren Feldern besteht.
Es ist mit einem Datenbankschema vergleichbar.
XXX notwendig?
> "...Man assoziiert HTTP allgemein mit REST mit "Ressourcen" als Kernkonzept.
>
> **Im Kontrast dazu steht GraphQLs konzeptuelles Modell eines Entitäten-Graphen.**"
>
> ["serving over http", auf graphql.org](http://graphql.org/learn/serving-over-http)
XXX notwendig?
> "Die grundlegenden Komponenten eines GraphQL-Schemas sind Objekttypen, die
> eine bestimmte Art von Objekt mit seinen Feldern darstellen, wie sie von
> einem [REST] Server abgefragt werden können"
>
> ["Schemas und Typen", auf graphql.org](http://graphql.org/learn/schema/)
Somit sind gegenüber REST auch die Beziehungen zwischen den Entitäten festgelegt.
"...Man assoziiert HTTP allgemein mit REST mit Ressourcen als Kernkonzept.
**Im Kontrast dazu steht GraphQLs konzeptuelles Modell eines Entitäten-Graphen.**"
Quelle: [graphql.org](http://graphql.org/learn/serving-over-http)
Gegenüber REST sind hier also auch die Beziehungen zwischen den Entitäten definiert.
Ein minimales Schema besteht nur aus einem **Wurzelknoten** (vom Typ **Query**),
der direkt oder indirekt Zugriff auf alle anderen Knoten im Graphen ermöglicht, wie im
Diagramm:
der direkt oder indirekt Zugriff auf alle anderen Knoten im Graphen ermöglicht, wie zum Beispiel in diesem Diagramm:
![data-topology](https://lowsky.github.io/deck-graphql-relay-talk/images/data-topology.png)
<!-- Anmerkung: hier braucht man noch ein Bild mit den Spotify-Daten ... -->
_XXX: Das Diagramm könnte noch schöner werden, oder bessere Qualität, wenn als SVG importiert... ?_
[Quelle: google drawing:](https://docs.google.com/drawings/d/13P005a7rGZe35IGk4Qy0DF2r-b1AaYS996ZHZqYF7p4/edit)
![data-topology](https://blog.codecentric.de/files/2017/12/GraphQL-data-topology.jpg)
## Schema Definition - Variante 1
......@@ -193,7 +178,7 @@ Da graphiql beim Start unseres Servers aktiviert ist(per `graphiql:true`), kann
![graphiql-hi](https://blog.codecentric.de/files/2016/09/graphiql-hi.png)
Im Editor-Fenster links wurde automatisch die Abfrage eingetragen und ausgeführt.-
Hier können wir durch das Schema tool-gestützt SyntaxHighlighting und auch **Auto-Vervollständigung** nutzen!
Hier können wir durch das Schema tool-gestützt SyntaxHighlighting und auch **Autovervollständigung** nutzen!
![graphiql-hi-with-docs](https://blog.codecentric.de/files/2016/09/graphiql-hi-with-docs.png)
......
......@@ -164,7 +164,7 @@ app.use('/graphql', expressGraphQL(req => ({
Hinweis: Alternativ hätten wir diese Logik auch direkt in die Schema Definition 1 hinzufügen können.
Dadurch würde die Logik für die Datenabfrage mit der Typdefinitionen gemischt sein.
Ich bevorzuge deshalb die zweite Variante der Schema-Definition, denn dabei lässt sich der Logikanteil besser mit Unit-Tests versehen, und die Schema-Definition bleibt überschaubarer.
Ich bevorzuge deshalb die zweite Variante der Schema-Definition, denn dabei lässt sich der Logik Anteil besser mit Unit-Tests versehen, und die Schema-Definition bleibt überschaubarer.
Hinweis: Spotify verlangt seit Sommer 2017, dass jeder Request per Header authentisiert ist.
Ein OAuth Token erhält man am einfachsten in der ["interactive API console" auf der Spotify Web API Seite](https://developer.spotify.com/web-api/console/)
......@@ -241,7 +241,7 @@ erhalten wir:
Der Quellcode der [Demoversion](https://spotify-graphql-server.herokuapp.com/graphql) findet sich [auf Github](https://github.com/lowsky/spotify-graphql-server)
## Was wurde nicht behandelt:
## Was wurde nicht behandelt?
* Caching
* Modifizierung
* Subscriptions
......