GraphQL wird in der Microservice Welt zunehmend bekannter und etabliert sich als Alternative zu REST Schnittstellen. Woran liegt das und was bedeutet das für die eigene Architekturentscheidung?

Bei den meisten Backend-Services die seit 2015 entwickelt werden, wird eine REST-Schnittstelle als Kommunikationsinterface verwendet. Das REST-Paradigma unterschied sich zu den bis dato oft verwendeten Verfahren SOAP und RPC, indem es keinen entfernten Funktionsaufruf anbietet. Es betrachtete vielmehr die Daten als eine Ressource, deren Zustand abgefragt oder verändert werden konnte. Vorteilhaft war die damit einhergehende Verwendung von Standardtechnologien (sind eh da) aus dem WWW (Web-Server, HTTP-fähige Clients, JSON Parser).

Der Beliebtheit von REST steht dabei oft im Weg, dass die Ressourcen, also die Daten, in einer recht statischen Struktur abgerufen werden. Will ein Client zum Beispiel eine Produktübersicht anzeigen, so werden oft wesentlich mehr Attribute mitgesendet, als zur Darstellung benötigt werden. Werden auf der Webseite mehrere Ressourcen vom Server geladen, werden viele Anfragen gestellt. Das resultierende Performance-Problem führt in der Praxis oft zu Workarounds, z.B. speziellen API-Endpunkten für verschiedene Anfragen. Für Clients wäre es hingegen häufig praktischer, direkt ein SQL-Statement zur Datenbankabfrage zu senden, um genau die Informationen zu erhalten, die für die Darstellung notwendig sind. Da die Attribute nicht selbsterklärend sind, bedeutet es Arbeit für das Dokumentieren und studieren der Dokumentation – ein negativer Produktivitätsfaktor für die Entwicklung.

Bühne frei für GraphQL.

In einem GraphQL-Statement wird die exakte Struktur der benötigten Daten beschrieben, die der Service zurück liefern soll. Somit wird die Kommunikation zwischen Client und Service effizienter (z.B. weniger Requests) und leichter wartbar. Als Protokoll wird weiterhin HTTP und als Format JSON verwendet. Damit bleibt der Vorteil von Standardtechnologien erhalten. Ein Beispiel: eine Darstellung in einer Kino App benötigt die Daten über einen Film. In einer Ansicht werden Titel, Genre und das Erscheinungsdatum benötigt. In einer anderen Darstellung hingegen werden zusätzlich eine Beschreibung sowie eine Auflistung der Darstellerinnen und Darsteller benötigt. Das Absenden beider Abfragen erfolgt grundsätzlich auf die gleiche Art, jedoch können in GraphQL jeweils die benötigten Daten mitgegeben werden. Durch die Angabe der jeweils benötigten Parameter kann die Anfrage aber exakt die Daten liefern, die im jeweiligen Fall benötigt wird, wie Listing 1 zeigt.

Listing 1:

// Example for overview
query {
movie(id: 1) {
id
title
genre
image
{ altText url }
}
}

// Example for details
query {
movie(id: 1) {
id
title
description
releaseYear
productionLocation
length
ageRating
genre

image { altText url }
}
}

GraphQL kann individuelle Abfragen durchführen. Doch wie sieht es mit der Manipulation von Daten aus? Auch das ist mit GraphQL möglich. Mutations sind in ihrer Benutzung fast identisch wie Queries und haben deswegen eigentlich die gleichen Vorteile.

Durch die Abbildung in einem Graph kann die Anfrage auch aufgeteilt werden und an andere Subsysteme verteilt werden. Diese Methode nennt sich GraphQL Federation. Das ist besonders nützlich in modernen Microservice Architekturen. Dort ist die Gefahr groß, dass sich Schemas wiederholen. Ein Beispiel: ein Client braucht Artikelstammdaten, Service A muss diese im Schema beschreiben. Service A hat die Stammdaten aber nicht selbst, sondern holt sich diese von Service B, der diese ebenfalls im Schema beschreiben muss. Über eine Schema Registry können die Schemas verwaltet und validiert werden. Das sorgt für Ordnung und Einheitlichkeit. So lassen sich die of dutzenden Services gut orchestrieren und managen. Es ist daher kein Wunder, dass sich GraphQL etabliert und REST Schnittstellen verdrängt.

REST-Services und GraphQL-Services können gut co-existieren, denn ein GraphQL-Service kann auch ohne Probleme Aufrufe an eine REST-API schicken und durchreichen. Eine GraphQL-API wird ähnlich wie ein REST Aufruf verwendet. Daher sind keine zusätzliche Bibliotheken oder Frameworks notwendig und eine bestehende Anwendung ist leicht zu migrieren, was die Hürde zur Adoption für viele Teams mit Legacy-Services deutlich senkt.