Einbindung von GraphQL

GraphQL ist nicht an eine spezifische Datenbank oder Speicherung der Daten gebunden, was bedeutet, dass GraphQL auf praktisch jedem Server mit wenig Aufwand eingesetzt werden kann. Dadurch, dass in einem GraphQL Schema selber definiert werden muss, wie auf ein Attribut zugegriffen wird, kann man jedes Objekt sehr einfach an die Datenhaltung jedes Servers anpassen. Gleiches gilt für die Mutations, also Anfragen, die Daten schreiben. Jede dieser Mutations benötigt eine eigene Implementierung, sodass der Server selber definiert, was mit den Daten passiert. Es existieren Bibliotheken für viele Programmiersprachen, die das Aufsetzen und Benutzen vereinfacht, doch generell liefert GraphQL JSON Daten zurück, also benutze ich auch hier JSON.

II. NUTZUNG VON GRAPHQL A. Abfrage mit GraphQL Eine Anfrage an einen Server k¨onnte mit GraphQL so aussehen:
query { concert { name id place } }
Woraus ein (korrekt aufgesetzter) Server antworten könnte:
{
“data”: { “concert”: { “name”: “Peter Lustig in Concert” “id” : 27 “place”: “Bauwagen” } }
}
In diesem Falle wird also nach allen Daten mit ”concert” gefragt, von diesen wollen wir nun den Namen, die ID und den Ort wissen. Bei dieser Abfrage existiert nur ein Konzert auf dem Server, aber normalerweise würde man so mehr Datensätze zurückbekommen. In dieser Ausarbeitung benutze ich die ”GraphQL Schema Sprache” [3], da GraphQL sprachunabhängig ist und die Schemasprache sehr einfach zu lesen ist. Der Server, der in dieser Sprache geschrieben ist, müsste für das Konzertbeispiel folgende Datenstrukturen und die dazugehörigen Funktionen definieren:
type Query { concert : Concert }
type Concert { id: ID name: String place : String }
function Query_concert(request) { return request.getConcert(); }
function Concert_name(concert) { return concert.getName(); }
function Concert_place(concert) { return concert.getPlace(); }
Wie zu sehen ist, definiert GraphQL eine Baumartige Datenstruktur und dazugehörige Getter/Setter für die Felder, die nun abgefragt werden k¨onnen. Die Funktionen sich Serverspezifisch, sind je nach Datenhaltung unterschiedlich und beinflussen GraphQL nicht, also werden sie in dieser Ausarbeitung weggelassen.25
Eine REST-API k¨onnte nun genauso die Daten zurückliefern, etwa an einem Endpoint ”Concert”, jedoch kann REST nur alle Felder komplett zur¨uckliefern, während GraphQL wählen kann welche benötigt werden. Die Vorteile, die GraphQL liefert werden jedoch später deutlich. B. Ändern von Daten mit GraphQL Genauso wie von dem Server mit einer Query Daten verlangt werden, können auch Daten bereit gestellt werden. Dazu muss der Server einen Mutation Type bereitstellen. Hier wird auch noch ein Input definiert, sodass komplexe Daten, wie etwa ein komplettes Konzert akzeptiert werden können. Hierbei wird angenommen, dass die ID eines Konzertes automatisch vergeben wird und deshalb nicht mit angegeben ist.
mutation newConcert($con: Conc) { createConcert(Conc : $con) { name place } } input Conc { name: String place: String }
Diese Mutation gibt die Möglichkeit, ein neues Konzert auf dem Server zu erstellen. Um ein Konzert zu erstellen könnte eine Anfrage so aussehen:
mutation { “con”: { “name”: “Demetori”, “place”: “Tokyo, Japan” } }
Es würden der Name und Ort wieder zur¨uckgegeben werden. Die Möglichkeit, die eingetragenen oder abgeänderten Daten zu beobachten ist sehr n¨utzlich, da sofort der Einfluss auf dem Server ersichtlich und überprüfbar ist. Das REST Gegenstück zu Mutations ist der POST befehl, aber mit GraphQL könnten mehrere Mutations in eine Abfrage gesteckt werden. Wichtig ist, dass man gleichzeitig Daten abfragen kann, aber verändert werden sie nacheinander.

C. Spezifische Abfragen GraphQL unterstüzt natürlich auch das spezifische Abfragen von Daten. Eine Abfrage die die Daten des Konzertes mit dem Namen ”Demetori” heraussucht:
query { concert(name: “Demetori”) { name id place } }
Spezifizierende Eigenschaften werden in Klammern hinter dem Objekt geschrieben, von welchem ein Attribut abgefragt
werden soll, hier der Name eines Konzertes. Wobei hierbei nun nur Werte zurückgegeben werden die zu dem Konzert gehören und nicht alle Konzerte auf dem Server.
D. Serverkonfiguration Die Serverseite einer GraphQL-Anwendung ist nat¨urlich genau so wichtig wie die Clientseite, deshalb hier ein kurzes Beispiel, wie ein Anwendungsfall in ein GraphQL Schema umgesetzt werden könnte. Dazu erweitern wir das bisherige Schema um Tickets, die zu einem Konzert gehören. Jedes Ticket hat eine Id, einen Preis, eine Sitznummer und den Namen des Käufers. Da zur erstellung eines Tickets ein Konzert ben¨otigt wird, benutzt dieses Beispiel das Konzept von Variablen. Eine Variable lässt nur Werte von dem Server zu, hier ein Konzert. Beim laden der Website könnte ein Auswahlfeld mit allen verf¨ugbaren Konzerten gefüllt werden, sodass nicht beliebige Werte eingegeben werden können. Eine Realisierung als GraphQL Schema könnte nun so aussehen:
type Query { concert:Concert }
type Concert { id: ID name: String place : String tickets : Ticket[]; } type Ticket { id: ID seat: Int name: String price: Int }
input Ticket { id: ID! seat: Int! name: String price: Int } mutation Create($co:Concert, $ti: Ticket!) { createTicket(Concert: $co, ticket: $ti) { name seat price } }
Diese Implementierung stellt eine GraphQL Schnittstelle zur verfügung, über welche nun der Name und Ort eines Konzertes abgerufen werden kann. Zusätzlich kann man Tickets für ein Konzert erstellen und bekommt den Namen des Käufers, den Preis und den Sitzplatz zurückgegeben. Das Eintragen eines verkauften Tickets könnte also so aussehen:
mutation { “co”: “Sonic Hybrid Orchestra”, “ti”: { “seat”: 301,26
“name”: “Zun Korindo”, “price”: 20
}
}
Ein Vorteil gegenüber REST ist die hierachische Struktur von GraphQL. Während mit GraphQL die Anfrage, wer das Ticket mit der Nummer 42 des Konzertes ”Woodstock” gekauft hat, so aussieht:
query { concert(name:”Woodstock”) { tickets(id:”42”) { name } } }
Würde mit REST eine Anfrage verschickt werden welche Konzerte es gibt, in der Antwort gesucht werden welches den Namen ”Woodstock” trägt, die ID kopiert werden und noch eine Anfrage geschickt werden, um herauszubekommen welche Attribute das Ticket mit der ID 42 hat. Bei allen diesen Anfragen entsteht viel Overhead, also Daten, die nicht benötigt werden, werden mitgeschickt und verworfen. Sollte sich der Baum noch weiter fortstrecken (z.B. ein Käufer Objekt mit Adresse) wird der Aufwand mit REST empfindlich höher als mit GraphQL grade in mobilen Netzwerken.