Anwendungsfälle für mehrere benutzerdefinierte Endpunkte
GraphQL ist darauf ausgelegt, einen einzigen Endpunkt für die Datenabfrage bereitzustellen. Es gibt jedoch Situationen, in denen es sinnvoller ist, stattdessen mehrere benutzerdefinierte Endpunkte anzubieten, wobei jeder dieser Endpunkte ein angepasstes Schema präsentiert. So können wir unterschiedlichen Nutzern oder Anwendungen ein unterschiedliches Verhalten bereitstellen, indem wir einfach den aufgerufenen Endpunkt wechseln.
Mehrere Endpunkte in GraphQL bereitzustellen ist nicht gleichbedeutend mit REST. Während in REST jeder Endpunkt Zugang zu einer vordefinierten Ressource oder einer Menge von Ressourcen bietet, ermöglicht jeder der mehreren GraphQL-Endpunkte weiterhin den Zugriff auf alle Daten seines Schemas – so lässt sich genau das abrufen, was wir brauchen. Es handelt sich also weiterhin um das normale GraphQL-Verhalten, mit dem zusätzlichen Vorteil, auf Daten aus verschiedenen Schemas zugreifen zu können.
Diese Fähigkeit unterscheidet sich auch von Schema Stitching oder Federation, die es ermöglichen, mehrere Datenquellen in einem einzigen, vereinheitlichten Graphen zusammenzuführen. Bei mehreren Endpunkten haben wir es mit mehreren Schemas zu tun. Die Absicht ist, diese eigenständig zu behandeln und nicht als Teil eines größeren Schemas.
Das Bereitstellen unterschiedlicher Schemas kann Zugang zu mehreren unabhängigen Graphen ermöglichen. GraphQL-Schöpfer Lee Byron erklärt, wann dies nützlich sein kann:
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
Lass uns einige weitere Anwendungsfälle erkunden, in denen es sinnvoll ist, mehrere GraphQL-Endpunkte bereitzustellen.
Admin- und öffentlichen Endpunkt separat bereitstellen
Wenn wir einen einzigen Graphen für alle Daten im Unternehmen verwenden, können wir überprüfen, wer Zugriff auf die verschiedenen Felder in unserem GraphQL-Schema hat, indem wir Zugriffssteuerungsrichtlinien einrichten. Zum Beispiel können wir Felder so konfigurieren, dass sie nur für angemeldete Nutzer oder Nutzer mit einer bestimmten Rolle zugänglich sind.
Wenn es jedoch Felder gibt, die sensible oder vertrauliche Informationen enthalten, die unter keinen Umständen für unberechtigte Akteure zugänglich sein sollten, ist es besser, diese Felder gar nicht erst in einem öffentlichen Schema bereitzustellen, sondern nur in einem privaten Schema, auf das ausschließlich das Team Zugriff hat. Diese Strategie schützt unsere privaten Daten vor unbeabsichtigten Problemen wie Software-Bugs und Nachlässigkeit bei der Schema-Konfiguration, und erhöht die Sicherheit zusätzlich, indem nur Besucher von bestimmten IPs Zugriff auf den privaten Endpunkt erhalten.
Daher können wir zwei separate Schemas erstellen – das Admin- und das Public-Schema – und sie jeweils unter den Endpunkten /graphql/admin (mit beschränktem Zugriff für Besucher von bestimmten IPs) und /graphql/public (für alle zugänglich) bereitstellen.
Zugriff auf private Informationen auf sicherere Weise einschränken
Dieser Abschnitt ist eine Verallgemeinerung des vorherigen: Es geht nicht nur um öffentlich vs. Admin, sondern um jede Situation, in der eine Gruppe von Nutzern definitiv keinen Zugriff auf Informationen einer anderen Gruppe haben darf.
Wenn wir beispielsweise für unsere verschiedenen Kunden angepasste Schemas erstellen müssen, können wir für jeden von ihnen einen benutzerdefinierten Endpunkt bereitstellen (/graphql/some-client, /graphql/another-client usw.), was sicherer sein kann, als ihnen Zugriff auf dasselbe vereinheitlichte Schema zu geben und sie über die Zugriffssteuerung zu validieren.
Verschiedenen Anwendungen ein unterschiedliches Verhalten bereitstellen
Wir können verschiedenen Anwendungen, die auf dieselbe Datenquelle zugreifen, ein unterschiedliches Verhalten gewähren.
Reddit beispielsweise liefert eine unterschiedliche Antwort, je nachdem ob es von einem Desktop-Browser oder einem mobilen Browser aufgerufen wird. Im Desktop-Browser können wir den Inhalt unabhängig davon, ob wir angemeldet sind oder nicht, direkt anzeigen:
Beim Zugriff über Mobilgeräte hingegen müssen wir angemeldet sein, um auf den Inhalt zugreifen zu können, und wir werden dazu aufgefordert, stattdessen die App zu nutzen:
Dieses unterschiedliche Verhalten könnte durch das Erstellen von zwei Schemas – dem Desktop- und dem Mobile-Schema – und deren Bereitstellung unter /graphql/desktop bzw. /graphql/mobile realisiert werden.
Eine Website in verschiedenen Sprachen generieren
Wenn wir dieselbe Website in verschiedenen Sprachen generieren möchten, können wir den Sprachcode bereits in die Struktur des benutzerdefinierten Endpunkts integrieren, z. B. /graphql/en für Englisch und /graphql/fr für Französisch. Der GraphQL-Server kann diese Information dann abrufen und die Daten in die gewünschte Sprache übersetzen.
Schließlich verweisen wir im statischen Website-Generator auf jeden dieser Endpunkte, um die Website in der einen oder anderen Sprache zu generieren:
Ein aktualisiertes Schema vor der Veröffentlichung für die Produktion testen
Wenn wir unser GraphQL-Schema aktualisieren und eine Gruppe von Nutzern es vorab testen lassen möchten, können wir dieses neue Schema über einen /graphql/upcoming-Endpunkt bereitstellen. Noch besser: Wir könnten auch einen /graphql/bleeding-edge-Endpunkt bereitstellen, der das Schema kontinuierlich aus DEV deployt.
Den BfF-Ansatz unterstützen
Backend-for-Frontends (kurz BfF) ist ein Ansatz zur Bereitstellung verschiedener APIs für verschiedene Clients, wobei jeder Client seine eigene API „besitzt" und so die optimale Version basierend auf seinen eigenen Anforderungen erstellen kann.
In diesem Modell ist ein benutzerdefiniertes BfF der Mittelsmann zwischen den Back-End-Diensten und seinem Client:
Dieses Modell lässt sich in GraphQL umsetzen, indem alle BfFs in einem einzigen GraphQL-Server mit mehreren Endpunkten implementiert werden, wobei jeder Endpunkt einem spezifischen BfF/Client zugeordnet ist (z. B. /graphql/mobile und /graphql/web):
