GraphQL : un query language pour votre API

02.12.2020
Implémenté par Facebook un an avant le fameux framework React, puis publié comme projet Open-Source en 2015, GraphQL est un « query-language » permettant de créer des API. Un langage ayant conquit beaucoup d'entre nous de par ses principales fonctionnalités :
Dev

Une création Facebook

Depuis de (très) nombreuses années, l’architecture REST fait office de standard dans le développement d’API Web. Cependant, depuis 2015, une alternative à ce modèle prend petit à petit de l’ampleur et tend à le remplacer. Cette dernière se nomme GraphQL et nous allons comprendre pourquoi elle convainc de plus en plus de développeurs et d’entreprises telles que Github, Airbnb ou encore Netflix.


Une API REST est une interface de programmation qui suit les règles imposées par l’architecture REST. Ces APIs exposent des ressources à des URLs spécifiques appelés les endpoints.


Ce type d’API, bien que très largement utilisé, comporte certaines limites. Nous pouvons notamment citer les problématiques :

  • d’over-fetching : signifie le fait de retourner au client plus de données que ce dont il a réellement besoin
  • d’under-fetching : signifie l'inverse, ne pas avoir suffisamment de données lors de l'appel API

Ces dernières prennent de l’ampleur dans des contextes de connectivité faible, par exemple lors du développement d’applications mobiles, où l'utilisation efficiente de la bande passante est capitale.

GraphQL à la rescousse

Malgré le fait que son nom puisse évoquer à certains les bases de données orientées graphes, il s’agit en réalité d’une technologie qui permet de développer des APIs Web modernes et d’encadrer les interactions avec ces dernières.


La fonctionnalité principale qui différencie une API GraphQL est le fait que le client qui consomme l’API spécifie au serveur les informations dont il a besoin. Le client compose la requête en fonction de son contexte et reçoit en retour uniquement les données qu’il a demandé : les problématiques d’over et d’under-fetching sont donc résolues nativement.

Le développeur n’a pas à créer de nouveaux endpoints afin de fournir une ressource correspondant aux besoins du client de l’API. Il est donc libéré du compromis qui oppose la conformité de la ressource au nombre d’endpoints de l’API.

Le schéma, la structure de l’API

Le schéma d’une API GraphQL est une description des actions et des données avec lesquelles le client de cette API pourra interagir. Fortement typé, il sera transmis au client.


Chaque Query ou Mutation, correspondants respectivement aux opérations de lecture et d’écriture spécifiées dans le schéma, possède donc un type de retour déterminé. C’est cette transparence et son typage fort qui permettent au client de connaître les informations qui peuvent lui être retournées et d’en sélectionner uniquement les fragments nécessaires.


La possession du schéma par le client va également permettre une validation de la requête côté client, et ainsi éviter un aller-retour infructueux.

Enfin, dernier avantage, le schéma pourra faire office de documentation de l’API, évitant ainsi aux développeurs d’avoir à rédiger et maintenir un document à côté de celle-ci.

Les resolvers

Si le schéma correspond à la spécification de notre API, les resolvers eux, constituent son implémentation. Concrètement, il s’agit des morceaux de codes chargés de récupérer et traiter la donnée demandée. Cette récupération va pouvoir s’effectuer depuis plusieurs sources, que ce soit depuis une base de données ou bien d’autres APIs.


Lorsqu’une requête GraphQL sera traitée, plusieurs resolvers seront potentiellement amenés à récupérer individuellement de la donnée, avant que ces données soient agrégées afin de constituer la réponse finale.


Certains resolvers pourront être chargés de résoudre une opération au complet ou uniquement une certaine propriété. Cette finesse de traitement et le fait qu’ils soient indépendants permettent une forte maintenabilité et évolutivité de l’API.

Flexibilité et résolution de problématiques

Technologie implémentée et disponible dans de nombreux langages, GraphQL permet de développer des APIs modernes aux nombreux avantages. La résolution native de problématiques que l’on peut retrouver avec des APIs REST classiques permet de libérer les développeurs de ces contraintes récurrentes.


De plus, sa flexibilité permet de développer des APIs évolutives, que l’on pourra plus facilement mettre à l’échelle. Parmi les autres fonctionnalités utiles, nous pouvons citer les subscriptions permettant de récupérer aisément de la donnée en temps réel.


Il n’est pas évident de trouver des inconvénients à l’utilisation de ce type d’API, le principal désavantage se situant au niveau de la gestion du cache. Chaque requête étant potentiellement différente, la mutualisation de ces données dans le cache est légèrement plus complexe qu’avec une API REST. Ceci est principalement dû au fait que le client compose cette requête en fonction de son besoin.

Déjà une référence sur le marché

C’est l’ensemble des avantages cités précédemment qui pousse les entreprises à adopter progressivement GraphQL et parfois même à remplacer leurs APIs REST traditionnelles. C'est le cas pour Gitlab qui prévoit une transition.

Cependant cette adoption reste relativement lente. Les promesses de cette technologie sont-elles suffisamment alléchantes pour renverser le géant REST et s’imposer en tant que nouveau standard ?


Il m’est difficile de répondre par la négative à cette question tant les avantages d’utiliser GraphQL sont nombreux.

Une autre question se pose alors : Quel est le frein à l’adoption de la technologie ? Simplement le manque de résonance du sujet ? Ou bien le manque de maturité de celle-ci ?


Concernant la maturité, son utilisation par des entreprises comme Spotify ou Twitter devrait suffire à rassurer les plus inquiets et ainsi renforcer son poids sur le marché. La technologie GraphQL se développe, devient de plus en plus populaire, continue de gagner du terrain face à ses concurrents et devient l'une des références dans le domaine.



Léo,

Expert technique