it-swarm.com.de

GraphQL- und Microservice-Architektur

Ich versuche zu verstehen, wo GraphQL am besten für die Verwendung in einer Microservice-Architektur geeignet ist.

Es gibt einige Debatten darüber, dass nur ein GraphQL-Schema als API-Gateway fungiert, das die Anforderung an die Ziel-Microservices weiterleitet und deren Antwort erzwingt. Microservices würden immer noch REST/Thrift-Protokoll für Kommunikationsgedanken verwenden.

Ein anderer Ansatz besteht stattdessen darin, mehrere GraphQL-Schemata pro Mikroservice bereitzustellen. Einen kleineren API-Gateway-Server haben, der die Anforderung mit allen Informationen der Anforderung und der GraphQL-Abfrage an den gewünschten Microservice weiterleitet.

1. Ansatz

1 GraphQL-Schema als API-Gateway zu haben, hat einen Nachteil: Jedes Mal, wenn Sie die Eingabe/Ausgabe Ihres Microservice-Vertrags ändern, müssen wir das GraphQL-Schema auf der API-Gateway-Seite entsprechend ändern.

2. Ansatz

Wenn Sie mehrere GraphQL-Schemas pro Microservice verwenden, ist dies in gewisser Weise sinnvoll, da GraphQL eine Schemadefinition erzwingt und der Konsument die Eingabe/Ausgabe des Microservice respektieren muss.

Fragen

  • Ob Sie GraphQL für den Entwurf einer Microservice-Architektur für geeignet halten?

  • Wie würden Sie ein API-Gateway mit einer möglichen GraphQL-Implementierung entwerfen?

136

Auf jeden Fall Ansatz 1.

Wenn Ihre Kunden mit mehreren GraphQL-Diensten sprechen (wie in Ansatz 2), wird der Zweck der Verwendung von GraphQL in erster Linie völlig zunichte gemacht, nämlich, ein Schema über Ihre gesamten Anwendungsdaten bereitzustellen, um das Abrufen zu ermöglichen es in einer einzigen Rundreise.

Eine shared nothing Architektur mag aus Sicht von Microservices vernünftig erscheinen, aber für Ihren clientseitigen Code ist dies ein absoluter Albtraum, da Sie jedes Mal, wenn Sie einen Ihrer Microservices ändern, aktualisieren müssen - alle Ihrer Kunden. Sie werden es auf jeden Fall bereuen.

GraphQL und Microservices passen perfekt zusammen, da GraphQL die Tatsache verbirgt, dass die Clients über eine Microservice-Architektur verfügen. Aus Sicht des Backends möchten Sie alles in Microservices aufteilen. Aus Sicht des Frontends möchten Sie jedoch, dass alle Ihre Daten von einer einzigen API stammen. Die Verwendung von GraphQL ist meines Wissens die beste Möglichkeit, beides zu tun. Damit können Sie Ihr Backend in Microservices aufteilen und gleichzeitig eine einzige API für Ihre gesamte Anwendung bereitstellen und Verknüpfungen zwischen Daten von verschiedenen Diensten zulassen.

Wenn Sie REST für Ihre Microservices nicht verwenden möchten, können Sie natürlich für jeden eine eigene GraphQL-API verwenden, aber Sie sollten trotzdem ein API-Gateway haben. Der Grund, warum Benutzer API verwenden Gateways sollen es einfacher machen, Microservices von Client-Anwendungen aus aufzurufen, und nicht, weil sie gut in das Microservices-Muster passen.

200
helfer

Lesen Sie den Artikel hier , in dem steht, wie und warum Ansatz 1 besser funktioniert. Schauen Sie sich auch das folgende Bild aus dem Artikel an, den ich erwähnt habe: enter image description here

Einer der Hauptvorteile, wenn sich alles hinter einem einzelnen Endpunkt befindet, besteht darin, dass Daten effektiver weitergeleitet werden können, als wenn jede Anforderung einen eigenen Dienst hätte. Während dies der häufig angepriesene Wert von GraphQL ist, eine Verringerung der Komplexität und des Serviceschleichens, ermöglicht die resultierende Datenstruktur auch, dass der Besitz von Daten äußerst genau definiert und klar abgegrenzt wird.

Ein weiterer Vorteil von GraphQL ist die Tatsache, dass Sie den Datenladeprozess grundsätzlich besser steuern können. Da der Prozess für Datenladeprogramme an einem eigenen Endpunkt abläuft, können Sie die Anforderung entweder teilweise, vollständig oder mit Einschränkungen erfüllen und so die Datenübertragung äußerst detailliert steuern.

Der folgende Artikel erklärt diese beiden Vorteile zusammen mit anderen sehr gut: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

25
Enayat

Für Ansatz Nr. 2 wähle ich genau das, weil es viel einfacher ist, das lästige API-Gateway manuell zu warten. Auf diese Weise können Sie Ihre Services eigenständig entwickeln. Machen Sie sich das Leben leichter: P

Es gibt einige großartige Werkzeuge, um Schemata in einem zu kombinieren, z. graphql-weaver und apollo's graphql-tools , ich benutze graphql-weaver, es ist einfach zu bedienen und funktioniert super.

6
HFX

Ab Mitte 2019 hat die Lösung für den 1. Ansatz nun den Namen " Schema Federation " geprägt von der Apollo people (Früher wurde dies oft als GraphQL-Stitching bezeichnet). Sie schlagen auch die Module @apollo/federation und @apollo/gateway dafür.

HINZUFÜGEN: Beachten Sie, dass Sie mit Schema Federation das Schema auf Gateway-Ebene nicht ändern können. Für jedes Bit, das Sie in Ihrem Schema benötigen, benötigen Sie einen separaten Service.

4
vanthome

Ich habe mit GraphQL und Microservices gearbeitet

Aus meiner Erfahrung heraus ist es für mich eine Kombination beider Ansätze, abhängig von der Funktionalität/Nutzung. Ich werde nie ein einziges Gateway wie in Ansatz 1 haben, sondern nur einen Graphql für jeden Mikroservice als Ansatz 2.

Zum Beispiel, basierend auf dem Bild der Antwort von Enayat, würde ich in diesem Fall 3 Graph-Gateways haben (nicht 5 wie im Bild)

enter image description here

  • App (Produkt, Warenkorb, Versand, Inventar, benötigt/verknüpft mit anderen Diensten)

  • Zahlung

  • Benutzer

Auf diese Weise müssen Sie besonders auf die Gestaltung der erforderlichen/verknüpften Mindestdaten achten, die von den abhängigen Diensten verfügbar gemacht werden, z. B. ein Authentifizierungstoken, eine Benutzer-ID, eine Zahlungs-ID und einen Zahlungsstatus

Nach meiner Erfahrung habe ich zum Beispiel das "Benutzer" -Gateway, in GraphQL habe ich die Benutzerabfragen/-mutationen, Login, Anmelden, Abmelden, Passwort ändern, E-Mail wiederherstellen, E-Mail bestätigen, Konto löschen, Profil bearbeiten, Bild hochladen , etc ... Dieses Diagramm ist für sich genommen ziemlich groß !, es ist getrennt, da sich die anderen Dienste/Gateways am Ende nur um die resultierenden Informationen wie Benutzer-ID, Name oder Token kümmern.

Dieser Weg ist einfacher zu ...

  • Skalieren/Herunterfahren der verschiedenen Gateway-Knoten je nach Verwendung. (Zum Beispiel bearbeiten Leute möglicherweise nicht immer ihr Profil oder zahlen ... aber die Suche nach Produkten wird möglicherweise häufiger verwendet).

  • Sobald ein Gateway ausgereift ist, wächst, die Nutzung bekannt ist oder Sie über mehr Fachwissen in der Domäne verfügen, können Sie identifizieren, welche Teile des Schemas ein eigenes Gateway haben könnten (... ist mir mit einem riesigen Schema passiert, das mit Git-Repositorys interagiert , Ich habe das Gateway, das mit einem Repository interagiert, getrennt und festgestellt, dass die einzige erforderliche/verknüpfte Information ... der Ordnerpfad und der erwartete Zweig ist.

  • Die Geschichte Ihrer Repositorys ist klarer und Sie können ein Repository/Entwickler/Team für ein Gateway und die damit verbundenen Microservices einrichten.

0
Victor Jimenez