Qu’est-ce que GraphQL ?

Dans cet article, nous discutons de tout ce qui se passe avec GraphQL et de la manière dont la technologie peut transformer la façon dont votre entreprise crée des applications Web.

Je pourrais simplement vous dire que c’était un langage informatique conçu par Facebook, et je ne mentirais pas, mais vous pourriez en savoir tout autant en lisant sa page Wikipedia. Pour comprendre l’importance de GraphQL, il est essentiel de l’examiner dans le bon contexte.

À mesure que les applications sur lesquelles nous nous appuyons deviennent de plus en plus complexes, le désir de séparer leur fonctionnement de leur apparence se renforce. Il y a des années, et je veux dire il y a des années (dans les années 1990), il était courant que chaque plate-forme prenne soin de son backend et rende également toute son interface visible par l’utilisateur. C’était la solution la plus simple, même si la personnalisation est rapidement devenue un défi. Modifier l’apparence directement dans le code signifiait que l’application ne pouvait plus être facilement mise à niveau, de sorte que diverses solutions de création de modèles ont été conçues.

Certains systèmes ont opté pour des modèles à écrire dans le même langage de programmation que celui utilisé par la plate-forme environnante. C’est ainsi que fonctionnent les systèmes basés sur WordPress à ce jour, le modèle étant la boucle logique principale. Il mélange le code responsable du dessin de l’interface utilisateur (HTML) avec une logique qui récupère les données de la base de données et exécute tous les plugins requis.

D’autres ont choisi d’utiliser des langages spécifiques au domaine (langages spéciaux créés pour résoudre un problème particulier) pour décrire les regards, la plateforme les interpréterait ensuite lors du rendu d’une réponse. Il y a de fortes chances que c’est ainsi que votre boutique basée sur Magento est conçue aujourd’hui.

La première approche présente l’inconvénient que les programmeurs qui modifient le modèle doivent être des développeurs full-stack, avec une bonne compréhension à la fois de la logique du backend (y compris sa langue de choix) et des langages utilisés pour construire l’interface (par exemple HTML, CSS , JavaScript). Comme le modèle lui-même agit comme la boucle logique principale, il affecte par inadvertance la logique métier, tandis que la modification de l’apparence devient un risque que vous devez tester spécifiquement. La page peut ressembler à ce qu’elle devrait, mais que se passe-t-il si le programmeur oublie d’inclure l’appel à votre service fiscal?

Cette dernière approche signifie que vos ingénieurs frontend devraient probablement apprendre une nouvelle langue et qu’une grande partie de leurs connaissances sera spécifique à la plate-forme elle-même. Alors que briser la logique métier devient beaucoup plus difficile, à un moment donné, votre organisation commence à embaucher des développeurs de thèmes Magento au lieu d’ingénieurs frontend. Les vastes connaissances d’un candidat potentiel sur les cadres frontaux modernes ne seront pas pertinentes à moins qu’il n’apprenne à créer un thème pour la plate-forme.

Pour que deux logiciels puissent se parler, ils doivent savoir comment échanger des informations et comment interpréter les données que l’autre partie pourrait choisir de transmettre. Il existe des normes qui décrivent des cas d’utilisation, des langages et des protocoles particuliers qui dictent la façon dont les programmes se parlent.

Habituellement, la partie avec une adresse établie est appelée le serveur et la partie qui s’y connecte est appelée le client. Pour que la communication commence, le client doit tendre la main (se connecter) au serveur. Pensez-y comme un client affamé entrant dans un restaurant; il n’y a tout simplement aucun moyen pour un serveur de savoir où se trouvent toutes les personnes affamées de la ville.

Une norme de communication destinée à une consommation programmatique est appelée une interface de programmation d’application (une API) et une adresse d’un serveur mettant en œuvre ladite norme est appelée un point final d’API. Lorsqu’un navigateur Web se connecte à un serveur Web, il utilise son API HTTP (Hypertext Transfer Protocol qui alimente le Web) en se connectant à son point de terminaison HTTP situé à l’adresse que vous avez fournie dans la barre d’adresse.

Les deux solutions de modélisation mentionnées ont leurs limites individuelles au-delà de celles énumérées ci-dessus, mais le défaut le plus flagrant est qu’elles ont été développées à une époque où tout était rendu par le serveur. Si chaque action de l’utilisateur effectue un aller-retour vers le serveur, il n’y a aucun moyen de prendre en charge le mode hors ligne. Si chaque interaction nécessite de redessiner la page entière, comment mettre en œuvre une recherche en direct dans un catalogue de cinq millions de produits?

C’est ainsi que nous sommes arrivés à des solutions hybrides où la plupart de la mise en page serait rendue par le serveur, mais une autre méthode – asynchrone – permet à l’interface utilisateur d’extraire des données supplémentaires si nécessaire. C’est là que AJAX (JavaScript asynchrone et XML) est apparu pour la première fois. Alors qu’AJAX était plus un concept qu’un standard, il proposait un moyen de récupérer des extraits de code HTML (ou XML si vous insistiez pour rester fidèle à son nom) puis de les ajouter à la page qui était déjà rendue.

AJAX a rendu possible la mise en œuvre de nouveaux types d’éléments de site Web, mais comme il n’y avait pas de méthode standardisée pour le faire, les développeurs de différentes entreprises (et parfois de différentes pièces dans le même bureau) avaient des opinions très différentes sur la façon dont tout devrait fonctionner. Finalement, la communication de serveur à serveur a été largement normalisée autour d’une spécification nommée Simple Object Access Protocol (SOAP), tandis que la communication de navigateur à serveur a choisi le transfert d’état de représentation (REST).

SOAP et REST utilisent chacun une approche très différente de la conception d’interface.

SOAP est un mécanisme d’appel de procédure à distance (RPC). Il propose une liste d’opérations prédéfinies; les « procédures », chaque procédure acceptant un nombre prédéfini de paramètres et renvoyant un certain nombre de valeurs nommées de types prédéfinis. Une procédure d’addition hypothétique peut accepter deux paramètres, a et b, de type number et renvoyer une seule valeur nommée sum, également de type number.

REST est une API tournant autour des ressources. Chaque ressource représente soit une seule entité, soit une collection d’entités d’un type particulier. Chaque ressource prend en charge un certain nombre d’opérations qui peuvent être : créées, lues, mises à jour et supprimées. Une collection de ressources de livres hypothétiques pourrait contenir une seule ressource représentant  Le Petit Prince  d’Antoine de Saint-Exupéry. Nous pourrions ensuite le mettre à jour avec l’année de publication, un numéro international normalisé du livre, et plus tard demander à la ressource de nous renvoyer les informations.

Construire des interfaces dynamiques avec AJAX était une douleur. C’était parce que le code pour dessiner les mêmes parties de l’interface utilisateur devait vivre à la fois du côté serveur et du côté client ; la première version serait générée par le serveur et envoyée au navigateur. Ensuite, lorsque l’utilisateur interagit avec la page, certaines parties doivent être redessinées par le code JavaScript exécuté dans le navigateur. Chaque fois que des modifications visuelles étaient apportées, elles devaient être effectuées aux deux endroits, ce qui nécessitait potentiellement différents types de talents pour chaque partie. Ce n’est guère une solution idéale. Ces dernières années ont donné naissance à un nouveau type de frameworks frontaux, ceux où toute l’application est rendue par JavaScript dans le navigateur. Le serveur n’a plus besoin de préparer la version initiale de la page en tant qu’applications dites monopage (SPA).

Les applications écrites en React, Vue.js ou Angular n’utilisent aucune solution de modèle obsolète implémentée par le serveur. L’architecture des serveurs headless (car les serveurs n’ont plus d’interface utilisateur) avec des clients riches permet aux ingénieurs frontend de construire toute l’expérience utilisateur en utilisant des technologies qu’ils connaissent et dans les langues de leur choix. La mise à jour du texte sur votre page à propos ne nécessite plus un développeur backend, mais comme tout devient piloté par l’API, les choix d’architecture derrière l’API deviennent le facteur limitant des performances de l’équipe.

SOAP a bien fait beaucoup de choses, mais ce faisant, il a exigé une représentation très complexe pour toute information transférée, ce qui a rendu difficile le travail des programmeurs JavaScript. L’insistance de REST à traiter les états d’objet plutôt que les transitions d’état signifie qu’il n’y a pas de moyen évident de représenter des concepts abstraits qui ne correspondent pas directement à des objets tangibles.

Pour comprendre les limites de REST, imaginez une API représentant les pommes que je détiens. Chaque fois qu’un de mes amis utilise l’application pour réclamer une de mes pommes, je souhaite diminuer le nombre de pommes disponibles.

Une solution naïve serait d’introduire une ressource «moi» avec un champ contenant le nombre actuel de pommes à portée de main. Cependant, comme la lecture et l’écriture sont des opérations distinctes, il n’y a pas de moyen sûr de diminuer le nombre de un sans risquer ce qu’on appelle une condition de concurrence: le cas où deux clients lisent une valeur puis tentent tous les deux de la modifier les actions des autres. En supposant qu’il y ait 5 pommes pour commencer, les deux clients liraient le numéro 5 puis publieraient une mise à jour, les deux définissant le nombre sur 4.

En réalité, vous devez contourner ce problème en introduisant une ressource explicite pour chaque pomme ou une ressource pour chaque acte de prise d’une pomme, même si ce dernier est un concept abstrait qui ne représente pas un objet tangible. Si vous essayez d’implémenter l’exemple de procédure d’addition hypothétique donné précédemment, vous rencontrez des problèmes similaires. La logique d’application du monde réel regorge d’opérations atomiques et de transitions d’états où le client ne peut tout simplement pas être fiable pour déterminer l’état résultant, soit en raison de conditions de concurrence possibles, soit en raison de contraintes commerciales ou même juridiques, et c’est là que – malheureusement – le mantra de création / lecture / mise à jour / suppression de REST tombe à plat.

Il existe une autre limitation commune à REST et SOAP. Nous avons célébré le fait que les applications monopage signifient ne plus avoir à mettre à jour le serveur chaque fois que le client est modifié. Cependant, comme l’ensemble exact des champs renvoyés par le serveur est contrôlé par le serveur lui-même, lorsque nous avons besoin d’afficher des données supplémentaires, nous sommes confrontés à un choix à faire: soit modifier le serveur pour envoyer plus de champs, soit émettre une requête supplémentaire au serveur. Un serveur renvoyant plus de champs pourrait signifier que dans les cas les plus courants, nous envoyons des données qui ne sont pas immédiatement utiles pour le client et nous gaspillons de la bande passante réseau. C’est ce qu’on appelle la surextraction. Forcer le client à établir une connexion supplémentaire au serveur dans les rares cas où plus de données sont nécessaires signifie un temps d’attente plus long pour l’utilisateur final car chaque connexion est un coût que nous payons en latence du réseau (le temps nécessaire pour que les données atteignent le serveur et retour). C’est appelé sous-extraction .

Enfin, nous sommes prêts à comprendre ce qu’est vraiment GraphQL . En bref, c’est un langage informatique conçu spécifiquement pour résoudre les problèmes d’un développeur Web moderne. Il s’agit également d’un ensemble de spécifications d’API qui décrivent comment parler GraphQL sur HTTP, le protocole utilisé par les applications Web.

Bien que GraphQL soit souvent comparé à REST, en réalité, il est beaucoup plus proche de SOAP. C’est un mécanisme RPC qui offre une collection d’opérations nommées (SOAP les appelle des procédures, alors que GraphQL a des requêtes, des mutations et des abonnements).

Contrairement à SOAP, il utilise un format de données simple pour représenter les objets. Pour cette raison, il est très simple à gérer dans le code JavaScript.

Contrairement à REST, il tourne autour d’opérations nommées au lieu de ressources. Cela facilite la mise en œuvre de scénarios qui ne correspondent pas à des objets tangibles ou qui opèrent sur plusieurs objets en même temps.

Contrairement à SOAP et REST, il exige que le client spécifie l’ensemble de champs (y compris les objets associés) qu’il attend en retour. Cela traite le problème de la sous-lecture et de la surextraction tout en maintenant la compatibilité ascendante.

Contrairement à REST, GraphQL est livré avec une interface d’introspection, ce qui signifie que les points de terminaison d’API sont auto-documentés. C’était un problème que SOAP a finalement résolu en distribuant des fichiers WSDL (Web Services Description Language), tandis que REST tente maladroitement de résoudre le même problème en générant des pages de documentation qui ne sont souvent ni utiles pour la lecture humaine ni adaptées aux ordinateurs. L’interface du mécanisme d’introspection a donné vie à un écosystème d’outillage riche comprenant des moyens automatisés pour détecter si le code du client fait référence à des zones d’API que le serveur considère comme obsolètes (avant leur suppression réelle).

Étant donné que GraphQL sépare sa spécification de protocole de ses spécifications de transport, il est possible pour une application d’utiliser le même moteur GraphQL à la fois pour résoudre les requêtes envoyées par les clients Web et pour exécuter des requêtes en interne au sein de l’application, devenant ainsi le mécanisme d’accès aux données unique pour tous. Logique métier.

Compte tenu de toutes ses avancées technologiques et de la norme désormais régie par sa propre Fondation GraphQL, opérant sous la Linux Foundation, ne permettez à personne de vous faire croire que GraphQL n’est rien de plus qu’une mode passagère, ou juste une hyperbole colportée par Facebook ingénieurs qui ne comprennent pas REST.

Librement traduit de l’anglais : article  saleor