Pourquoi choisir l’API GraphQL ?

Commençons notre discussion sur GraphQL en examinant les lacunes de l’API REST. Après tout, si l’API REST était parfaite, GraphQL n’aurait pas été nécessaire.

Défis inhérents à l’API REST

Au fil des années, il est devenu évident que REST présente des défis importants, et ces problèmes sont les suivants :

1. Structure d’entité fixe
2. Demander une réponse uniquement

Examinons donc ces questions, en commençant par…

1. Structure d’entité fixe

Cela implique que dans REST, le client n’a pas la possibilité de spécifier les parties spécifiques d’une entité qu’il souhaite récupérer. De plus, la structure de l’entité renvoyée est prédéterminée par le développeur back-end et ne peut pas être personnalisée pour chaque requête.

Comprenons avec un exemple :

Avec REST, il n’existe aucun mécanisme pour récupérer uniquement les champs requis, ce qui entraîne la récupération de l’intégralité de l’entité, amplifiant ainsi les temps de chargement et la latence du réseau. Cette inefficacité est souvent observée dans diverses organisations, incitant les développeurs à créer des types d’entités spécialisés adaptés à des requêtes spécifiques.

C’est donc l’un des problèmes de l’API REST : sa limitation à prendre en charge uniquement les structures d’entités fixes.

2. Demander une réponse uniquement

L’API REST adhère exclusivement au modèle demande-réponse. Ainsi, dans le scénario où il existe un client et un service, le service expose une API REST. Le client envoie une requête à cette API REST et reçoit ensuite une réponse, adhérant au modèle requête-réponse. Néanmoins, les applications Web modernes nécessitent un éventail plus large de méthodes de communication client-serveur.

Comprenons avec un exemple :

Prenons le cas de Facebook : les notifications push sont de plus en plus précieuses et répandues. Pour adopter efficacement ce modèle, le modèle demande-réponse n’est pas adapté. En effet, notre objectif est de transmettre les données du service au client plutôt que de les récupérer dans le cadre d’une demande et d’une réponse. Essentiellement, nous avons besoin d’un mécanisme permettant au service d’envoyer des notifications au client.

Comment peut-on faire ça:

Nous pouvons y parvenir grâce à des méthodes telles que les sondages, où des requêtes périodiques sont envoyées au service pour vérifier les nouvelles notifications, ou en utilisant des protocoles plus avancés tels que WebSockets. Cependant, quelle que soit l’approche de mise en œuvre, l’intégration de cette fonctionnalité à l’API REST n’est pas inhérente au protocole et peut s’avérer complexe à mettre en œuvre.

Ainsi, la reconnaissance de ces deux problèmes a conduit à la prise de conscience qu’un nouveau type d’API était nécessaire pour les résoudre : la structure d’entité fixe et la limitation requête-réponse. C’est là que GraphQL entre en jeu.

API GraphQL :

GraphQL fonctionne principalement comme une spécification plutôt que comme une implémentation unique. Il décrit la structure des données renvoyées, fonctionnant au format JSON. Il englobe trois types d’opérations, s’appuie sur un schéma et offre une compatibilité multiplateforme. Passons donc en revue toutes les caractéristiques des API GraphQL.

spécification

GraphQL délimite la sémantique et les composants d’une API GraphQL sans fournir d’implémentations concrètes. Diverses entités développent des implémentations dans plusieurs langages, et la spécification complète de GraphQL peut être trouvée ici.

Définit une structure de données renvoyées

La caractéristique déterminante de GraphQL réside dans sa capacité à structurer les données renvoyées, ce qui constitue peut-être son avantage le plus important. Avec GraphQL, nous pouvons spécifier précisément les parties souhaitées d’une entité à renvoyer et même demander des entités associées dans le cadre de la requête. De plus, le filtrage peut être spécifié directement dans la requête. Cette fonctionnalité résout efficacement le problème des structures d’entités fixes, car GraphQL nous permet d’identifier les domaines d’intérêt spécifiques au sein du modèle de données.

Architecture de l’API GraphQL

Une API GraphQL est un outil robuste pour interagir avec les données stockées dans une base de données graphique. Contrairement aux API REST traditionnelles, GraphQL optimise la récupération des données en les modélisant en termes de nœuds et d’arêtes, représentant ainsi efficacement les objets et leurs relations. Cette conception permet aux développeurs d’effectuer plusieurs opérations sur différents nœuds en utilisant une seule requête HTTP.

Via les requêtes HTTP/HTTPS, chaque point de terminaison GraphQL est dédié à une opération spécifique (GET, POST, PUT, DELETE), rationalisant les interactions client avec la base de données. Les développeurs envoient des requêtes, encapsulant les données essentielles dans le corps de la requête ou les paramètres de requête, et reçoivent en réponse un code d’état HTTP/HTTPS approprié ainsi que les données demandées.

Par exemple, imaginez un serveur contenant des données sur les auteurs, les articles de blog et les commentaires. Dans un scénario d’API REST typique, un client peut devoir émettre trois requêtes distinctes (/posts/abc, /authors/xyz, /posts/abc/comments) pour récupérer des détails concernant un article de blog spécifique, son auteur et ses commentaires.

À l’inverse, une API GraphQL permet aux clients de faire une seule requête qui récupère simultanément les données des trois ressources. De plus, les clients peuvent spécifier les champs exacts dont ils ont besoin, offrant ainsi un contrôle accru sur la structure de la réponse. Cette efficacité et cette flexibilité sont des facteurs clés à l’origine de l’adoption croissante des API GraphQL dans le développement Web contemporain.

Les références:

1. GraphQL
2. Introduction à GraphQL.