Was ist GraphQL-Föderation?

Die Föderation unterteilt das Schema – sozusagen den Vertrag zwischen Backend- und Frontend-Vorgängen – in besser verwaltbare Komponenten und Microservices, sodass Teams Teile eines Schemas unabhängig voneinander erstellen, bereitstellen und verwalten können, während ein einheitliches Datendiagramm für die Interaktion der Kunden beibehalten wird. 

In einer föderierten GraphQL-Umgebung integriert ein GraphQL-Gateway mehrere Schemata – auch Subgraphen oder Dienste genannt – in einen einzigen Graphen (oder Router). Jeder Subgraph definiert einen Teil des Gesamtschemas und übernimmt die Geschäftslogik und den Datenabruf für seine eigenen Typen und Felder. Das Gateway fügt dann eigenständige Subgraphen zu einem Supergraphen zusammen, sodass Kunden Datenquellen über verschiedene Dienste hinweg abfragen können, als würden sie mit einem einzigen GraphQL-Schema interagieren.

Vor der Föderierung war eine der wichtigsten Methoden zur Kombination mehrerer GraphQL-Schemata das Schema-Stitching, bei dem verschiedene Schemata und Resolver manuell kombiniert werden. Dabei mussten Entwickler definieren, wie die Schemata zusammengeführt und wie Daten zusammengefügt werden. Das Schema-Stitching bot zwar eine einheitliche Lösung für GraphQL-Schemata, war jedoch auch komplex und fehleranfällig, was die Verwaltung erschwerte.

Um diese Probleme anzugehen und die Schema-Stitching-Prozesse zu optimieren, haben die Entwickler von Apollo – einer GraphQL-Implementierung für die Produkt- und App-Entwicklung – die Apollo-Föderation entwickelt. Die Apollo-Föderation führte die Schlüsselwörter „key“, „external“, „requires“ und „extends“ ein, um die Verbindungen zwischen Typen in verschiedenen Diensten zu definieren. Mithilfe der neuen Querverweis-Funktionen konnten Entwickler ein Apollo-Gateway nutzen, um ein zusammenhängendes Datendiagramm zu erstellen, ohne auf eine übermäßig komplexe Stitching-Logik angewiesen zu sein.

Die Apollo GraphQL-Föderation bestand jedoch nicht nur aus einer Reihe neuer Tools und Bibliotheken. Sie umfasste auch eine Systemspezifikation, die die Architektur und die Art und Weise beschrieb, wie Dienste kommunizieren können, um ein verteiltes Diagramm zu bilden. Dadurch konnten andere Implementierungen und Tools die Föderationsprinzipien übernehmen und es wurde ein Standard für die Erstellung von föderierten GraphQL-APIs festgelegt.

Seit seiner Einführung hat die GraphQL-Föderation zahlreiche Verbesserungen erfahren. Die verwaltete Föderation kann beispielsweise die Erfassung von Messdaten erleichtern und automatische Gateway-Updates ermöglichen, wenn sich Teilgraphen ändern, und das alles ohne manuelle Eingriffe oder Systemausfallzeiten.

Zu den Weiterentwicklungen gehört auch die Entwicklung von Federation 2¹, einer Innovation, die die dienstübergreifende Schema-Zusammenführung und Abfrageausführung vereinfacht, die Modularität für eine bessere Kontrolle über die Schema-Zusammensetzung erhöht und die Sichtbarkeit von Fehlern für eine einfachere Nachverfolgung und Fehlerbehebung verbessert.

Die Apollo-Föderation stellte einen bedeutenden Fortschritt für den Aufbau optimierter API-Ökosysteme dar und bleibt eine Option für Unternehmen, die föderierte IT-Architekturen einsetzen möchten.

Dennoch bindet ein auf Apollo basierender Föderationsansatz Entwickler an eine Implementierung eines einzigen Anbieters, da Apollo-föderierte Umgebungen nur Apollo-definierte Anweisungen und Typen von Apollo oder Apollo-konformen Backend-Technologien akzeptieren können. Mit anderen Worten: Eine Apollo-Föderation schränkt die Systemflexibilität oft ein, selbst wenn neue Technologien verfügbar werden.

Entwickler, die die Flexibilität optimieren und gleichzeitig die Unified-Layer-Funktionalität der Apollo-Föderation beibehalten möchten, bevorzugen möglicherweise eine offene Föderation. Mit Ansätzen der offenen Föderation können Systeme Daten von jedem API-Anbieter oder -Typ kombinieren, einschließlich Nicht-GraphQL-APIs. Mit Tools wie IBM API Connect können Unternehmen ihre IT-Ressourcen ohne Kompatibilitätseinschränkungen anpassen und skalieren und weiterhin Innovationen aus einer Reihe von Technologie-Communitys übernehmen.

Mit GraphQL können Kunden genau die Daten anfordern, die sie benötigen, ohne dass Ressourcen unter- oder überdimensioniert werden. Dies macht GraphQL zu einer großartigen Option für Unternehmen, die ihre betriebliche Effizienz optimieren möchten.

Angesichts seiner Flexibilität ist es nicht verwunderlich, dass GraphQL eine immer beliebtere Abfragesprache und Laufzeitumgebung für APIs ist.² Da Web- und Mobilanwendungen jedoch immer ausgefeilter werden, kann die Bereitstellung eines einzelnen, monolithischen GraphQL-Servers (und all seiner Abhängigkeiten) zu einer unhaltbaren Situation führen. Die Föderation vereinfacht GraphQL-Ökosysteme, indem sie unterschiedliche Teilgraphen dabei unterstützt, als ein zusammenhängender GraphQL-Dienst ineinanderzugreifen.

Die Implementierung einer föderierten GraphQL-Architektur umfasst die folgenden zentralen Prozesse.

Die Definition von Subgraph-Schemata umfasst die Identifizierung von Domaingrenzen und die Entscheidung, wie diese Grenzen interagieren sollen. 

In einer föderierten Architektur stellt jedes Subgraph-Schema einen bestimmten Teil des gesamten Datendiagramms dar. Es enthält Typen, Konfigurationen, Abfragen, Mutationen und Abonnements, die für einen Dienst oder eine Domäne gelten. Ein Produktdienst kann beispielsweise ein Subgraph-Schema haben, das Typen wie Produkt und Bewertung enthält, während ein Benutzerdienst über Benutzer- und Profiltypen verfügen kann.

Subgraph-Schemata werden auf ähnliche Weise wie ein Standard-GraphQL-Schema definiert, jedoch mit zusätzlichen föderationsspezifischen Anweisungen. Föderationsanweisungen enthalten Anweisungen dazu, wie ein System Entitäten über Schemata hinweg erweitert und wie das Gateway bestimmte Felder über Dienste hinweg auflösen sollte. Sie definieren auch Schlüssel für die Referenzierung von Entitäten.

Ein Beispiel: Die @key-Direktive gibt die Felder an, die einen Typ in föderierten Graphen identifizieren. Bei der Bereitstellung fordert diese Direktive das Gateway auf, eine Entität von dem Dienst abzurufen, dem der angegebene Typ gehört. Die @extends-Direktive gibt an, dass ein in einem Subgraph-Schema definierter Typ einen Typ erweitert, der aus einem anderen stammt, und erleichtert so die Typenerweiterung (mit zusätzlichen Feldern) in einem anderen Dienst.

Subgraph-Dienste sind Back-End-Dienste, welche die Geschäftslogik für entsprechende Subgraph-APIs implementieren. Jeder Subgraph-Dienst definiert seinen Teil des Datendiagramms und verarbeitet Abfragen und Mutationen im Zusammenhang mit seinem Bereich. Ihre jeweiligen Resolver rufen alle zugehörigen Daten aus den entsprechenden Datenquellen, Datenbanken oder REST-APIs ab.

Subgraph-Dienste zeigen ihre GraphQL-Endpunkte auch dem Föderations-Gateway an, das sie zur Erstellung des gesamten Föderationsschemas verwendet. Beachten Sie, dass diese Dienste in jeder beliebigen Programmiersprache geschrieben werden können, vorausgesetzt, die Sprache unterstützt GraphQL.

Föderations-Gateways koordinieren die Schemaerstellung und Abfrageplanung. Mithilfe von Föderationsservern verschleiern Gateways einzelne Subgraph-Dienste und präsentieren dem Client eine einheitliche API.

Um ein Föderations-Gateway zu konfigurieren, geben die Teams in der Regel den Standort jedes Subgraph-Dienstes an und richten die für das Abrufen von Schemata, die Abfrageplanung, die Ausführung und die Fehlerbehandlung erforderliche Infrastruktur ein. Sobald das Gateway eingerichtet ist, ruft es die Schemata kontinuierlich von den Subgraph-Diensten ab, um sicherzustellen, dass es über die aktuellste Version des Föderationsschemas verfügt.

Wenn die Subgraph-Dienste und das Föderations-Gateway konfiguriert sind, stellen die Administratoren das gesamte System bereit. Dies umfasst die Bereitstellung von Hardware und Cloud-Ressourcen, die Einrichtung von Bereitstellungspipelines, die Überwachung der Systemleistung und die Sicherstellung einer hohen Ressourcenverfügbarkeit.

Es sollte nicht überraschen, dass eine konsistente Echtzeitüberwachung für die Optimierung einer föderierten GraphQL-Umgebung unerlässlich ist. Durch eine sorgfältige Überwachung können Teams Leistungsengpässe, Systemfehler und ungeplante Ausfallzeiten erkennen und beheben, bevor sie größere Probleme verursachen. Darüber hinaus ermöglicht die Überwachung die Zustandsüberwachung für Subgraph-Dienste und das Föderations-Gateway.

Die GraphQL-Föderation stellt einen bedeutenden Fortschritt bei der Entwicklung von GraphQL-APIs für große, verteilte Systeme dar. Mit ihr können Teams unabhängig voneinander an verschiedenen Teilen eines GraphQL-Schemas arbeiten und ihre Arbeit nahtlos in eine einheitliche API integrieren, ohne dass die Endbenutzererfahrung beeinträchtigt wird.

Die GraphQL-Föderation hat auch eine Vielzahl von Anwendungsfällen – von der Bereitstellung und Zwischenspeicherung von Microservice-Architekturen bis hin zu Erkenntnissen über Produktentwicklung und -betrieb – und wurde von Unternehmen wie Netflix, Airbnb, GitHub und Expedia übernommen.

Darüber hinaus ermöglicht die GraphQL-Föderation Folgendes: