Introduction

Dans un monde où les applications monolithiques se font de plus en plus rares, et les APIs de plus en plus présentes, de nombreuses branches évolutives se dessinent, avec toutes leurs avantages et leurs inconvénients. Dans les architectures d’APIs modernes “classiques”, on retrouve le plus souvent les APIs REST (ou RESTfull). Le principe de ces APIs sont simples : une requête HTTP, un endpoint, une action, donc un format de réception des données et un format de sortie (même si l’on peut agrémenter ces points de paramètres spécifiques afin de récupérer seulement les informations souhaitées).

La problématique principale de ce design REST, pour certains projets, est que, comme dit, un endpoint correspond le plus souvent à un format d’entrée, un traitement et un format de sortie. Dans le cadre d’une très grosse application où l’on veut pouvoir tout contrôler de façon très avancée, et connaître exactement les impacts de quel appel, cela peut rester un avantage (encore que GraphQL est tout à fait capable de logiques de sécurité complexes, comme on le verra plus tard).

Dans le cas d’une petite à moyenne application où la volonté est un développement et une capacité d’évolution extrêmement rapide, par exemple pour un POC ou encore si les spécifications de l’application ne sont pas clairement définies et que l’on veut pouvoir changer rapidement de direction, GraphQL est une très bonne alternative au modèle REST.

GraphQL et ses avantages

GraphQL est une norme qui se met en place côté backend et frontend, permettant non plus côté backend de définir des endpoints avec leur spécification et côté frontend de les appeler pour récupérer des données ou faire des actions, mais côté backend de définir les modèles de données, récupérateurs de données (Query) et mutateurs de données (Mutation), et côté frontend de les utiliser comme bon nous semble (un peu à la manière de fonctions RCP).

En effet côté backend, GraphQL s’expose sur une seule URL, que l’on appelle depuis le front en précisant la fonction que l’on veut appeler, les paramètres à lui passer, et les données que l’on veut en récupérer.

Un exemple concret serait un article de blog. Côté backend, on écrit notre modèle de données, on créé un Query qui nous permettra de récupérer la liste des articles, un autre pour en récupérer un seul, et par exemple trois Mutation pour respectivement créer, modifier et supprimer un article.

Une fois que cela a été créé (et la sécurité gérée, on le verra plus tard), le backend est terminé.

On peut maintenant passer côté front où l’on appellera, en utilisant les librairies GraphQL spéciales frontend, ou tout simplement en forgeant les requêtes à la main en suivant la spécification GraphQL :

  • Nos fonctions de Query afin de récupérer nos articles, en choisissant dans l’appel la liste des champs / relations que l’on voudra récupérer
  • Nos fonctions de Mutation afin de créer, modifier ou supprimer des articles, en leurs passant les paramètres nécessaires à l’exécution de la fonction, et la liste des champs que l’on veut récupérer sur l’article créé / modifié / supprimé (oui, on peut faire ça)

La notion de récupération des relations est très importante car elle constitue l’un des avantages principaux de GraphQL. Une fois les relations entre nos données définies dans le backend (par exemple un Article et son Auteur), on peut en une seule requête décider de récupérer l’Article et l’Auteur, simplement en le demandant à la fonction de récupération. On peut même choisir quels champs de l’Auteur on veut récupérer ! Et si l’auteur avait une relation sur un Groupe, on peut même pousser jusqu’ici, et plus loin encore !

On peut très rapidement comprendre les avantages d’un tel système sur des applications vouées à évoluer fortement et rapidement, surtout si celles-ci sont par la suite déployées en micro-services : plus besoin pour faire évoluer le frontend de faire évoluer le backend (sauf ajout ou modification de logique métier).

La définition des Query / Mutations

Deux solutions se posent à nous côté serveur pour ces définitions :

  • Définition du modèle et des Queries / Mutations à la main
  • Utilisation d’Adapters qui nous permettront de générer pour nous les modèles, Query et Mutation dont nous avons besoin. Comprenez toutefois que si une logique complexe est à appliquer pour, par exemple, la vérification des permissions, on peut parfois être amenés à devoir écrire nous-même les fonctions.
    Un exemple est pour une application NodeJS utilisant MongoDB avec le package Mongoose pour la gestion de la base de données, les packages graphql-compose et graphql-compose-mongoose nous permettent de définir automatiquement les modèles de données, Query et Mutation basées sur le modèle Mongoose.

Quid de la sécurité

Avant de commencer à utiliser GraphQL, la première des raisons qui me retenait était celle de la sécurité.

Comment sécuriser un backend qui expose des fonctions que l’on peut appeler librement ?”

La réponse est simple : exactement de la même manière et avec la même facilité que l’on sécurise un backend REST : avec des middlewares et / ou des vérifications de sécurité à l’intérieur des fonctions.

GraphQL propose en effet des systèmes d’injection de contexte, pour par exemple récupérer les informations d’un utilisateur, de middleware pour en vérifier l’authentification et les permissions, et de bien d’autres systèmes permettant de sécuriser notre API aussi bien (sinon mieux) qu’en REST.

NON, GraphQL pas une passoire de sécurité.

GraphQL est-il fait pour tous les projets

La réponse courte est non.

Pour rentrer un peu plus dans le détail, GraphQL est une norme qui a fait ses preuves, on rappellera qu’elle est backée par Facebook, qui créa plus tard la GraphQL Foundation, regroupant des grandes entreprises du web et aujourd’hui en charge de la maintenance et de l’évolution du projet.

Elle reste cependant une manière particulière d’appréhender l’API. Une manière qui ne convient pas à tous les projets, et surtout pas à tout le monde. Beaucoup d’entreprises sont encore très réfractaires à l’utilisation de GraphQL, elles ont toutes des raisons, la plus commune étant tout simplement la volonté de ne pas avoir une techno de plus à mettre sur les fiches de poste.

Conclusion

GraphQL n’est pas une techno particulièrement récente, contrairement à ce que l’on entend beaucoup. C’est une techno qui va bientôt avoir 10 ans, qui a fait ses preuves, qui est backée par de très grandes entreprises technologiques et possédant un environnement technique extrêmement riche. Elle reste cependant une technologie à la marge, regardée un peu de loin, que beaucoup hésitent encore aujourd’hui à toucher du bout du doigt.

Alors, quelle est votre excuse pour ne pas l’essayer ?

Julien Pontillo