Startseite
Themen
GraphQL
Veröffentlicht: 8. Dezember 2023
Mitwirkende: Chrystal R. China, Michael Goodwin
GraphQL ist eine Open-Source-Abfragesprache und serverseitige Laufzeit, die angibt, wie Clients mit Programmierschnittstellen (APIs) interagieren sollen.
Mit einer intuitiven Syntax, die es Benutzern ermöglicht, API-Anfragen in einer oder wenigen Zeilen zu stellen (anstatt auf komplexe Endpunkte mit vielen Parametern zuzugreifen), erleichtern GraphQL-Technologien die Erstellung und Beantwortung von API-Anfragen. GraphQL stellt ein Upgrade von traditionellen RESTful-Architekturen dar.
In den frühen 2010er Jahren erlebte Facebook ein enormes Wachstum und einen enormen Wandel. Aber eine wachsende Nutzerbasis und eine zunehmend komplexe mobile App-Umgebung machten den bestehenden RESTful-Ansatz, der mehrere Roundtrips zu verschiedenen Endpunkten erforderte, um alle erforderlichen Abfragedaten abzurufen, unhaltbar.
Representational State Transfer (REST) und RESTful APIs waren für den Umgang mit komplexen, datengesteuerten Benutzeroberflächen schlecht gerüstet und es kam häufig zu Latenzproblemen und Datenineffizienzen, insbesondere bei mobilen Benutzern mit begrenzten oder teuren Datentarifen.
Als Antwort auf diese Herausforderungen entwickelten Facebook-Ingenieure GraphQL (zusammen mit der Single-Page-Application-Plattform React) und veröffentlichten es 2015 als Open-Source-Lösung. Letztendlich übertrug Facebook den Dienst im Jahr 2018 auf die GraphQL Foundation, zu der Mitgliedsunternehmen wie AWS, Gatsby, Intuit und IBM gehören.
Erfahren Sie, wie Sie mit APM und ARM schneller Entscheidungen treffen und Ressourcen einsetzen.
Die deklarativen Datenabruffunktionen einer GraphQL-Architektur drehen sich um mehrere Schlüsselkomponenten und -prozesse, die jeweils eine einzigartige Rolle bei der Datenverarbeitung spielen.
Dazu gehören:
GraphQL basiert auf einem starken Typsystem, bei dem alle Datentypen in der GraphQL-Schemadefinitionssprache (SDL) aufgezeichnet werden. Typisierte Schemata bestimmen die Datentypen, die in der API abgefragt werden können, sowie die Beziehungen zwischen den Typen und den Vorgängen, die dem Benutzer zur Verfügung stehen. Mit anderen Worten, sie definieren die Funktionen der API und die Form der Daten, mit denen Clients interagieren können.
Jedes Feld in einem Schema wird durch einen Resolver unterstützt, der Daten einfüllt und die Antwort auf eine Reihe von Feldern bestimmt. Resolver – die Daten aus einer Datenbank, einem Cloud-Service oder praktisch jeder anderen Quelle abrufen können – stellen Anweisungen zum Umwandeln einer GraphQL-Operation (z. B. einer Abfrage, Mutation oder eines Abonnements) in Daten bereit.
Wenn ein Abfragefeld gestartet wird, generiert das System einen Aufruf an den entsprechenden Resolver, um den nächsten Wert zu erzeugen. Wenn ein Feld einen Skalarwert erzeugt (z. B. eine Zeichenfolge oder Zahl), wird die Ausführung abgeschlossen. Wenn ein Feld einen Objektwert erzeugt, enthält die Abfrage weitere Felder für dieses Objekt. Dieser Vorgang wird fortgesetzt, bis nur noch Skalarfelder übrig sind.
Resolver erleichtern außerdem die Datenformatierung und helfen dem System, Informationen aus verschiedenen Datenquellen zusammenzuführen.
Eine Datenabfrage ist die Anfrage, die der Client an den GraphQL-Server stellt; sie gibt an, welche Daten der Client abrufen möchte. Wenn eine Abfrage eingeht, validiert GraphQL sie anhand der Schemadefinitionen und führt sie aus –vorausgesetzt, sie ist gültig. Die Struktur einer Abfrage spiegelt in der Regel die Struktur der Antwortdaten wider, was Datenanforderungen explizit und vorhersehbar macht.
Mutationen sind GraphQL-Vorgänge, die Daten auf dem Server erstellen, aktualisieren oder löschen. Sie sind analog zu den POST-, PUT-, PATCH- und DELETE-Vorgängen in RESTful-APIs.
Ähnlich wie bei Abfragen werden GraphQL-Mutationen anhand des Schemas und seiner Definitionen validiert. Sobald die Mutation validiert und gestartet wurde, gibt der Server eine JSON-Antwort zurück.
Obwohl GraphQL-APIs inzwischen eine effizientere und flexiblere Alternative sind, waren REST und RESTful lange der Standard für API-Architekturen. REST-API ist ein strukturierter Architekturstil für vernetzte Hypermedia-Anwendungen, der entwickelt wurde, um ein zwischenspeicherndes, zustandsloses Client/Server-Kommunikationsprotokoll (normalerweise HTTP) zu verwenden.
Sowohl GraphQL als auch REST ermöglichen es Clients, mit Servern zu kommunizieren und Daten anzufordern, aber es gibt wesentliche Unterschiede, die die Verbreitung von GraphQL-Systemen erklären.
REST-APIs sind auf Ressourcen ausgerichtet (z. B. jede Art von Objekt, Daten oder Dienst, auf den der Client zugreifen kann) und funktionieren, indem sie für jede Ressource unterschiedliche Endpunkte (URLs) haben. Sie verwenden eine feste Datenstruktur, um die Form und Größe der Ressourcen zu bestimmen, die sie ihren Kunden bereitstellen.
Wenn der Client eine Ressource anfordert, sendet der Server alle mit dieser Ressource verknüpften Daten. Auch wenn ein Client nur eine Teilmenge der Daten benötigt, empfängt er trotzdem alle Daten (Overfetching); wenn er hingegen Daten benötigt, die mehrere Ressourcen umfassen, muss er oft mehrere API-Aufrufe tätigen, da die Daten der ursprünglichen Anfrage nicht ausreichen (Unterabruf).
GraphQL verwendet dagegen einen einzelnen Endpunkt, der eine vollständige und verständliche Beschreibung der Daten bereitstellt. GraphQL-Abfragen können auf Ressourceneigenschaften zugreifen und Referenzen zwischen Ressourcen folgen, sodass der Client alle benötigten Daten mit einer einzigen Anfrage an den GraphQL-Server abrufen und Probleme mit übermäßigem und zu geringem Abruf vermeiden kann.
In einer REST-Architektur müssen Teams bei einer Änderung der Datenstruktur oft die API versionieren, um Systemfehler und Serviceunterbrechungen für den Nutzer zu vermeiden.
Das bedeutet, dass Entwickler jedes Mal, wenn sie die Struktur ändern, einen neuen Endpunkt erstellen müssen, was zu mehreren API-Versionen führt und den Wartungsprozess erschwert.
GraphQL macht Versionierung überflüssig, da Clients ihre Anforderungen in der Abfrage angeben können. Wenn dem Server neue Felder hinzugefügt werden, sind Clients, die diese Felder nicht benötigen, davon nicht betroffen. Wenn Felder dagegen veraltet sind, können Clients sie weiterhin anfordern, bis sie ihre Abfragen aktualisieren.
REST-APIs verwenden HTTP-Statuscodes, um den Status/Erfolg einer Anfrage anzuzeigen. Jeder Statuscode hat eine bestimmte Bedeutung.
Bei einer erfolgreichen Anfrage wird der Statuscode 200 zurückgegeben, während ein Client-Fehler den Statuscode 400 und ein Server-Fehler den Statuscode 500 erzeugen kann.
GraphQL behandelt Fehler unterschiedlich. Jede Anfrage gibt unabhängig davon, ob sie zu einem Fehler geführt hat, den Statuscode 200 OK zurück. Die Fehler werden nicht über HTTP-Statuscodes kommuniziert; stattdessen kommuniziert das System Fehler im Antworttext zusammen mit den Daten.
Bei diesem Ansatz müssen Clients den Antworttext analysieren, um festzustellen, ob die Anfrage erfolgreich war. Das kann das Debuggen von GraphQL-APIs erschweren.
REST bietet keine integrierte Unterstützung für Echtzeit-Updates. Wenn eine Web- oder Mobilanwendung Echtzeitfunktionen mit einer REST-API benötigt, müssen Entwickler in der Regel Techniken wie Long-Polling (bei dem der Client den Server wiederholt nach neuen Daten abfragt), vom Server gesendete Ereignisse und WebSockets implementieren, was die Anwendung komplexer machen kann.
GraphQL bietet dagegen integrierte Unterstützung für Echtzeit-Updates durch den Einsatz von Abonnements. Abonnements halten eine stabile Verbindung zum Server aufrecht, sodass der Server bei bestimmten Ereignissen Aktualisierungen an den Client weiterleiten kann und Clients den Überblick über relevante API-Daten behalten.
Das REST-Ökosystem ist gut etabliert und bietet Entwicklern eine breite Palette an Tools, Bibliotheken und Frameworks. Bei der Arbeit mit REST-APIs müssen Teams jedoch häufig durch mehrere Endpunkte navigieren und die einzigartigen Konventionen/Muster jeder API kennen.
GraphQL ist relativ neu, aber das GraphQL-Ökosystem ist seit seiner Einführung enorm gewachsen und bietet eine Vielzahl von Tools und Bibliotheken für die Entwicklung von Frontend- und Backend-Diensten.
Tools wie GraphiQL, Apollo Studio und GraphQL Playground verfügen über leistungsstarke, im Browser integrierte Entwicklungsumgebungen (IDEs) zum Erkunden und Testen von GraphQL-APIs. Darüber hinaus bietet GraphQL eine starke Unterstützung für die Codegenerierung, was die clientseitige Entwicklung vereinfachen kann.
REST-APIs basieren auf HTTP-Caching-Mechanismen wie ETags und zuletzt geänderten Headern. Caching-Strategien sind zwar effektiv, aber eventuell umständlich zu implementieren und optimieren die Leistung nicht immer für alle Anwendungsfälle.
Das Zwischenspeichern von GraphQL-APIs kann aufgrund der dynamischen Natur der Abfragen schwieriger sein. Der Einsatz von persistierten Abfragen, Response Caching und Server-seitigem Caching kann diese Herausforderungen jedoch entschärfen und effiziente Caching-Strategien für GraphQL-Architekturen bieten.
Seit der Übernahme von GraphQL in die GraphQL Foundation haben Entwickler unter anderem Implementierungen für verschiedene Programmiersprachen wie JavaScript, Python, Ruby und PHP erstellt. Und GraphQL-APIs wurden von zahlreichen Unternehmen wie Github, Pinterest, PayPal, Shopify, Airbnb und anderen übernommen, was es immer mehr Kunden ermöglicht, Datenspezifikationen zu vereinfachen, übermäßige oder unzureichende Netzwerkdatenübertragungen zu reduzieren und die allgemeinen Datenabrufmöglichkeiten zu verbessern.1
Darüber hinaus drängen Unternehmen und Entwickler auf einen offenen Verbund von GraphQL-Architekturen. In seiner aktuellen Iteration nimmt der GraphQL-Verbund separate GraphQL-Dienste auf und fasst sie in einer einzigen GraphQL-API zusammen, die als Einstiegspunkt für alle zugrunde liegenden Backend-Daten dient und den Datenabruf durch eine einzige Anfrage erleichtert. Leider ist die Verbundimplementierung jedoch ausschließlich einem einzelnen Anbieter vorbehalten.
Als Reaktion darauf plädiert IBM für eine demokratisierte Föderation, die die Datenaggregation sowohl von GraphQL-APIs als auch von Nicht-GraphQL-APIs anstelle einer GraphQL-exklusiven Aggregation erleichtert.2
IBM API Connect ist eine Lösung für das Management des gesamten Lebenszyklus von APIs, die über eine intuitive Benutzeroberfläche die konsistente Erstellung, Verwaltung, Sicherung, Vernetzung und Monetarisierung von APIs ermöglicht und so die digitale Transformation lokal und in der Cloud unterstützt.
Mit IBM API Connect können Sie in wenigen Minuten eine GraphQL-API auf Produktionsebene erstellen und bereitstellen. Geben Sie einfach die Verbindungsdetails Ihrer Datenquelle an und schon wird eine sichere und optimierte GraphQL-API generiert.
Eine REST-API ist eine Programmierschnittstelle, die den Designprinzipien des REST-Architekturstils (Representational State Transfer) entspricht.
Erfahren Sie mehr über die beiden unterschiedlichen Ansätze dieser Frameworks für die Erstellung von APIs und die Stärken und Schwächen der beiden.
Lesen Sie den Gartner Magic Quadrant 2023 für API Management, um herauszufinden, warum IBM weiterhin als Marktführer im Bereich API Management gilt.
IBM API Connect-Toolkit ansehen.
IBM wurde im Gartner-Bericht 2023 als führendes Unternehmen ausgezeichnet: Critical Capabilities for API Management.
Diese Tutorials bieten praktische Anleitungen, mit denen Entwickler den Einsatz der Technologien in ihren Projekten erlernen können.
Fußnoten
1 IBM acquires GraphQL startup StepZen to step up its game in API Management (IBM erwirbt das GraphQL-Startup StepZen, um sich im Bereich API Management zu verbessern) (Link befindet sich außerhalb von ibm.com), TechCrunch, 8. Februar 2023
2 Why GraphQL Needs an Open Federation Approach (Warum GraphQL den Ansatz eines offenen Verbunds benötigt) (Link außerhalb von ibm.com), The New Stack, 16. November 2023