#4 J’ai rêvé de GraphQL — le graphe de votre entreprise.

Pour certains, GraphQL est juste un nouveau protocole à la mode, sorti des labos de Facebook pour palier aux problèmes de REST. 

Mais c’est beaucoup plus profond et important que cela.

GraphQL permet de définir de manière simple et explicite un graphe des objets de votre entreprise. Vous définissez de types d’objets, les champs les composant et les relations entre eux et laissez les utilisateurs explorer votre système d’information en parcourant le graphe.

GraphQL définit également un langage de requêtes des données ultra simple, mais très complet. Ce langage est agnostique de la source des données et des API sous-jacentes. GraphQL permet à n’importe quelle application d’aller chercher n’importe quelle donnée, sans savoir où cette donnée se trouve et sous quelle forme, en explorant le graph avec les requêtes.

Votre objet “client” se trouve dans votre AS400, mais aussi, en partie, dans SalesForce et dans votre e-commerce Magento ? Aucun souci, du point de vu de l’extérieur, toute cette complexité est cachée par GraphQL, rendant, du coup très simple les remplacements et migrations des outils sous-jacents.

GraphQL fonctionne en mode requête, grâce aux resolvers — petites fonctions que vous pouvez écrire dans n’importe quel langage et qui sont appelés par le serveur GraphQL pour aller chercher et traiter les données. Les resolvers — espèces de micro-serivces, peuvent faire des requêtes en base, ou faire appel aux API des systèmes sous-jacents, mais aussi des choses plus folles comme charger des fichiers, faire des calculs, scrapper le web ou lancer un moteur de recherche.

GraphQL fonctionne aussi avec la mise à jour des données, grâce aux mutations, cela vous permet de modifier les données de vos applications, sans exposer la complexité interne de votre système d’information.

Mais, surtout, GraphQL résout un problème clef : l’evolution des API.

Puisque vous n’avez plus qu’un seul endpoint, votre API n’évolue jamais.

Vous rajoutez des objets métier, vous changez vos resolvers mais vos applications clientes ne voient aucun impact. Ce découplage est un accélérateur immense pour les équipes et donne un sérieux coup de canif dans les bus de services et autres API Gateways. 

La conception des API a toujours été problématique

L’API expose une certaine logique métier, mais surtout de la donnée métier aux utilisateurs. Ce faisant, et quelque soit le protocole sous-jacent, le concepteur de l’API fait des hypotheses sur l’usage de son API. 

Et il se trompe forcément, car les usages et applications clients évoluent rapidement. Sous la pression des “change requests”, l’API évolue, mais n’arrive jamais à suivre les demandes des équipes front, nécessite alors des rustines (middlewares, caches, proxys, bus de services) et altère in fine le plus important : l’experience utilisateur front.

Si l’API est, exposée en externe, c’est encore pire : tout changement impacte alors des centaines de partenaires ou clients et devient complexe à introduire. 

L’API évolue alors peu et l’usage en pâtit. 

Avec GraphQL au contraire, vous exposez aux clients (internes ou externes) le graphe de la représentation sémantique vos objets métiers. Charge aux applications clientes d’effectuer les requêtes dont elles ont besoin. De votre coté, vous ne maintenez que des resolvers et mutations qui adressent vos outils internes (bases de données, fichiers, API, ERPs, etc…)

Description sémantique des objets VS objets réels.

Une nuance importante à prendre en considération est le fait que vous présentez un graphe, qui est une representation sémantique de vos objets métiers, pas les détails de leur réalité technique. 

Par exemple, les identifiants de clefs et autres champs techniques n’ont pas à être exposés dans le graphe. 

Si vous présentez un objet Article contenant des Commentaires, mais que vous ne cherchez jamais un commentaire par son identifiant, vous n’avez pas à exposer dans le graph l’ID d’un commentaire. Cela vous laisse le loisir de passer à tout moment à BazaarVoice ou Disqus, sans que les applications clientes n’en sachent rien.

GraphQL est auto-documenté.

L’autre aspect important des API, est la documentation. Avec GraphQL le besoin est fortement réduit, c’est un standard, vous n’avez pas à expliquer aux clients comment utiliser votre API, par ailleurs GraphQL propose un système d’introspection permettant de découvrir le graph sans lire de documentation, pour peut que vous nommiez vos champs correctement.

GraphQL est protecteur de votre système d’information

Si GraphQL ne résoudra en rien les problèmes de performance de votre SI, il jouera le rôle de protecteur, puisque vous pouvez intégrer du cache au niveau de vos resolvers.

GraphQL permet la fédération des schémas

Quand vous avancez dans la mise en place de GraphQL votre schéma va grossir et il est très probable que plusieurs équipes travaillent en parallèle et sur plusieurs outils sur des objets très coeur comme le Client, le Produit, la Facture ou le Contrat. Vous pouvez, alors utiliser la fédération de GraphQL pour laisser une certaine indépendance à chaque équipe tout en présentant, in fine, un graphe unique à vos clients. Vous évitez également le gaspillage et encouragez la réutilisation.

GraphQL n’est pas la solution à tous les problèmes…

Comment avec n’importe quelle technologie, GraphQL n’est pas LA solution pour tout faire.

Il existe, par exemple, une limitation majeure dans GraphQL, connue sous le nom de N+1 ou, plutôt 1+N. Chaque resolver ne connait que son parent au moment de l’execution d’une requête. Donc, si vous souhaitez charger toutes les commandes de tous les clients, GraphQL va exécuter le chargement de la liste des clients, puis, pour chaque client charger ses commandes. C’est un problème de performance majeur, mais, heureusement limité et qui a déjà une solution avec la mise en place d’un DataLoader.

Globalement, si vous souhaitez charger des requêtes croisées complexes, vous devez encore créer des endpoints sur mesure, probablement en REST ou utiliser des outils du type DataLoader si vous souhaitez absolument rester en 100% GraphQL.

Le cache est également problématique puisqu’il doit se faire au niveau des resolvers et pas devant le serveur GraphQL (vous n’avez qu’un seul endpoint). 

Enfin, si vous ne contrôlez pas les autorisations des clients, vous risquez des pics de charge avec des clients executant des requêtes complexes. 

Chaque inconvenient évoqué a des solutions assez simples mais il est important d’en être conscient au moment de se lancer dans l’implémentation.

Alors, plutôt que de tenter developper une API parfaite, qui ne le sera jamais, ouvrez le Graph de votre entreprise auprès des utilisateurs et laissez créer les usages dont ils ont besoin. 

Et vous qu’en pensez vous ?