Verständnis von föderiertem GraphQL

Eine Anmerkung vor dem Beitrag: Dieser Artikel wurde ursprünglich auf dem Blog von Contentful veröffentlicht. Ich habe ihn als Gastbeitrag im Rahmen ihres Autorenprogramms verfasst. Alle Bilder in diesem Beitrag wurden von ihnen erstellt. Ein besonderer Dank geht an ihr Team, nicht nur für die Bilder, sondern auch für die Unterstützung bei der Bearbeitung dieses Beitrags und der Veröffentlichung auf ihrer Website.

---

In den letzten Jahren hat das Content Management einen Wandel in der Art und Weise erfahren, wie wir unsere Projekte gestalten. Immer mehr Menschen wechseln von Monolithen zu einer Microservice-Architektur. Wenn Sie bereits Contentful verwenden, haben Sie bereits von den Vorteilen dieser microservice-orientierten Herangehensweise profitiert.

Microservices sind ein Schritt in die richtige Richtung, stellen jedoch eine neue Reihe technischer Herausforderungen dar. Beim Einsatz von beliebig vielen Microservices, die von beliebigen Kanälen genutzt werden, können Skalierungs- und Wartungsprobleme auftreten.

Als Antwort auf diese technischen Hürden ist GraphQL Federation entstanden. GraphQL Federation ist eine Architektur, die mehrere Schemata zu einem einzigen Endpunkt kombiniert.

Der Weg zur föderierten Architektur

Um GraphQL Federation besser zu verstehen, ist es hilfreich, die Entwicklung in der API-Architektur bis zu diesem Punkt zu betrachten.

Alles begann mit unserer traditionellen Monolithen-API. Diese APIs enthielten mehrere Endpunkte zur Datenabfrage in Ihrer Organisation.

Beispielsweise könnte eine E-Commerce-Organisation Endpunkte für Daten über Produkte und Kunden haben. Es könnten Endpunkte für das Übermitteln von Formularen und die Verarbeitung von Daten während des Checkouts existieren. Möglicherweise gibt es auch Endpunkte für Backend-Services wie die Verwaltung von Produkt- oder Kundendaten.

All dies erfordert viel Wartung. Sie bräuchten ein Entwicklungsteam, das Kenntnisse in all diesen verschiedenen Bereichen hat oder zumindest weiß, wie Änderungen in einem Bereich andere Bereiche beeinflussen können. Sie teilen dieselbe Code-Basis, was Sie weniger agil macht. Die Koordination von inkrementellen oder großen Feature-Änderungen in den verschiedenen Bereichen kann zu Kopfschmerzen führen.

Microservices sind die Lösung für diese Probleme.

Microservices können all diese Probleme der Monolithen-Architektur lösen. Ich werde nicht im Detail auf alle Vorteile von Microservices im Vergleich zu Monolithen eingehen. Stattdessen empfehle ich Ihnen diesen Artikel über Monolithen vs. Microservices, um weitere Informationen zu erhalten.

Es ist wichtig zu verstehen, dass die Komposition von Microservices es uns ermöglicht, unsere API einfach zu entwickeln und zu skalieren. Das Hinzufügen/Aktualisieren von Microservices kann in ihrer eigenen Silo-Umgebung erfolgen, ohne andere Services zu beeinträchtigen.

Als wir begannen, Microservices zu nutzen, sind wir dann dazu übergegangen, einen API-Gateway zu verwenden.

Das API-Gateway versucht, das Beste aus beiden Welten - Microservices und monolithische Architekturen - zu kombinieren. Im Backend haben wir immer noch unsere zusammensetzbaren Microservices. Das Gateway bietet Clients einen einheitlichen Endpunkt. Es kann auch andere Dienste wie Authentifizierung oder benutzerdefinierte Geschäftslogik verwalten.

Federation ist der nächste Schritt im Architekturdesign. Während das API-Gateway Verbesserungen gegenüber Microservices bietet, erfordert der einheitliche Endpunkt immer noch domänenspezifische Logik, um alle Services zu vereinen. Das liegt daran, dass das API-Gateway nicht von den Microservices entkoppelt ist. Federation verbessert dies, indem es den einheitlichen Endpunkt beibehält und gleichzeitig die entkoppelte und verteilte Architektur der Microservices beibehält.

Schlüsselfunktionen von GraphQL Federation

Verteilte Architektur

Federation profitiert von der verteilten Architektur, die durch Microservices entsteht. Microservices selbst sind eine Form der verteilten Architektur, bei der die Komponenten Ihrer Anwendung in separate Dienste aufgeteilt sind.

Dies gewährleistet Skalierbarkeit, Entkopplung und manchmal verbesserte Leistung. Skalierbarkeit wird durch unsere Fähigkeit erreicht, neue Microservices hinzuzufügen und sie sofort in unseren föderierten Endpunkt einzubinden. Unsere Fähigkeit, Aktualisierungen an einem Service vorzunehmen, ohne andere zu beeinträchtigen, gewährleistet, dass wir die Dinge entkoppelt halten.

Federation erreicht diese verteilte Architektur, indem sie ihr einheitliches Schema aus den Schemata jedes Microservices zusammenstellt.

Schemazusammensetzung

Schemazusammensetzung bezieht sich auf die Gruppierung von Schemata über Ihre verteilte Architektur hinweg zu einem einzelnen, vereinheitlichten Schema.

Schauen wir uns unser E-Commerce-Beispiel an. Angenommen, die Kundendienstabteilung muss einen Kunden nachschlagen und den Versandstatus seiner Bestellung überprüfen. Ohne Federation müssten Sie mit den folgenden Schemata arbeiten:

# Vereinfachtes Benutzer-Schema
type User {
  id: ID!
  firstName: String
  lastName: String
}

# Vereinfachtes Auftrags-Schema
type Order {
  id: ID!
  userId: ID!
  shipped: Boolean
  products: [Product]!
}

Dieses vereinheitlichte Schema wird automatisch aus allen Teil-Schemas zusammengesetzt. Dadurch können wir unsere entkoppelte Architektur beibehalten.

# Vereinfachtes kombiniertes Schema
type User @key(fields: "id"){
  id: ID!
  firstName: String!
  lastName: String!
  orders: [Order]! @provides(fields: "id shipped")
}

type Order {
  id: ID!
  shipped: Boolean!
  products: [Product]! @provides(fields: "id name")
}

type Product @key(fields: "id") {
  sku: ID! @external
  name: String @external
  inStock: Boolean
  price: Int
}

Detailliertes Wissen darüber, wie all diese verschiedenen Services miteinander interagieren, ist nicht erforderlich. Ihre Kanäle müssen nur mit einem einzigen Schema interagieren. Das Föderations-Gateway weiß, wie Anfragen an den entsprechenden Service weitergeleitet werden müssen.

Dies ist eine vereinfachte Version, wie diese Subgraphs kombiniert werden könnten. Zusätzliche Routing-Daten würden hinzugefügt werden, um dem Gateway mitzuteilen, welchen Subgraphen es abfragen soll.

Effiziente Datenabfrage

Mit unserem zusammengesetzten Schema kann unser föderiertes Gateway Daten intelligent abfragen. Basierend auf diesem Schema werden Anfragen optimiert und an ihre jeweiligen Dienste weitergeleitet.

Basierend auf dem kombinierten Schema können Anfragen vom Gateway an die jeweiligen Teilgraphen weitergeleitet werden. Diese Abfragen können auch parallel ausgeführt werden, um die Effizienz zu verbessern.

Zusätzlich zur effizienten Abfrage werden auch Caching auf Feldebene und das Stapelladen von Daten implementiert. Dies verbessert die Gesamtleistung und Effizienz.

Wie man föderiertes GraphQL implementiert

Die gute Nachricht ist, dass Backend-Entwickler unabhängig von ihrer bestehenden Architektur eine vollständig föderierte Dienste-Architektur übernehmen können. Ob Sie mit einem Monolithen oder Mikroservices arbeiten, Sie können ein föderiertes Gateway einrichten. Anschließend können Sie schrittweise Ihren Monolithen entkoppeln.

Von hier aus empfehle ich, die Apollo GraphOS-Dokumentation zur Föderation zu überprüfen. Dort finden Sie Tutorials zum Einstieg in die Föderation sowie weitere technische Details.

Überlegungen zur GraphQL-Föderation

Wie bei jeder architektonischen Gestaltung gibt es Dinge, die vor der Implementierung berücksichtigt werden müssen. Obwohl wir gegenüber der Monolith-Architektur Fortschritte gemacht haben, haben wir immer noch einen einzelnen Ausfallpunkt mit unserem Gateway.

Ein weiterer Aspekt, den Sie berücksichtigen müssen, ist, dass mit der Hinzufügung einer API-Gateway-Schicht eine potenzielle Zunahme der Latenz auftreten könnte. Jede Anfrage muss vom Gateway entgegengenommen und an den entsprechenden Dienst weitergeleitet werden.

Fazit

GraphQL-Föderation ist eine API-Architektur, die das Beste aus sowohl monolithischen APIs als auch Mikroservices nutzt. Sie bietet einen einzigen Endpunkt für alle Ihre Dienste und gleichzeitig eine verteilte Architektur.

Mit der Föderation erhalten Sie ein entkoppeltes Design, Schema-Komposition und effiziente Datenabfrage. Unabhängig von Ihrer bestehenden Architektur können Sie mit der Migration zu einer föderierten Architektur beginnen.

Schauen Sie sich unbedingt die Apollo-Dokumentation an oder treten Sie dem Contentful Discord bei, wenn Sie mehr über GraphQL-Föderation erfahren möchten.