GraphQL est un langage de d'interrogation de données initialement utilisé en 2012 en interne par les équipes de Facebook. En 2015, un premier prototype open-source est ouvert au public par le biais de Facebook Open Source, la branche de Facebook dédiée aux logiciels libres et ouverts au public.

La plupart du temps il est utilisé pour servir d'API permettant de requêter des données sur le web par le biais de HTTP ou Websocket bien qu'il n'est pas contraint à ces usages et protocoles.

Mais qu'est-ce dont qu'un graphe ?

Brièvement : Un graphe en architecture logicielle et base de données est une façon de modéliser des relations entre des noeuds (entités).

Un graphe de relation entre des utilisateurs et des films

Jusqu'à là rien de très anormal, c'est ce que l'on a déjà tendance à faire aujourd'hui pour exprimer l'interconnexion de nos données.

Où se positionne GraphQL sur une architecture logicielle ?

Très bonne question, en réalité GraphQL vient se placer comme un middleware entre les clients qui demande les données (terminaux mobiles, navigateurs web, …) et les possesseurs de ces données (services tiers, base de données, …). Il permet d'agréger ces données diverses et fourni une abstraction permettant de les requêter unitairement, très simplement et cela de manière sécurisé.

Le schéma illustre à quel endroit se positionne la couche middleware sur une architecture client / serveur.

L'emplacement de GraphQL sur une architecture client / serveur

Il ajoute du typage statique à des APIs, ce qui renforce la confiance et la sécurité des échanges.

Pour cette raison, le standard GraphQL est souvent comparé à REST (qui n'est lui pas un standard à proprement parler, mais plus une collection d'idées pour architecturer les échanges de données). Il vient préciser et combler certaines lacunes et certains aspects de ce dernier.


De REST à GraphQL

Comparaison des paradigmes

En quoi GraphQL est une amélioration par rapport à REST ?

Imageons cela grâce à un burger afin de comprendre une partie des avantages:

BurgerQL — Imager les différences entre GraphQL et REST avec de la bouffe

Le premier burger est issue d'un endpoint REST classique, le second burger lui vient d'un endpoint GraphQL. Imaginons maintenant un commit de cuisine qui exécute les ordres du chef cuisinier.

Dans le premier cas le chef cuisinier REST dit au commit : « donne moi le burger /burger ». Il reçoit quelques minutes après un burger avec du pain, salade, tomate, steak et fromage.

Dans ce cas là : la personnalisation est limitée, on reçoit ce qui a été défini en dur dans la recette (le schéma de données n'est pas statique et dépend de l'implémentation). Si l'on souhaite un burger différent et personnalisé : il faut modifier le endpoint ou en créer un nouveau, ce qui rend difficile le versionnage de l'API et surtout est complètement imprédictible pour le client.

Dans le second cas le chef de cuisine GraphQL définie une requête détaillée en demandant uniquement les ingrédients qu'il souhaite obtenir. Il dit donc « donne moi le contenu de la recette getBurger, par contre dans celle-ci je voudrais un burger avec pain, steak et salade uniquement ».  Il obtient quelques minutes plus tard un burger sur mesure répondant exactement à ses attentes.

Cette fois-ci la requête est très déclarative et personnalisée, il n'y a pas d'excès d'ingrédient. Le client est pleinement satisfait et il n'y a pas de gaspillage.

Que faut-il retenir ?

GraphQL définie un contrat entre les acteurs, une interface déclarative décrivant ce qu'il est possible de requêter et dans quelle mesure, là où REST est plus abstrait bien que certains standards tel que JSON API ont essayés de standardiser un peu le concept.

Mais alors qu'est-ce qu'on y gagne à utiliser GraphQL ?

Je traite volontairement brièvement cette partie que je développerais plus tard dans d'autres articles.

Les avantages sont entre-autres :

  • Une accélération du développement frontend en utilisant un paradigme déclaratif. Les développeurs se concentrent plus sur le quoi plutôt que sur le comment.
  • Une réduction de l’« over et under fetching». Le réseau est allégé car seulement les données nécessaires à la requête transitent. Il n'y a pas besoin de faire plusieurs « rounds trips » pour obtenir les données nécessaires à l'affichage.
  • Plus de prédictibilité. On sait à l'avance grâce au contrat d'interface ce qu'il est possible de requêter et de quels types de données vont être retournées.
  • Plus d'éco-conception. Il n'y a pas d'excès de données et plusieurs requêtes peuvent être regroupées dans un seul appel HTTP par exemple, ce qui permet une réduction des charges réseaux.
  • Un langage de requête qui est : protocole, langage de programmation, client agnostique. GraphQL tourne sur toutes les configurations et pour tous les cas d'usage.

Quelles conséquences à l'utilisation de la solution ?

Comme tout dans ce monde, l'utilisation d'un outil induit de nouvelles problématiques, ici également : je survole quelques principes qui seront abordés plus tard.

  • Le nombre de requêtes côté serveur induit par le Lazy-loading de GraphQL peut exploser. Ce qui peut impacter les performances et nécessites certaines optimisations.
  • Un changement de mentalité est nécessaire dans la façon d'architecturer les services. Il faut penser conception en Graphe.
  • Des difficultés pour utiliser le cache HTTP avec Varnish, NginX, HAProxy par exemple du fait qu'il n'y a qu'un seul endpoint qui reçoit les requêtes.

Pour conclure

GraphQL est un outil très pratique qui pourrait bien porter votre application au niveau suivant, en la renforçant et la rendant plus prédictible.

Bien qu'aux premier abords cela semble verbeux et assez complexe, dans la réalité des faits la prise en main est plutôt bonne, notamment grâce à des outils comme Apollo ou Prisma.