GraphQL

Article écrit par Nadir Si mohammed

GraphQL est un langage de requête pour les APIs qui offre une solution flexible et performante pour la gestion des données. Avec GraphQL, vous pouvez définir précisément les données dont vous avez besoin et obtenir uniquement celles-ci, évitant ainsi le problème d’overfetching ou d’underfetching rencontrés dans les API REST traditionnelles. De plus, GraphQL permet une meilleure collaboration entre les développeurs front-end et back-end en standardisant les échanges de données.

Sommaire :

• Commençons par faire un état des lieux
• Un peu d’histoire
• GraphQL c’est quoi ?
• L’objectif de la présentation
• GraphQL comment ça marche ?
• Les points négatifs
• Faisons le point

Commençons par faire un état des lieux

Lorsque nous évoquons les API (Interfaces de Programmation d’Applications) dans un projet web/mobile, REST est souvent le premier à venir à l’esprit. C’est en effet devenu une norme et presque une exigence pour tout développement impliquant un back-end, grâce à son architecture qui a vu le jour au début des années 2000.

REST API est l’abréviation de Representational state Transfer Application programme Interface. Comme son nom l’indique, c’est une interface/un style architectural qui permet aux différentes applications de communiquer en effectuant des requêtes (appels) sur un réseau ou sur une même machine. Dans la plupart des cas, les développeurs utilisent les API REST pour créer des services web.

Dans l’architecture REST, le client est tenu de se conformer aux endpoints existants côté serveur pour récupérer les ressources. Cela implique de faire plusieurs requêtes sur les endpoints pour récupérer la totalité des données, ce que nous appelons UNDER-FETCHING/OVER-FETCHING.

Un peu d’histoire

En 2012, l’utilisation de la téléphonie mobile a atteint son apogée avec la vente de plus de 2 milliards de téléphones portables à travers le monde. Cette invasion a mis en péril les entreprises qui n’ont pas adapté leurs produits, menaçant de les faire perdre une grande part de leur part de marché. C’est ce qui s’est produit pour Facebook à ce moment-là.

Facebook est spécialisé dans le web, ils ont donc conçu leur application iOS en utilisant une web-view. Toutefois, ils ont rapidement constaté que les limitations de leurs services ne leur permettaient pas d’être à la pointe de la technologie. Ils ont alors décidé de revoir entièrement leur site web en le migrant vers du natif afin d’offrir une expérience user friendly et performante.

Toutefois, l’architecture classique reposant sur des API REST posait de grosses difficultés : manque de souplesse, temps de réponses longs en raison de nombreux allers-retours pour obtenir les données, surtout si la communication est peu performante. Ils ont dû faire face à des problèmes d’OVER-FETCHING (une partie du payload n’est pas nécessaire pour la plupart des requêtes) et notamment, gérer autant de requêtes HTTP est fastidieux, surtout avec des applications mobiles (bande passante, etc.).

GraphQL c’est quoi ?

Le prototype original de GraphQL a été créé en 2012 pour répondre aux besoins de l’application iOS de Facebook. Lors de la création d’une application mobile, la consommation de données est un facteur important à prendre en compte. Parmi les défis les plus importants dans le développement d’applications mobiles, il y a la nécessité de garantir un fonctionnement adéquat avec tous les types de réseaux (4G, 3G, etc.). Une application peut rencontrer une faible bande passante en tout temps (utilisateurs isolés, transport en commun) et doit toujours être affichée avec le minimum de ressources.

L’objectif de GraphQL était de créer une API efficace pour les applications mobiles en permettant un appel unique qui regroupe toutes les informations nécessaires, évitant ainsi plusieurs requêtes.

Cependant, les requêtes GraphQL peuvent être plus lentes unitairement que les requêtes REST du fait de plus nombreux traitements en jeux pour délivrer les données.

L’objectif de la présentation

GraphQL est paru dans les tendances à suivre de 2018 en se basant sur l’étude de l’écosystème de Github en juin de cette année.

En 2020, j’ai eu l’opportunité de l’intégrer dans un back-end NodeJS pour un projet universitaire et dans un back-end Scala pour une entreprise.

L’objectif de cet article n’est pas de détailler tous les concepts de GraphQL ni de parler du côté technique, car il existe déjà une abondante documentation facile à trouver en effectuant une simple recherche en ligne.

Cependant, je souhaiterais aborder la question “Pourquoi devrions-nous inclure GraphQL dans notre boîte à outils de développeur ? ”

GraphQL comment ça marche ?

GraphQL est un système de requêtes pour API basé sur un modèle client-serveur, qui comprend un langage de requêtes fortement typé et un environnement d’exécution pour traiter ces requêtes.

GraphQL permet un traitement simple, flexible et très précis des données. GraphQL n’est ni un langage de programmation, ni un framework, c’est une spécification pour implémenter des API.

“QL” se réfère à Query Language, ce qui signifie langage de requête, tandis que “Graph” représente la vue côté consommateur de l’API et n’a rien à voir avec les bases de données orientées graphe. En réponse à une API, nous obtenons un ou plusieurs objets avec une racine qui nous permet de naviguer dans la réponse (structure arborescente ou graphique).

Avec GraphQL, une seule requête est nécessaire pour obtenir l’ensemble du playload, contrairement aux API REST définies par plusieurs endpoints. GraphQL vous permet de définir dynamiquement l’objet reçu côté client au lieu d’adapter un objet défini côté serveur. Cela change tout et peut sembler magique.

Après réception de la requête côté serveur et vérification de la syntaxe et du schéma, les resolvers de GraphQL attribuent une fonction de l’API (traitement de données, récupération de la base de données, logique métier, etc.) à une requête ou une action spécifiée dans les objets du schéma global (Query : récupération de données et Mutation : modification de données). À ce niveau de l’architecture, nous relions les paramètres d’entrée des requêtes aux arguments des fonctions de l’API.

Points négatifs ?

Lorsque nous comparons un temps d’exécution de 40ms à celui de 200ms sur des API REST, nous constatons que le temps de réponse serveur est amorti dès 5 appels. Cependant, lorsque le temps de transport des données est 10 fois plus élevé (+1000ms, passant de 1040ms à 1200ms), ce temps devient négligeable et il est alors préférable d’utiliser un seul appel.

Les API GraphQL permettent une personnalisation des champs, de l’ordre et des combinaisons d’objets et de sous-objets. Cependant, cela rend la mise en cache sur le serveur difficile car les requêtes et les réponses sont uniques pour chaque client. Pour contourner ce défi, il est possible de mettre en place un cache Etag pour chaque requête, mais cette solution a des limites car les consommateurs doivent formuler les mêmes requêtes.

Facebook offre un outil de bashing et de mise en cache, Dataloader, qui regroupe les données répétitives d’une requête pour n’interroger le serveur qu’une seule fois pour chaque donnée. Cela permet de gagner du temps lors de requêtes importantes et fréquentes.

Faisons le point :

GraphQL n’est pas la réponse à tout et encore moins un remplaçant à REST. Au contraire, il s’agit d’un outil complémentaire dans notre boîte à outils de développement d’API.

• Optimisation des données réseaux (récupération des informations en un seul appel)
• Idéal pour des consommateurs avec un réseau faible
• Optimisation des requêtes (le pouvoir est donné au client)
• Résolution des problématiques d’over fetching / under fetching
• Cache (plus complexe, plutôt applicatif)
• Fonctionnement des mutations en RPC (une mutation par action)

Vous vous demandez qui est Ouidou ? N’hésitez pas à nous contacter via contact@ouidou.fr ou visiter notre site https://ouidou.fr