Cas d'usage pour plusieurs endpoints personnalisés
GraphQL est censé exposer un seul endpoint pour interroger les données. Cependant, il existe des situations où il est plus judicieux d'exposer plusieurs endpoints personnalisés, où chacun de ces endpoints présente un schéma personnalisé. Cela nous permet de fournir un comportement distinct pour différents utilisateurs ou applications en changeant simplement l'endpoint accédé.
Exposer plusieurs endpoints dans GraphQL n'équivaut pas à REST. Alors qu'en REST chaque endpoint fournit l'accès à une ressource prédéfinie ou à un ensemble de ressources, chacun des multiples endpoints GraphQL fournira toujours l'accès à l'ensemble des données de son schéma, permettant de récupérer exactement ce dont nous avons besoin. Il s'agit donc toujours du comportement normal de GraphQL, avec en plus la possibilité d'accéder aux données depuis différents schémas.
Cette capacité est également différente du schema stitching ou de la federation, qui permettent d'incorporer plusieurs sources de données dans un graphe unique et unifié. Avec plusieurs endpoints, nous traitons avec plusieurs schémas. L'intention est de les traiter de manière indépendante, et non comme faisant partie d'un schéma plus grand.
Exposer différents schémas peut fournir un accès à plusieurs graphes indépendants. Le créateur de GraphQL Lee Byron explique quand cela peut être utile :
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.
Explorons quelques cas d'usage supplémentaires où exposer plusieurs endpoints GraphQL est judicieux.
Exposer séparément les endpoints admin et public
Lorsque nous utilisons un seul graphe pour toutes les données de l'entreprise, nous pouvons valider qui a accès aux différents champs de notre schéma GraphQL en configurant des politiques de contrôle d'accès. Par exemple, nous pouvons configurer des champs pour qu'ils ne soient accessibles qu'aux utilisateurs connectés ou aux utilisateurs ayant un certain rôle.
Cependant, lorsqu'il existe des champs contenant des informations sensibles ou confidentielles, de sorte qu'en aucun cas ceux-ci ne devraient être accessibles à des acteurs non autorisés, nous préférons ne pas exposer ces champs dans un schéma public en premier lieu, mais uniquement dans un schéma privé auquel seule l'équipe a accès. Cette stratégie protégera nos données privées des problèmes non intentionnels, tels que les bugs logiciels et la négligence lors de la configuration du schéma, et renforcera même la sécurité en autorisant uniquement les visiteurs provenant de certaines IP à accéder à l'endpoint privé.
Ainsi, nous pouvons créer deux schémas distincts, les schémas Admin et Public, et les exposer respectivement sous les endpoints /graphql/admin (et restreindre l'accès aux visiteurs provenant d'une certaine IP) et /graphql/public (accessible à tous).
Restreindre l'accès aux informations privées de manière plus sécurisée
Cette section est une généralisation de la précédente : il ne s'agit pas seulement de public versus admin, mais de toute situation dans laquelle un ensemble d'utilisateurs ne doit certainement pas pouvoir accéder aux informations d'un autre ensemble d'utilisateurs.
Par exemple, chaque fois que nous avons besoin de créer des schémas personnalisés pour nos différents clients, nous pouvons exposer un endpoint personnalisé pour chacun d'eux (/graphql/some-client, /graphql/another-client, etc), ce qui peut être plus sûr que de leur donner accès au même schéma unifié et de les valider via le contrôle d'accès.
Fournir un comportement différent à différentes applications
Nous pouvons accorder un comportement différent aux différentes applications accédant à la même source de données.
Par exemple, Reddit produit une réponse différente selon qu'on y accède depuis un navigateur de bureau ou depuis un navigateur mobile. Depuis le navigateur de bureau, que nous soyons connectés ou non, nous pouvons directement visualiser le contenu :
En accédant depuis un mobile, en revanche, nous devons être connectés pour accéder au contenu, et nous sommes encouragés à utiliser l'application à la place :
Ce comportement différent pourrait être fourni en créant deux schémas, les schémas Desktop et Mobile, et en les exposant respectivement sous /graphql/desktop et /graphql/mobile.
Générer un site en différentes langues
Si nous voulons générer le même site en différentes langues, nous pouvons faire en sorte que le code de langue fasse déjà partie de la structure de l'endpoint personnalisé, comme /graphql/en pour l'anglais et /graphql/fr pour le français. Ensuite, le serveur GraphQL peut récupérer ces informations et traduire les données dans la langue souhaitée.
Enfin, nous pointons vers chacun de ces endpoints dans le générateur de site statique pour produire le site dans l'une ou l'autre langue :
Tester un schéma amélioré avant de le publier en production
Si nous voulons mettre à jour notre schéma GraphQL et avoir un ensemble d'utilisateurs qui le testent à l'avance, nous pouvons exposer ce nouveau schéma via un endpoint /graphql/upcoming. Encore mieux, nous pourrions également exposer un endpoint /graphql/bleeding-edge, qui continue de déployer le schéma depuis DEV.
Prendre en charge l'approche BfF
Backend-for-Frontends (BfF en abrégé) est une approche pour produire différentes API pour différents clients, où chaque client « possède » son API, lui permettant de produire la version la plus optimale en fonction de ses propres exigences.
Dans ce modèle, un BfF personnalisé est l'intermédiaire entre les services back-end et son client :
Ce modèle peut être satisfait dans GraphQL en faisant en sorte que tous les BfFs soient implémentés dans un seul serveur GraphQL avec plusieurs endpoints, chaque endpoint traitant un BfF/client spécifique (comme /graphql/mobile et /graphql/web) :
