Die Rolle und Auswirkungen von GraphQL

GraphQL hat sich als moderner und effizienter Ansatz für die API-Entwicklung herausgestellt und überwindet die Einschränkungen herkömmlicher REST-APIs. Während REST bereits seit den Anfängen des Webs weit verbreitet ist, bietet GraphQL Entwicklern eine neue Perspektive und mehr Kontrolle. Mit GraphQL können Entwickler ein stark typisiertes Schema definieren, das es Clients ermöglicht, genau die Daten anzufordern, die sie benötigen. Durch die Vermeidung von Über- und Unterabrufen von Daten optimiert GraphQL die Leistung und erleichtert die Erstellung moderner, interaktiver Webanwendungen mit komplexen Anforderungen an Datenabfragen und Datenmodellierung.

Wir sind uns jedoch darüber im Klaren, dass GraphQL nicht ohne Herausforderungen ist. Dieses Dokument bietet Einblicke in die Sicherheitsbedenken und die Lernkurve, die mit der Einführung von GraphQL verbunden sind. Wir untersuchen Fallstudien aus der Praxis und beschreiben die Vorteile namhafter Unternehmen, die GraphQL erfolgreich implementiert haben.

Darüber hinaus präsentieren wir unsere eigene Untersuchung zu GraphQL und teilen unsere Erfahrungen und Erkenntnisse. Wir geben eine kurze Einführung in GraphQL, vergleichen es mit REST und gehen auf die Herausforderungen ein, die es bewältigt. Darüber hinaus werden Sicherheitsaspekte erörtert, um Organisationen dabei zu unterstützen, fundierte Entscheidungen zu treffen. Unsere Forschung zeigt das transformative Potenzial von GraphQL. Wir zeigen, wie wir die Softwarearchitektur einer Testmanagement-Suite vereinfacht haben, was zu einem Anstieg der Menge der durch GraphQL in JSON-Objekten verborgenen Daten um über 300 % geführt hat.

Zusammenfassend empfehlen wir Unternehmen, die mit der Skalierung, Optimierung oder dem Betrieb einer REST-API-Infrastruktur zu kämpfen haben, dringend, GraphQL als praktikable Lösung in Betracht zu ziehen. Unsere Erkenntnisse bieten praktische Anleitungen für alle, die sich auf die GraphQL-Reise begeben, und ermöglichen es ihnen, die Vorteile zu nutzen und Herausforderungen effektiv zu meistern.

Einschränkungen bei REST-APIs führen zu einer steigenden Nachfrage nach einem neuen API-Technologieansatz.

Der auf REST (Representational State Transfer) basierende Ansatz wurde ursprünglich als Satz von Architekturprinzipien für den Entwurf von Web-APIs vorgeschlagen. REST entwickelte sich im Laufe der 2000er und 2010er Jahre mit der Entstehung von Web 2.0 zu einem besseren Mittel zur Implementierung einer serviceorientierten Architektur (SOA) im Vergleich zu anderen Technologien wie der Common Object Request Broker Architecture (CORBA).

Mit der zunehmenden Nutzung mobiler Endgeräte stieg auch die Nachfrage nach präzisen Daten. Allerdings führten REST-basierte APIs häufig dazu, dass zu viele oder zu wenige Daten abgerufen wurden, was zu Ineffizienzen führte. Dieser Ansatz, beispielsweise bei Apps wie Facebook, erforderte oft zahlreiche REST-API-Aufrufe für ein einzelnes Update, was den Netzwerkverkehr erhöhte und die Leistung und das Benutzererlebnis beeinträchtigte.

GraphQL wurde speziell entwickelt, um diese Einschränkungen zu beheben, indem es ein stark typisiertes Schema und eine effizientere Möglichkeit zum Abfragen von Daten bietet. Dadurch eignet es sich gut für Anwendungsfälle, in denen bestimmte Daten zur Optimierung der Netzwerkbandbreite erforderlich sind. Darüber hinaus ermöglicht die Fähigkeit von GraphQL zur Schemaanalyse eine bessere Dokumentation und bessere Tools. Zwar hätte eine standardisiertere REST-Implementierung für etwas Konkurrenz sorgen können, doch die einzigartigen Funktionen und Vorteile von GraphQL machen es zu einer überzeugenden Wahl für moderne Anwendungsarchitekturen, die verteilt und datenintensiv sind.

Abbildung 1 zeigt einen topologischen Unterschied zwischen der Implementierung von REST und GraphQL. Wie in REST API vs. GraphQL dargelegt, „besteht der Hauptunterschied zwischen GraphQL und REST APIs darin, dass GraphQL eine Abfragesprache ist, während REST ein Architekturkonzept für netzwerkbasierte Software ist.“ 

Meta hat GraphQL im Jahr 2012 ( Open Source 2015) entwickelt, um die Leistung und Flexibilität seiner mobilen Apps zu verbessern. Vor GraphQL wurden die mobilen Apps von Meta mit einer Kombination aus RESTful-APIs und nativem Code erstellt, was die Handhabung der großen Bandbreite an Geräten, Bildschirmgrößen und Netzwerkbedingungen, die die Apps unterstützen mussten, erschwerte. 

Eine der größten Herausforderungen bestand darin, dass RESTful-APIs oft die falsche Datenmenge zurückgaben – manchmal zu viele und manchmal zu wenige. Wenn die API große Datenmengen zurückgab, die die mobilen Apps nicht benötigten, kam es zu langen Ladezeiten und schlechter Leistung. Wenn die API zu wenige Daten zurückgab, mussten mobile Apps mehrere Anfragen an verschiedene Endpunkte stellen, um alle benötigten Daten abzurufen, was zu zusätzlicher Latenz und Komplexität des Prozesses führte.

Meta hat GraphQL entwickelt, sodass jede App in einer einzigen Anfrage nur die Daten anfordern kann, die sie benötigt. Dadurch konnte der Datentransfer zwischen den mobilen Apps und den Backend-Diensten optimiert werden, was zu schnelleren Ladezeiten und besserer Leistung führte. Darüber hinaus erleichterten die starken Typisierungs- und Selbstdokumentationsfunktionen von GraphQL Entwicklern das Verständnis und die Nutzung der API. 

GraphQL bietet leistungsstarke Funktionen zum Abrufen und Bearbeiten von Daten und bietet im Vergleich zu herkömmlichen API-Ansätzen erhebliche Vorteile. 

GraphQL verfügt über ein stark typisiertes Schema, das Klarheit und Genauigkeit bei der Definition der Struktur und Datentypen gewährleistet, die von einer API abgefragt werden können. Nehmen wir an, wir haben eine API für eine Bibliothek, die Bücher, Autoren und Verlage enthält. 

a) GraphQL-Schema : In GraphQL würde ein stark typisiertes Schema wie in Abbildung 2 unten aussehen: 

Stark typisierte Schemata in GraphQL bieten sicherheitsrelevante Vorteile, indem sie die Eingabevalidierung ermöglichen, ein Über- oder Unterholen von Daten verhindern, eine klare Dokumentations- und Tool-Unterstützung bieten, die Versionskontrolle erleichtern und bei der Autorisierung und Zugriffskontrolle helfen. Diese Funktionen verbessern die API-Sicherheit, indem sie das Risiko gängiger Sicherheitslücken verringern und eine ordnungsgemäße Datenverarbeitung und Zugriffsverwaltung gewährleisten.

Im gezeigten Beispiel (Abbildung 2) definiert das Schema die Datentypen für Bücher, Autoren und Verlage und deren Beziehungen zueinander. Das Schema ist stark typisiert , was bedeutet, dass jedes Feld einen bestimmten Datentyp hat und Clients das Schema leicht untersuchen können, um verfügbare Felder und ihre Typen zu ermitteln.

b) REST-Schema : In REST wäre die Schemadefinition lose typisiert, wie in Abbildung 3 unten dargestellt: 

Diese Endpunkte geben JSON-Objekte zurück, die die Bücher, Autoren und Herausgeber darstellen, aber das Schema selbst ist nicht explizit definiert und bleibt dem Können und der Interpretation des Programmierers überlassen. Kunden müssen sich auf die Dokumentation verlassen, um die Struktur der Daten zu verstehen.

GraphQL hat sich zu mehr als einer besseren Alternative zu REST entwickelt und hat das Potenzial, für Unternehmen, die eine bessere Datenstrategie in Betracht ziehen, zum bevorzugten Ansatz zu werden. Neben der Lösung der Einschränkungen von REST gibt es mehrere weitere Gründe, warum sich GraphQL zu einem neuen Ansatz für das API-Design entwickelt hat. Während die Tabelle (Abbildung 4) die Vorteile von GraphQL gegenüber REST aufzeigen kann, betrachtet man GraphQL am besten als eine Reaktion auf die Entwicklung des Internets und verschiedener Anwendungen und nicht als eine Reaktion auf die Identifizierung von Problemen mit REST selbst.

GraphQL bietet gegenüber herkömmlichen RESTful-APIs zwar viele Vorteile, seine Verwendung bringt jedoch auch einige Herausforderungen mit sich. Zu den üblichen Herausforderungen gehören:

1. Lernkurve: Da die meisten Entwickler eher mit REST vertraut sind, müssen Unternehmen, die GraphQL einführen möchten, Zeit einplanen, damit ihre Teams den effektiven Einsatz erlernen können. GraphQL erfordert eine andere Denkweise hinsichtlich der Erstellung und Nutzung von APIs und seine Einführung könnte Änderungen an der zugrunde liegenden Anwendungsarchitektur erfordern. Entwickler müssen möglicherweise neue Konzepte wie Schemata, Resolver und Typen sowie neue Tools und Bibliotheken erlernen. Mit GraphQL haben Clients mehr Kontrolle über die Daten, auf die sie zugreifen können, was die Sicherung von APIs erschweren kann. Techniken wie Eingabevalidierung, Authentifizierung und Autorisierung müssen möglicherweise anders angewendet werden als bei RESTful-APIs.
2. Zwischenspeicherung : Das Caching kann mit GraphQL komplexer sein, da Clients mit jeder Abfrage unterschiedliche Daten anfordern können, was das Zwischenspeichern und Wiederverwenden von Antworten erschwert.
3. Leistung : Während GraphQL es Clients ermöglicht, nur die Daten anzufordern, die sie benötigen, sind damit auch komplexere und ressourcenintensivere Abfragen möglich. Bei GraphQL-APIs können Leistungsprobleme auftreten, insbesondere beim Abfragen großer Datensätze oder bei einer großen Anzahl gleichzeitiger Anfragen. Entwickler müssen Strategien implementieren, beispielsweise die Abfragetiefe zu begrenzen oder sicherzustellen, dass Clients nur auf die benötigten spezifischen Daten zugreifen dürfen.
4. Fehlerbehandlung : GraphQL kann die Fehlerbehandlung komplexer machen, da Fehler möglicherweise als Teil der Antwort und nicht als separater HTTP-Statuscode zurückgegeben werden.
5. Testen : Das Testen mit GraphQL ist aufgrund der Komplexität der Abfragen, des Fehlens standardisierter Testansätze, der Schemaentwicklung und der Abfragevalidierung während der Laufzeit eine Herausforderung. Entwickler müssen Zeit investieren, um geeignete Test-Frameworks und -Tools zu finden, um diese Herausforderungen zu bewältigen. Entwickler müssen eine umfassende Testabdeckung sicherstellen, indem sie geeignete Tools auswählen und die Schemaentwicklung berücksichtigen, um GraphQL-APIs effektiv zu testen und ihre Funktionalität und Stabilität sicherzustellen.
6. Überwachung : Die Überwachung von GraphQL-APIs kann aufgrund der Komplexität der Abfragen, des Fehlens standardisierter Protokollierung und Metriken sowie potenzieller Leistungsprobleme eine Herausforderung darstellen. Aufgrund der dynamischen Natur von GraphQL-Abfragen ist es schwieriger, die Struktur und Größe der angeforderten Daten vorherzusagen und zu überwachen. Das Fehlen standardisierter Überwachungstools speziell für GraphQL-APIs erschwert den Einblick in die GraphQL-Abfrageleistung, Fehlerverfolgung und API-Integrität. Entwickler müssen spezielle Überwachungstools und -praktiken übernehmen, die mit den einzigartigen Eigenschaften von GraphQL umgehen können und so eine effiziente Leistung und einen zuverlässigen Betrieb gewährleisten. 

GraphQL ist ein leistungsstarkes Tool, das in zahlreichen Anwendungen eingesetzt werden kann, vom Erstellen von APIs bis hin zur Bereitstellung mobiler Apps. Aufgrund seiner Flexibilität und der Möglichkeit, Datenquellen zu vereinheitlichen, eignet es sich gut für eine Vielzahl unterschiedlicher Nutzungsmuster.

1. Erstellen effizienter APIs : Eine der Hauptanwendungen von GraphQL besteht darin, APIs zu erstellen, die von Web- und mobilen Anwendungen genutzt werden können. GraphQL bietet eine flexible und leistungsstarke Möglichkeit zum Definieren und Zugreifen auf Daten und eignet sich daher gut für die Erstellung von APIs, die eine breite Palette von Clients und Anwendungsfällen unterstützen müssen.
2. Datenabruf und -manipulation : Mit GraphQL können Daten aus einer Vielzahl von Quellen abgerufen und bearbeitet werden, darunter Datenbanken, Cloud-Dienste und andere APIs. Indem GraphQL einen einheitlichen Datenzugriff ermöglicht, kann es dazu beitragen, den Prozess der Erstellung und Wartung datengesteuerter Anwendungen zu vereinfachen.
3. Anwendungsfälle in Echtzeit : GraphQL eignet sich gut für Echtzeitanwendungsfälle, da Clients Aktualisierungen bestimmter Daten abonnieren und Benachrichtigungen erhalten können, wenn sich die Daten ändern. Dies kann in Anwendungen wie Chat, Live-Streaming, Echtzeit-Dashboards und mehr verwendet werden.
4. Mikroservices : Mit GraphQL lässt sich eine flexible, lose gekoppelte Architektur aufbauen, die es verschiedenen Microservices ermöglicht, auf konsistente und klar definierte Weise miteinander zu kommunizieren.
5. Vom Backend zum Frontend : Mit GraphQL lässt sich eine Back-End-for-Front-End-Architektur (BFF) aufbauen, die verschiedenen Front-End-Clients einen konsistenten und effizienten Zugriff auf Daten und Dienste ermöglicht.
6. Mobile Entwicklung : GraphQL kann zum Betrieb mobiler Apps verwendet werden, indem es eine Möglichkeit bietet, unabhängig von Plattform oder Gerät konsistent und effizient auf Daten und Dienste zuzugreifen. 

Es gibt offensichtliche Gründe, warum wir GraphQL benötigen, wie die folgenden Brancheneinsätze zeigen:

Netflix fasste seine GraphQL-Reise im Jahr 2020 in einer zweiteiligen Blogserie zusammen , die für jeden GraphQL-Praktiker eine Pflichtlektüre ist. Die von ihnen vorgestellte Fallstudie war das Studio Edge-System, bei dem die Studio-APIs übernommen und für GraphQL neu strukturiert wurden. Die Studio-API von Netflix wird von den Content-Teams verwendet, um die Produktion, Postproduktion und den Vertrieb von Fernsehsendungen und Filmen zu verwalten und zu überwachen. Die API bietet Zugriff auf eine riesige Menge an Daten, darunter Metadaten zu Titeln, Talentinformationen und mehr.

Ursprünglich wurde die Studio-API mithilfe einer herkömmlichen RESTful-Architektur mit Endpunkten erstellt, die Daten im JSON-Format zurückgaben. Mit dem Wachstum der API und der steigenden Zahl der darauf zugreifenden Clients wurde jedoch klar, dass eine effizientere Lösung erforderlich war.

Netflix begann, GraphQL als mögliche Lösung für die Studio-API zu untersuchen. Das Unternehmen begann mit dem Aufbau eines kuratierten Graphen für die Studio-API. Dabei wurden mehrere wichtige Vorteile identifiziert, darunter die Möglichkeit, die Netzwerknutzung zu reduzieren, den Datenzugriff zu vereinfachen und die Leistung zu verbessern, indem Clients nur die Daten anfordern können, die sie benötigen.

Bei der Einführung von GraphQL für die Studio-API stand Netflix außerdem vor besonderen Herausforderungen. Insbesondere ging es darum, die Komplexität des Schemas zu bewältigen und sicherzustellen, dass Clients nur auf die Daten zugreifen können, für die sie eine Anzeigeberechtigung haben.

Um diese Herausforderungen zu bewältigen, hat Netflix eine benutzerdefinierte Lösung namens „Netflix GraphQL Federation“ entwickelt, die die Apollo Federation-Spezifikation verwendet, um das Studio-API-Schema in kleinere, besser handhabbare Teile aufzuteilen. Sie haben außerdem ein System zur Verwaltung von Berechtigungen und Zugriffskontrollen implementiert, mit dem sie den Clientzugriff auf bestimmte Teile des Schemas einschränken können.

Im Blog veröffentlichten sie auch die Entwicklung ihrer API-Architektur vom Monolithen zum Federated Gateway. Abbildung 5 ist eine Adaption des Bildes aus ihrem Blog.

Unserer Ansicht nach fehlt ein weiterer Ansatz, der in der Branche zwar weit verbreitet, aber nicht formalisiert ist.

Man könnte die Gateway-Aggregatschicht und das föderierte Gateway aus Abbildung 5 wie unten dargestellt kombinieren:

Jedes Zahnradsymbol stellt im Wesentlichen eine flüchtige und föderierte GraphQL-Instanz (auch Gateway-Akteur genannt) dar, die in Echtzeit (sogar auf Transaktionsbasis) am Rand, d. h. topologisch in der Nähe der Clients, instanziiert werden kann und über einen sicheren API-Transport eine Verbindung zu den Mikrodiensten herstellt. Diese Kombination ersetzt im Wesentlichen die Gateway-Aggregationsschicht oder die föderierte Schicht durch verteilte Gateway-Akteure, die das Beste aus beiden Funktionalitäten kombinieren. Wir nennen dies die verteilte GraphQL-Gateway-Akteursarchitektur, wie in Abbildung 7 dargestellt.

PayPal ist auf der GraphQL-Reise seit2018 als sie es zu einem Teil ihrer Checkout-App machten. Ihr Hauptanliegen bei REST war, ähnlich wie bei Meta, dass die Designprinzipien nicht für Web- und mobile Apps und deren Benutzer optimiert sind. Client-Anwendungen führten zahlreiche Hin- und Rückreisen vom Client zum Server durch und benötigten zum Abrufen der Daten etwa 700 ms. Dies führte zu längeren Renderzeiten, Frustration bei den Benutzern und niedrigeren Konvertierungsraten. Bei der Checkout-App stellte PayPal fest, dass die Entwickler von Benutzeroberflächen (UI) weniger als ein Drittel ihrer Zeit mit der Erstellung der UI verbrachten, während sie die restliche Zeit damit verbrachten, herauszufinden, wie Daten abgerufen und verarbeitet werden.

Die anderen Technologien, die das PayPal-Entwicklungsteam in Betracht zog, waren Orchestrierungs-APIs und Bulk-REST. Das Erstellen einer Orchestrierungs-API würde zu einem übermäßigen Abrufen und einer Kopplung der Clients an den Server führen. PayPal kam zu dem Schluss, dass dieser Ansatz mit der Zeit dazu führen kann, dass die API schwerfällig und unhandlich wird und mehr als nur einem Zweck dient. Auch ihr Bulk-REST-Experiment war erfolglos. Dadurch musste das Engineering-Team zwar nicht mehr die Orchestrierungs-APIs optimieren, die Kunden mussten sich jedoch genau mit der Funktionsweise der APIs auskennen.

PayPals erste Erfahrung mit der Verwendung von GraphQL zum Erstellen eines neuen Produkts war ein mobiles SDK zur Integration von PayPal Checkout in Apps. Innerhalb einer Woche der Evaluierung von GraphQL entschied das Entwicklungsteam, es für sein neues Produkt zu verwenden. Obwohl die API noch nicht fertig war, konnten sie das Produkt vorzeitig fertigstellen, wobei praktisch keine PayPal-spezifischen Kenntnisse erforderlich waren. Den Entwicklern gelang es, schnell eine effiziente und benutzerfreundliche App zu erstellen und das Engineering-Team davon zu überzeugen, GraphQL vollständig in ihren Technologie-Stack zu übernehmen. 

Starbucks beauftragte einen Drittanbieter mit der Entwicklung seiner Progressive Web App (PWA).

Die Aufgabe des Teams bestand darin, ein Bestellsystem zu entwickeln, das die komplexe Geschäftslogik effizient und effektiv umsetzen würde. Da Kunden ihre Bestellungen personalisieren können, musste das Entwicklungsteam sicherstellen, dass das System mehrere Instanzen einzigartiger Geschäftslogik unterstützt und die richtigen Daten zur richtigen Zeit an den richtigen Ort sendet.

GraphQL ermöglichte es dem Team, eine effiziente API mit serverseitigem Caching und Rendering zu erstellen, um die Offline-Funktionalität zu verbessern. Das Team nutzte React außerdem, um Animationen zu integrieren und so ein dynamisches und fesselndes Benutzererlebnis zu schaffen.

Das Ziel des CTO-Büros von F5 bestand darin, herauszufinden, wie wir GraphQL im F5-Ökosystem nutzen können. Wir führen derzeit zwei Projekte durch, in denen die Verwendung von GraphQL untersucht wird.

Die von F5 angebotene Test Management Suite (TMS) bietet Kunden die Möglichkeit, Endpunkte oder Clients ihrer eigenen Systeme zu testen und festzustellen, ob es sich um Menschen oder Bots handelt.

Dies war ein internes Projekt zur Rationalisierung der Entwicklung und Prüfung der TMS-Software. Das Hauptziel bestand darin, in der vorhandenen SQL-Datenbank gefangene JSON-Daten zu extrahieren, in Diagrammdaten zu konvertieren und eine GraphQL-API für Abfragen zu implementieren.

Dies war notwendig, da die aktuelle Datenbank Herausforderungen mit sich bringt, darunter das „JSON-Blob-Problem“, das sich aus der Speicherung von Metadaten als JSON-Objekte in einer tabellarischen Datenbank ergibt. Das Parsen und Verarbeiten dieser Objekte ist naturgemäß teuer und ineffizient. Darüber hinaus enthalten die JSON-Blobs aufgrund ihrer grafischen Natur wertvolle Daten, die die Produkte und die Sicherheit von F5 weiter verbessern können. Durch die Umstellung auf eine gerichtete Graphdatenbank können die JSON-Blobs effizient analysiert und mit gerichteten Beziehungen verwaltet werden, wodurch die Datenübertragung und -nutzung optimiert wird. 

Die Ergebnisse sind ermutigend. Indem wir ermittelten, welche Tabellen in der relationalen TMS-Datenbank JSON-Blobs haben, stellten wir fest, dass die Umstellung auf eine GraphDB und die Verwendung von GraphQL unsere Transparenz im System um ein Vielfaches erhöhen könnte. 

Abbildung 9 zeigt die möglichen Entwicklungen oder Implementierungsoptionen für dieses Projekt. Jede Wahl hat ihre eigenen Auswirkungen.

Option 1 hat die geringsten Auswirkungen auf die Benutzeroberfläche, da der Client nicht geändert werden muss. Ein Hybridmodus, wie in den Optionen 1 oder 2, kann je nach Situation gut funktionieren, insbesondere wenn eine kleinere Anzahl von Spalten mit JSON-Objekten vorhanden ist. Darüber hinaus wäre auch das abgeleitete Schema für jedes JSON klein.

Bei dieser Planung stellten wir jedoch fest, dass die JSON-Objekte einen Kontext benötigten, der in anderen Spalten in der SQL-Datenbank gespeichert war. Die Größe des in jedem JSON-Objekt gespeicherten Schemas war ebenfalls ziemlich groß. Dies hätte zu mehr Arbeit bei der Wartung der Codebasis geführt. Nach sorgfältiger Überlegung haben wir uns entschieden, die Anwendung neu zu strukturieren, um GraphQL und Neo4J zu unterstützen, wie in Option 3 gezeigt.

CloudGraph ist eine kostenlose, universelle GraphQL-API und ein Cloud Security Posture Management (CSPM)-Tool mit Open Source für AWS, Azure, GCP und Kubernetes (K8s). Das Ziel des Projekts besteht darin, mithilfe von CloudGraph ein „CloudGraph-Plugin“ (Abbildung 10) zu erstellen, auf dem die Daten der F5 Distributed Cloud (F5XC) angezeigt werden, um so eine bessere Sichtbarkeit der über die F5 Distributed Cloud verbundenen Cloud-Ressourcen zu ermöglichen.

Unser Ziel ist die Integration mit CloudGraph, um ein tiefes Verständnis der Technologie zu erlangen und zukünftige CloudGraph-Integrationen, Erkenntnisse und GraphQL-APIs für F5XC-Daten zu erstellen.

Nachdem wir den benutzerdefinierten F5XC-Anbieter in die CloudGraph-Plattform integriert und die Funktion zum Erstellen von Beziehungen der Plattform genutzt haben, haben wir einen besseren Überblick über die mit F5XC verbundenen Cloud-Ressourcen und ihre Beziehungen zu anderen Clouds. Wir können dann für denselben Mandanten komplexe Abfragen zu Ressourcen in mehreren Clouds generieren. Dadurch können wir den Stakeholdern einen umfassenden Überblick über F5XC bieten und eine tiefere Integration von CloudGraph für zusätzliche GraphQL-Plugins und benutzerdefinierte Einblicke in Cloud-Operationen erkunden, die für F5 und seine Kunden relevant sind.

Unsere ersten Untersuchungen auf der Grundlage der oben genannten Initiativen entsprachen den Erfahrungen, die wir in den zuvor vorgestellten Fallstudien gemacht haben.

Ursprüngliche Annahmen hinsichtlich der Überlegenheit von GraphQL gegenüber REST in puncto Sicherheit haben sich als falsch herausgestellt, da GraphQL wie jede andere Technologie auch seine eigenen Risiken birgt, wenn es nicht richtig implementiert wird. Es ist wichtig zu erkennen, dass GraphQL nicht grundsätzlich sicherer ist als andere Technologien. Um die Sicherheit von GraphQL-APIs zu gewährleisten, sind eine ordnungsgemäße Implementierung und Einhaltung bewährter Methoden von entscheidender Bedeutung. Indem wir diesen Mythos zerstreuen, können wir GraphQL mit einem realistischen Verständnis seiner Sicherheitsaspekte angehen und geeignete Maßnahmen ergreifen, um mögliche Risiken zu mindern.

GraphQL bietet Entwicklern ein leistungsstarkes Tool namens Introspektion, mit dem sie Informationen über das von einem GraphQL-Dienst verwendete Schema anfordern können. Mithilfe dieses Tools können Entwickler mehr über den Dienst und seine Struktur erfahren. Allerdings sind mit der Selbstbeobachtung auch Risiken verbunden. Das Aktivieren der Introspektion in einem Produktions-GraphQL-Dienst bedeutet, dass auch auf vertrauliche Informationen innerhalb des Schemas zugegriffen werden kann. Dies stellt ein erhebliches Risiko dar, da böswillige Benutzer die Introspektion ausnutzen können, um an vertrauliche Daten zu gelangen und möglicherweise Schaden anzurichten. Darüber hinaus ermöglicht die Introspektion diesen Benutzern das einfache Erkennen potenziell schädlicher Vorgänge, da sie das gesamte Schema einsehen und bestimmen können, welche Abfragen ausgeführt werden sollen. Die Folgen eines solchen Lecks können katastrophal sein, je nach Art des Schemas und der darin enthaltenen Daten.

Schadensbegrenzung : Eine Lösung zur Minderung der Risiken der Introspektion besteht darin, sie in Produktions-APIs mithilfe verschiedener Frameworks zu deaktivieren. Durch die Deaktivierung der Introspektion verlieren Entwickler einige der praktischen Funktionen, die sie bietet. Um die Nutzbarkeit wiederherzustellen, können Entwickler das GraphQL-Schema der Produktions-API jedoch mit Tools wie GraphOS registrieren. Dadurch behalten sie kontrollierten Zugriff auf das Schema und seine Informationen.

SQL-Injection ist ein weithin anerkannter und weit verbreiteter Angriff, dessen Risiken von der Datenmanipulation bis zur vollständigen Löschung der Datenbank reichen. Bei diesem unkomplizierten Angriff macht man sich die Verkettung von Zeichenfolgen zunutze, wodurch ein Angreifer ausführbaren Code in die Eingabe einfügen kann, sich unbefugten Zugriff auf die Datenbank verschafft und böswillige Änderungen ermöglicht. Interessanterweise ist dieser Angriffsvektor nicht nur auf SQL-Datenbanken beschränkt, sondern kann auch grafische Datenbanken wie Neo4j betreffen. Neo4j verwendet die Abfragesprache Cypher, die SQL ähnelt und dessen Schwachstellen erbt. Diese als Cypher-Injection bezeichnete Angriffsart nutzt die Ähnlichkeiten aus, profitiert aber auch von vorhandenen Lösungen, ohne dass neue Erfindungen erforderlich sind.

Schadensbegrenzung : Zu den Gegenmaßnahmen gehören die Bereinigung der Benutzereingaben, um eine Ausnutzung zu erkennen und zu verhindern, und die Verwendung der Parametrisierung, um die Benutzereingaben von der direkten Abfrageerstellung zu abstrahieren. Durch diese Maßnahmen lässt sich die Gefahr von Injection-Angriffen wirksam verringern. Es ist wichtig, dieses Sicherheitsproblem in GraphQL-Implementierungen zu beheben, aber glücklicherweise stehen bekannte und leicht implementierbare Lösungen zur Verfügung. 

Das Aufsetzen einer GraphQL-API auf eine REST-API kann zu SSRF-Schwachstellen (Server Side Request Forgery) führen. Angreifer können dies ausnutzen, indem sie Parameter ändern, die über den GraphQL-Proxy an die REST-API gesendet werden. Wenn keine der APIs die Parameter für bestimmte Aufrufe validiert, erlangen Angreifer Kontrolle über das Backend-System. Wenn Sie beispielsweise in einer GraphQL-Abfrage an eine Benutzer-ID „/delete“ anhängen, kann dies zu einer unbeabsichtigten Löschung von Daten führen, wenn diese an die REST-API übergeben werden.

Schadensbegrenzung : Obwohl diese Sicherheitslücke ein berechtigtes Anliegen ist, kann sie wirksam behoben werden, indem Typen im GraphQL-Schema definiert und Parameter gründlich validiert werden, bevor sie an externe APIs oder Dienste gesendet werden. Es ist wichtig zu beachten, dass diese Sicherheitslücke sowie andere mit GraphQL verbundene Sicherheitslücken eher auf Implementierungsprobleme zurückzuführen sind als dass sie auf inhärente Probleme mit GraphQL selbst zurückzuführen sind. Solche Probleme entstehen, wenn GraphQL aufgrund einer kurzfristigen Mentalität missbraucht wird, obwohl die Technologie vielversprechend ist.

Authentifizierungsschwachstellen sind ein weit verbreiteter Angriffsvektor in verschiedenen Systemen, einschließlich GraphQL. Die Fähigkeit von GraphQL, mehrere Abfragen oder Mutationen in einer einzigen Anfrage zu senden, macht es anfällig für Batch-Angriffe, bei denen Brute-Force-Methoden zum Einsatz kommen.

Bei der ersten Angriffsart geht es darum, Anmeldekennwörter mit roher Gewalt zu erzwingen. Angreifer senden eine Anfrage mit zahlreichen Mutationen, die Anmeldedatenpaare enthalten. Da GraphQL viele Mutationen in einer Anfrage zulässt, umgeht dieser Angriff die Ratenbegrenzungsprüfungen und ermöglicht die Erstellung einer Sitzung durch Brute-Force-Angriffe auf Passwörter.

Die zweite Art von Angriff funktioniert ähnlich, zielt jedoch auf eine beliebte Form der Zwei-Faktor-Authentifizierung (2FA) ab, das sogenannte One-Time-Passwort (OTP). Eine einzelne Anfrage wird mit mehreren Mutationen gesendet, von denen jede gültige Anmeldeinformationen gepaart mit einer anderen OTP-Variante enthält. Wenn eine der Mutationen das richtige OTP enthält, wird die Anforderung authentifiziert und eine Sitzung hergestellt.

Schadensbegrenzung : Die Behebung dieser Schwachstellen erfordert einen umfassenden Ansatz, da es keine hundertprozentige Lösung gibt. Entwickler spielen eine entscheidende Rolle, indem sie sichere Codierungspraktiken übernehmen und die Perspektive der Geschäftslogik betonen. Auf der Webserverseite müssen unbedingt Maßnahmen wie die Begrenzung der Anmeldeversuche und die Validierung der Benutzereingaben umgesetzt werden. Darüber hinaus sollte beim Scannen von Anfragen auf mehrere Mutationen besondere Aufmerksamkeit geschenkt werden, da ein legitimer Anmeldeversuch normalerweise nicht mehr als eine Mutation umfasst.

Bei diesen Angriffen wird der GraphQL-Dienst mit übermäßigem Datenverkehr überlastet, sodass er nicht mehr in der Lage ist, Anfragen legitimer Benutzer zu verarbeiten, was möglicherweise zu Serverabstürzen führt. DoS-Angriffe können durch rekursive GraphQL-Abfragen oder durch das Senden großer Abfrageanforderungen ausgeführt werden.

Im Szenario rekursiver Abfragen nutzen Angreifer die zyklische Natur von GraphQL-Schemadefinitionen aus. Wenn das Schema beispielsweise die Typen „Autor“ und „Buch“ enthält, kann ein Angreifer den Autor und das Buch wiederholt in einer Schleife abfragen, den Server mit rekursiven Aufrufen überlasten und seinen Betrieb stören.

Alternativ können Angreifer Abfragen stellen, die umfangreiche Datenmengen aus der Datenbank anfordern. Beispielsweise kann eine Abfrage viele Autoren und alle zugehörigen Bücher abrufen. Eine derart massive Datenanforderung kann das System erheblich verlangsamen oder zum Absturz bringen .

Schadensbegrenzung : Es gibt mehrere Lösungen, um dieses Problem zu mildern. Der erste Ansatz besteht darin, ein Timeout für Abfragen festzulegen, um Benutzer daran zu hindern, Anfragen zu stellen, die eine bestimmte Dauer überschreiten. Allerdings wird das Problem hierdurch möglicherweise nicht vollständig behoben, da innerhalb der vorgegebenen Zeit dennoch Schäden auftreten können. Eine andere Lösung besteht darin, Beschränkungen hinsichtlich der Abfragetiefe und -komplexität durchzusetzen. Abfragen, welche die vorgesehene Tiefe überschreiten oder eine von der Schemadefinition abweichende Komplexität aufweisen, können abgelehnt werden. Schließlich kann auch die Implementierung einer Benutzerdrosselung wirksam sein. Wenn ein Benutzer eine große Anzahl oder mehrere aufeinanderfolgende Anfragen sendet, kann ihm der Zugriff auf den Server vorübergehend verweigert werden, bis der Server bereit ist, weitere Anfragen zu verarbeiten.

Wie gezeigt gibt es mehrere Bereitstellungsmuster für GraphQL, jedes mit seinen eigenen Kompromissen und Überlegungen. Zu den häufigsten Mustern gehören:

Dies ist das einfachste und gebräuchlichste Muster zum Bereitstellen einer GraphQL-API. Bei einer monolithischen Bereitstellung werden der GraphQL-Server, die Datenbank und alle anderen erforderlichen Dienste zusammen als eine Einheit bereitgestellt. Dies kann den Einstieg in GraphQL erleichtern, kann jedoch mit dem Wachstum der Anwendung schwierig zu skalieren und zu warten werden. 

Zusammengesetzte Monolithen beziehen sich auf die Architektur, bei der eine monolithische Anwendung durch eine Kombination aus monolithischen Diensten und Mikrodiensten erstellt wird, wobei GraphQL als API-Schicht fungiert (Abbildung 12). Bei diesem Muster wird das gesamte System nicht in separate Microservices zerlegt, sondern die Anwendung wird zunächst als separater Monolith entwickelt, der die gesamte Geschäftslogik und die Datenzugriffsebenen kapselt. 

Innerhalb dieser monolithischen Struktur wird GraphQL als API-Schicht implementiert, sodass Clients Daten von verschiedenen zugrunde liegenden Microservices anfordern und abrufen können. Dies bedeutet, dass die Anwendung aus Bereitstellungsperspektive zwar monolithisch bleibt, GraphQL jedoch als Mittel zum Zusammenstellen von Daten aus verschiedenen Diensten und zum Präsentieren dieser Daten für Clients auf flexible und effiziente Weise nutzt.

Dieses Muster bietet Vorteile wie eine vereinfachte Entwicklung und Bereitstellung sowie die Möglichkeit, die leistungsstarken Abfrage- und Datenabruffunktionen von GraphQL zu nutzen. Entwickler können damit schrittweise die Microservices-Architektur übernehmen und gleichzeitig von der Flexibilität und Benutzerfreundlichkeit von GraphQL profitieren. 

Föderierte Graphen in GraphQL-Bereitstellungsmustern beinhalten die Kombination mehrerer GraphQL-Dienste, sogenannter Subgraphen, in einem einzigen einheitlichen GraphQL-Schema. Jeder Subgraph stellt eine separate Domäne oder einen separaten Mikrodienst mit eigenen Daten und Funktionen dar. Diese Architektur verwendet ein zentrales Gateway, das Client-Anfragen basierend auf den angeforderten Feldern an den entsprechenden Teilgraphen weiterleitet. Durch die Zusammenführung dieser Untergraphen können Entwickler einen zusammenhängenden Graphen erstellen, in dem Clients nahtlos Abfragen durchführen und zwischen verschiedenen Diensten wechseln können.

Dieser Ansatz fördert Modularität, Skalierbarkeit und unabhängige Entwicklung von Diensten, was zu verbesserter Leistung und Flexibilität beim Erstellen von GraphQL-APIs führt. Föderierte Subgraphen (Abbildung 13) bieten eine leistungsstarke Möglichkeit, Daten aus verschiedenen Diensten zusammenzustellen und eine verteilte und skalierbare Architektur zu erstellen.

Hybridgraphen (Abbildung 14) in GraphQL-Bereitstellungsmustern kombinieren föderierte Teilgraphen und nicht-föderierte Schemata durch Stitching-Techniken. Dieser Ansatz ermöglicht es Organisationen, vorhandene GraphQL-APIs oder Legacy-Systeme mit föderierten Microservices zu integrieren, was zu einer einheitlichen GraphQL-API führt, die von beiden Ansätzen profitiert. Durch das Zusammenführen von Schemata und das Auflösen von Beziehungen zwischen Typen und Feldern bietet die hybride Grapharchitektur Flexibilität, Modularität und Skalierbarkeit.

Das hybride Graphmuster bietet Organisationen die Möglichkeit, die Föderation schrittweise einzuführen und gleichzeitig ihre vorhandenen Ressourcen zu nutzen. Es ermöglicht die nahtlose Integration föderierter Teilgraphen und nicht föderierter Schemata, berücksichtigt unterschiedliche Anforderungen und fördert die Interoperabilität. Dieser Ansatz ermöglicht es Organisationen, umfassende GraphQL-APIs zu erstellen, die skalierbar und an sich entwickelnde Anforderungen anpassbar sind. Durch die Kombination der Stärken föderierter und nicht föderierter Dienste bieten Hybridgraphen eine flexible und leistungsstarke Lösung zum Erstellen von GraphQL-Bereitstellungen.

Zu den Herausforderungen bei hybriden Graphen in GraphQL-Bereitstellungen gehören die Verwaltung der Komplexität zusammengeführter Schemata, die Bewältigung potenzieller Leistungseinbußen, die Gewährleistung von Datenkonsistenz und -integrität, die Handhabung der Systementwicklung und Versionierung sowie die Bewältigung der Komplexität von Überwachung und Debugging in einer verteilten Architektur. Um diese Herausforderungen zu meistern und einen reibungslosen Betrieb hybrider Graphbereitstellungen zu gewährleisten, sind sorgfältige Planung, Optimierung und robuste Entwicklungspraktiken erforderlich. 

Dieses Muster beinhaltet die Bereitstellung der GraphQL-API als Satz serverloser Funktionen, wie etwa AWS Lambda oder Google Cloud Functions. Dies kann eine kostengünstige und skalierbare Möglichkeit zum Bereitstellen einer GraphQL-API sein, kann aber auch zusätzliche Latenzzeiten mit sich bringen und die Komplexität der Architektur erhöhen.

Serverloses Routing bringt viele Herausforderungen mit sich. Ein Problem besteht darin, verteilte Teilgraphen nahtlos zu verbinden, wenn die Anwendung erweitert wird. Die Koordination mehrerer Teams und Bereitstellungen kann komplex werden, wodurch die effektive Verwaltung und Skalierung der Teilgraphen eine Herausforderung darstellt. Die Gewährleistung der Datenkonsistenz und -synchronisierung zwischen diesen Teilgraphen stellt eine weitere Hürde dar. Die Überwachung und Fehlerbehebung in einer verteilten Serverless-Umgebung kann schwieriger sein und erfordert entsprechende Protokollierungs- und Fehlerbehandlungsmechanismen. Darüber hinaus ist die Verwaltung der Zugriffskontrolle und Autorisierung über mehrere serverlose Funktionen und Untergraphen hinweg eine Herausforderung. Die Bewältigung dieser Herausforderungen ist für den reibungslosen Betrieb und die Skalierbarkeit einer serverlosen GraphQL-Bereitstellung von entscheidender Bedeutung.

In einem Edge-Bereitstellungsmuster für GraphQL-APIs wird die API mithilfe eines CDN-Dienstes näher an den Clients platziert. Dies bringt mehrere Vorteile mit sich, darunter eine geringere Latenz für schnellere Antworten, eine geringere Belastung des Ursprungsservers und Schutz vor DDoS-Angriffen.

Durch die Verteilung der API-Infrastruktur auf Edge-Server weltweit kann der Datenverkehr effizienter abgewickelt und weltweit für ein besseres Benutzererlebnis gesorgt werden. Die Caching- und Filterfunktionen des CDN tragen dazu bei, die Skalierbarkeit zu verbessern und die Verfügbarkeit der API sicherzustellen, selbst bei hohem Datenverkehr oder böswilligen Angriffen. Edge-Bereitstellungen bieten das Potenzial, durch Nutzung des Servernetzwerks von CDNs die Leistung und Zuverlässigkeit einer API zu optimieren. 

GraphQL-Technologien sind ausgereift genug, um von traditionellen Unternehmen übernommen zu werden. Obwohl Gartners Hype Cycle für APIs 2022 darauf hinweist, dass es von einer flächendeckenden Einführung noch mehrere Jahre entfernt ist, haben wir jetzt einen kritischen Wendepunkt erreicht, an dem die erforderlichen Tools bereits vorhanden sind. Obwohl GraphQL noch relativ neu ist, hat es sich bereits soweit entwickelt, dass es die Anforderungen etablierter Großunternehmen erfüllen kann.

Die Reife der GraphAPI-Technologien beruht auf der wachsenden Zahl von Unternehmen, die GraphQL und andere Graphdatenbanktechnologien nutzen. Da immer mehr Unternehmen diese Technologien übernehmen, werden die zur Unterstützung dieser Technologien erforderlichen Werkzeuge und Ressourcen zunehmend verfügbar, was es für andere Unternehmen einfacher macht, diesem Beispiel zu folgen. Darüber hinaus werden die Vorteile von GraphAPI-Technologien – wie etwa verbesserte Datenabfragen und reduzierte Komplexität – immer stärker anerkannt, was ihre Akzeptanz bei Großunternehmen weiter fördert.

Als Branche müssen wir die Bedeutung von GraphAPI-Technologien wie GraphQL und ihr Potenzial zur Überwindung der Einschränkungen von REST erkennen. Unternehmen dürfen die dringende Notwendigkeit nicht übersehen, in GraphQL zu investieren und es zu verstehen, insbesondere im Hinblick auf Datenmodellierung, Vielfalt und Intransparenz. Obwohl man sich leicht in die Funktionen und das Potenzial von GraphQL verlieben kann, muss man sich auch darüber im Klaren sein, dass nach dem Erreichen des Höhepunktes überzogener Erwartungen eine Talsohle der Ernüchterung eintreten kann. Die Anbieter müssen der Erweiterung ihrer Produkte Priorität einräumen, um GraphQL vollständig zu unterstützen, während die Unternehmens-IT – einschließlich der Anbieter – ermitteln sollte, welche Daten von der Nutzung von GraphQL zur Produktivitätssteigerung profitieren würden.

Kunden müssen dem Verständnis ihrer Daten Priorität einräumen und erkennen, dass ein durchschnittliches Unternehmen anders vorgeht als die Hyperscaler, die GraphQL ursprünglich eingeführt haben. Lassen Sie uns gemeinsam daran arbeiten, GraphQL als effektives Softwarearchitekturmuster zu etablieren und die Branche in Richtung besserer Produktivität und Innovation voranzutreiben.

Laden Sie den Bericht herunter