Ist GraphQL die Antwort auf alles?
Technologien kommen und gehen – auch Programmierschnittstellen bilden dabei keine Ausnahme. Mit GraphQL hat Facebook ein Architekturkonzept mit enormem Potenzial auf den Open-Source-Markt gebracht. Verdrängt der Ansatz damit SQL, REST oder etwas anderes?
42. Das ist die Antwort des Supercomputers Deep Thought in Douglas Adams‘ Science-Fiction-Klassiker "Per Anhalter durch die Galaxis" auf die endgültige Frage nach dem Leben, dem Universum und dem Rest. Adams zielte damit sicherlich nicht auf REST-APIs ab, ein Blick auf die historische Entwicklung der beliebtesten Programmierschnittstellen zeigt aber, dass sich auch die IT-Welt schnell und gerne zu endgültigen Aussagen hinreißen lässt. Dem 2017 von Facebook veröffentlichten GraphQL wurde beispielsweise schnell attestiert, es wäre die Antwort auf alles, eine Art "42" des API-Kosmos. Davor, die Älteren werden sich erinnern, galt XML-RPC lange Zeit als das Maß aller Dinge, wenn es um den Aufruf von Methoden und Funktionen bei verteilten Systemen ging. Es folgten zahllose neue Ideen und Ansätze: Von MQTT und AMQP über SSE bis zu EDI oder EDA. In der wachsenden API-Landschaft stachen dabei aber vor allem das Netzwerkprotokoll SOAP (Simple Object Access Protocol) und – als einer der großen Platzhirsche – REST deutlich heraus. Abseits der APIs etablierte sich zudem SQL als Standard für die Datenabfrage. Aus REST wurde "REST in Peace", während die Staubschicht auf dem vermeintlich umständlichen SOAP, immerhin ein industrieller Standard des World Wide Web Consortiums, mittlerweile höher als der interne Traffic eines globalen Konzerns sein könnte.
Hat Facebook mit seiner flexiblen, deklarativen Interface-Definition wirklich für die große API-Revolution gesorgt und alle Diskussionen beendet? Um die offensichtliche Antwort vorwegzunehmen: Natürlich nicht. Um zu verstehen, warum GraphQL zwar fortschrittlich und effizient ist, eine Co-Existenz mit anderen Konzepten aber dennoch die meisten Vorteile für die IT-Welt bringt, hilft ein genauerer Blick auf die Funktionen und Anwendungsfälle. Die beispielhafte Gegenüberstellung von REST und GraphQL verdeutlicht, warum sich die verschiedenen Lösungen nicht gegenseitig eliminieren.
Die Vor- und Nachteile von REST
Für REST spricht in erster Linie seine einfache Architektur und zugängliche Bedienbarkeit. Indem der Client seine Anfrage über das HTTP-Protokoll an den Server sendet, zwingt REST ihn praktisch dazu, die gängigen Methoden von HTTP zu nutzen – was einer Standardisierung gleichkommt und zu einer sehr weiten Verbreitung von REST-APIs geführt hat. Diese sind von Natur aus zustandslos und Plattform-agnostisch. Ein weiterer Vorteil: Jede Anfrage an den Server enthält ein Token, serverseitig ist daher sehr viel weniger Speicherkapazität bei der Beantwortung notwendig, weil keine Sitzungsdaten gespeichert werden.
Im Ergebnis führen diese zentralen Eigenschaften zu einer guten und stabilen Performance, die REST in Verbindung mit der Einfachheit zu weltweiter Beliebtheit verholfen hat. Daraus entstand ein weitläufiges Ökosystem mit einer Vielzahl an Tools und Frameworks, die REST de facto zu der Sprache für Data Retrieval im Internet haben aufsteigen lassen. Dabei kommt es ohne ein festes Schema aus, vielmehr ist es den Entwicklerinnen und Entwicklern überlassen, wie sie Daten strukturieren und validieren wollen. Wer seine REST-APIs dennoch strukturiert gestalten möchte, muss auf ein Third-Party-Framework wie Swagger zurückgreifen, das die fehlende Validierung und Dokumentation für REST bereitstellt.
Technisch betrachtet handelt es sich bei GraphQL um eine Mischung aus Schema und Flexibilität.
Wo so viel Licht ist, gibt es bekanntlich auch einen Schatten. Im Falle von REST besteht dieser vornehmlich aus dem Over- und Under-Fetching von Daten, weil REST-APIs die jeweiligen Endpunkte nur als Ganzes ansprechen, die wiederum nur eine bestimmte Datenstruktur vollständig zurückgeben. Reichen die erhaltenen Daten nicht aus, sind weitere Anfragen notwendig, die eine Kommunikation, zum Beispiel zwischen Front- und Backend schnell ineffizient machen. Auch kann REST nicht gezielt auf einzelne Anfragen reagieren, sondern sendet in jedem Fall alle Daten des Endpunktes im Gesamten zurück. Für komplexe Schnittstellen kann sich daraus schnell ein Problem entwickeln, das sich in einem hohen Netzwerk-Overhead ausdrückt und besonders bei mobilen und bandbreitenbeschänkten Anwendungen kritisch ist. Auch für Anwendungsfälle, die auf beinahe Echtzeit angewiesen sind, etwa Messaging, Livestreaming- oder Navigations-Dienste, eignen sich REST-APIs damit weniger. Abstriche müssen Anwender oft auch bei dem Einsatz von REST in großen und verteilten Systemen machen, weil die Performance in diesen Fällen den Ansprüchen einer möglichst geringen Latenz und schnellen Kommunikation nicht genügt.
Was macht GraphQL anders?
Es könnten genau diese Limitierungen gewesen sein, die Facebook zur Entwicklung von GraphQL bewegt hat – zu komplexe Queries, zu großer Overload, zu wenig Effizienz. Stößt die Software bei großen, komplizierten Datenstrukturen an ihr Limit, sind neue Lösungen gefragt. Nicht zuletzt müssen Unternehmen Wert auf fundamentale Technologien legen, die schlanke, einfache Wege zur Lösung eines Problems bieten. Im Falle von Facebook bedeutet das einen neuen Ansatz für den API-Bereich. Der Clou dabei: Obwohl GraphQL auf dem Papier als eine Middleware zwischen Client und Server fungiert und damit für zusätzliche Komplexität sorgt, kann der Client mit nur einer einzigen Abfrage alle benötigten Daten erhalten. Dabei empfängt er nicht die Informationen des gesamten Endpunktes, sondern kann dank seines flexiblen Interfaces jederzeit Keys hinzufügen oder löschen. Auf diese Weise kann der Client genau die Daten anfragen, die er benötigt – auch wenn die sich über verschiedene Endpunkte verteilen. GraphQL sammelt die Anfragen, bündelt sie und liefert ausschließlich die angefragten Informationen zurück. Damit können API-Aufrufe drastisch reduziert werden, was sich wiederum positiv auf die Performance und die Netzwerkgeschwindigkeit auswirkt. Kein Wunder also, das GraphQL besonders für mobile Apps attraktiv ist, die durch Bandbreite und Rechenkapazität eingeschränkt sind.
Technisch betrachtet handelt es sich bei GraphQL um eine Mischung aus Schema und Flexibilität. Das zu Grunde liegende Schema einer Anfrage besiegelt dabei eine Art Vertrag zwischen Client und Server, der bestimmt, was eine GraphQL-API darf und was nicht. Weil weder Schema noch Interface ein starres Konstrukt sind, haben Anwender große Flexibilität bei der Erstellung ihrer Queries. Allerdings: Die Einführung von GraphQL kann komplexer sein als bei einer einfachen REST-API. Auch das Erstellen und Pflegen eines gut durchdachten Schemas ist aufwendiger und erfordert ein höheres Maß an Planung, insbesondere bei großen, komplexen Systemen. Bei kleineren Projekten und Anwendungsfällen kann GraphQL hingegen schnell eine überdimensionierte Lösung sein – eine Abwägung von Aufwand und Nutzen ist daher immer geboten. Abschrecken lassen sollte sich von den etwas höheren Entwicklungsanforderungen allerdings niemand – GraphQL ist keine Raketenwissenschaft und stellt sich insbesondere für API-erfahrene Entwicklerinnen und Entwickler eher als ein neues Lernprojekt dar.
Wertvoll, aber nicht die Antwort auf alles
Wird das Aufkommen von neuen Lösungen den Einsatz der alten API-Hasen nun obsolet machen? Kurzfristig sicherlich nicht, langfristig werden sich, wie immer, die effizientesten fundamentalen Technologien am weitesten verbreiten. Weil aber REST, GraphQL, SOAP, RPC und alle anderen Ansätze ihre eigenen Vor- und Nachteile sowie sinnvolle Anwendungsfälle haben, ist eine Co-Existenz kein Widerspruch, sondern ein Vorteil. Wer beispielsweise SOAP bereits zum alten Eisen gelegt hat, übersieht, dass das Netzwerkprotokoll auch heute noch vorteilhaft ist, wenn hohe Sicherheitsanforderungen, umfassende Spezifikationen und Transaktionssicherheit benötigt werden. Kein Wunder also, dass beispielsweise das deutsche Finanzministerium auf SOAP zurückgreift. Während GraphQL besonders im Mobile-Bereich großen Mehrwert bringt, werden Firmen für den internen Datenaustausch auch weiterhin auf SQL und Co. setzen, um direkt mit der Datenbank zu kommunizieren – allein aus den Gründen der großen Verbreitung und einfachen Handhabung. So wird SQL mit seinem riesigen Ökosystem und zahlreichen Akzenten, etwa SQL++, auch zukünftig der Standard für Data Access bleiben.
Auch REST ist gekommen, um zu bleiben. Für Anwendungsfälle mit komplexen Datenstrukturen, mobilen Apps oder Anwendungen, die auf Echtzeit angewiesen sind, steht mit GraphQL allerdings eine weitere Lösung zur Verfügung. Nicht als zwangsläufiger Ersatz, aber als ein weiteres Werkzeug in einem immer besser bestückten Sortiment an spezialisierten Ansätzen für Programmierschnittstellen. Der so oft proklamierte Untergang älterer API-Konzepte hat daher wenig mit der Realität zu tun. Ähnlich wie bei Douglas Adams sollten wir daher die vorangehende Fragestellung überdenken. Diese müsste nicht lauten, was die eine Lösung für alles ist, sondern wie und wann uns RPC, SOAP, REST, GraphQL, SQL und alle anderen als beste Option dienen.
