Echtzeit-Kommunikation mit GraphQL I/O
Seite 4: GraphQL, der erste Lösungsschritt
Eine vielversprechende Alternative zu RPC, SOAP und REST ist das 2015 von Facebook veröffentlichte GraphQL. Wie SQL für relationale Datenbanksysteme ist GraphQL eine Abfragesprache für Daten mit Graphstruktur. Sowohl SQL als auch GraphQL lassen sich als clientorientiert charakterisieren.
Client-directed Queries
GraphQL ist nicht die einzige clientorientierte Abfragesprache. Weitere wichtige Vertreter sind SQL, OData oder SPARQL. Diese Abfragesprachen versetzen Clients in die Lage, Daten angepasster Struktur, Detailgrad und Umfang abzurufen. Sie erfüllen im Gegenzusatz zu GraphQL allerdings nicht sämtliche Anforderungen einer Omnichannel-Echtzeit-Architektur.
Bei GraphQL stellt der Server die Daten nicht in Form einzelner Funktionen oder Ressourcen bereit. Stattdessen definiert das GraphQL-Backend lediglich, welche Daten in Form von Objekten und Feldern es überhaupt gibt, wie sie in Beziehung zueinander stehen und regelt, auf welche der Daten ein Client zugreifen darf. Diese Definition ist das Schema. Dieses muss im Gegensatz zu RPC nicht explizit feingranular implementiert sein.
Einstiegspunkt, Umfang, Detailgrad und Struktur der abgerufenen Daten darf immer der Client auf Grundlage dieses Schemas formulieren. Dazu definiert er in JSON eine Wunschstruktur der Objekte und übergibt sie an den Server. Der Server antwortet schlicht exakt so, wie vom Client gefordert, gibt höchstens Nullwerte zurück, falls der Client auf bestimmte Informationen keinen Zugriff hat. Auch die Antwort des Servers erfolgt als JSON-Struktur. Die Schnittstelle wird auf Serverseite im Idealfall deshalb nur einmal definiert und implementiert, steht unter einem einzigen Endpunkt zur Verfügung und unterstützt dennoch beliebige Data Access Pattern.
Der Preis dafür ist ein geringfügig erhöhter Entwicklungsaufwand je Clientimplementierung, weil die Entwickler die konkrete Abfrage anhand des Schnittstellenkontrakts recherchieren müssen. Im Gegenzug sinkt die Nutzlast beim Datenaustausch auf ein minimales, respektive adäquates, Niveau.
Weitere Vorteile: Der HTTP-Traffic je fachlicher Gesamtabfrage sinkt, weil nur eine Anfrage für die benötigten Daten abgesetzt werden muss. Obendrein sind die Serverentwickler zu einem beliebigen Zeitpunkt während der Entwicklung in der Lage, Ergänzungen an Struktur, Umfang und Detailgrad der Daten vorzunehmen, ohne die Cliententwickler informieren zu müssen. Das vereinfacht die Implementierung und Entwicklung erheblich.
Eine letzte Anforderung der Omnichannel-Echtzeit-Schnittstelle kann aber auch GraphQL nicht vollends abdecken: Push statt Pull. Es gibt zwar mit den Subscriptions ein Event-System, das fügte Facebook aber erst später hinzu und brach dabei mit der etablierten Architektur. Während die Queries und Mutations – Mutation heißen Änderungen an den Daten – über HTTP laufen, laufen die Events hingegen über eine zusätzliche Websocket-Verbindung. Dadurch entstehen zwei Transportwelten.
Weiterhin gehören die Events zwar zum selben Schema, sind aber ein fachlich eigenständiges Konzept neben Queries und Mutations. Der Client kann sich nur vom Server benachrichtigen lassen, dass ein bestimmtes Ereignis eingetreten ist. So gesehen handelt es sich um einen RPC vom Server zum Client. Aber wann der Server den RPC auslöst, ist nicht geregelt. Auch nicht, wie der Client mit diesem Ereignis dann umzugehen hat und ob überhaupt Daten abgerufen werden. Das müssen die Entwickler implementieren. Ein Abonnement eines bestimmten Querys, etwa mit automatischer Übermittlung geänderter Daten, ist deshalb nicht möglich.
