GraphQL est basé sur une idée simple, déplacer l’assemblage d’une requête du serveur vers le client. Ce dernier voit l’ensemble du schéma fortement typé au lieu d’une multitude de services REST et construit la requête souhaitée en fonction de ses besoins.

Ma première application web en REST, SPAs pour Single Page Application comme cela fût appelé plus tard, remonte à 2005. A cette époque, les requêtes REST et les applications internet riches (RIA) étaient nommées AJAX et principalement utilisées pour transporter du XML. Ma première requête REST en JSON a été faite quelques mois plus tard. Cette expérience fût rafraichissante en comparaison de l’enfer XML utilisé à ce moment là! Plus besoin d’analyses inutiles, de schémas illisibles ou de pénible SOAP.

REST nous a bien servi et continuera à le faire longtemps. Cependant, dans certaines situations, il n’est pas optimal quand GraphQL peut s’avérer plus commode.

Les objectifs de GraphQL

Les données proviennent de sources multiples dans l’entreprise et différentes équipes les gèrent en tant que propriétaires et fournisseurs de données. Elles sont stockées dans des bases de données hétérogènes et situées sur plusieurs plateformes avec des politiques d’accès complexes.

Les Data Warehouses, Data Marts et Data Lakes exposent des ensembles de données avec leurs propres exigences et protocoles. Maintenir une gouvernance cohérente, définir des processus efficaces et s’assurer que les utilisateurs finaux exploitent les données disponibles dans l’entreprise est un défi.

GraphQL a pour objectif de fournir aux utilisateurs finaux des API auto-documentées, utilisant des données de toutes sources, pour créer des applications prêtes pour la production.

Les catalogues API

GraphQL fournit le manuel manquant lorsque de nouveaux entrants doivent acquérir du savoir sur les API de l’entreprise. Étant donné que le modèle de données est déclaré dans un schéma, il est facile d’y naviguer et d’en tirer des enseignements. Il permet aux développeurs front-end d’interagir avec différentes API sans connaître les détails d’intégration de chacune d’elles. Divers outils GraphQL fournissent une interface utilisateur Web pour éditer les requêtes avec une documentation d’API intégrée et des fonctionnalités d’auto-complétion pour la rédaction des requêtes.

La vitesse de développement

Le taux d’itération et de prototypage est beaucoup plus rapide qu’avec REST. Il n’est plus nécessaire de spécifier les exigences en matière de données côté serveur, telles que les champs à partir desquels les modèles doivent être récupérés et exposés. Avec GraphQL, vous définissez un schéma, il s’agit du modèle. Le schéma porte la connaissance des jeux de données ainsi que toutes les propriétés qu’ils comportent. La manière d’utiliser le schéma et de consommer leurs données est définie côté client. Cela change la façon d’interagir avec les données en libérant l’intégrateur.

Par exemple, si vous devez modifier une propriété manquante dans REST, vous devez modifier le code côté serveur et refléter ces modifications sur le client. Alors qu’avec GraphQL, vous déclarez une nouvelle propriété directement sur le client où les données sont toutes de suite utilisable. Les développeurs front-end n’ont pas besoin d’accéder au serveur, en supposant qu’ils y aient accès. Junior ou senior, tous se sent à l’aise pour utiliser les données disponibles. Liberté et la façilité induite par GraphQL donne un sentiment de puissance. Si un développeur oublie d’afficher un champ déjà disponible dans le modèle, il doit simplement mettre à jour son code client.

Robustesse de l’intégration

Les développeurs côté serveur bénéficient également de l’utilisation de GraphQL. Sur le serveur, de nombreuses données sont consultées, souvent de manière très similaire. Les enregistrements doivent être fusionnés ou enrichis pour répondre à des exigences de requêtes spécifiques et renvoyées sous forme de fichier JSON. Le même processus d’intégration est répété encore et encore pour chaque nouvelle exigence. Avec GraphQL, les données étant exprimées par un schéma, les développeurs côté serveur n’ont pas à passer par ce processus. Une fois votre schéma défini et la source des données déclarée, vous n’êtes plus concerné par la logique et vous n’avez plus de travail supplémentaire à faire.

Autre avantage, cela réduit la surface des applications à la fois en termes de bugs potentiels et de violations de la sécurité. En cas de problème, l’équipe peut examiner un emplacement, où le schéma est défini. Elle n’a pas à vérifier dans toutes les sources de base pour rechercher parmi plusieurs API REST susceptibles d’être affectées.

Garanties en refactoring

Les clients GraphQL analysent la requête de manière statique. L’avantage est la possibilité de configurer des règles de validation, “linting” en anglais, pour détecter une modification du schéma générant une erreur. Il permet aux équipes de reformuler leur requête GraphQL et de s’assurer qu’elle reflète le nouveau schéma. Par exemple, si vous souhaitez modifier le nom de la propriété afin de la rendre plus descriptive, vous pouvez la renommer, exécuter le “linter” et savoir exactement quelle requête va être dissociée et la corriger là où elle est utilisée. Il peut être associé à Flow (ou TypeScript) pour suivre tous les noms de variables en cours de modification

Bénéfices supplémentaires

GraphQL est livré avec plusieurs fonctionnalités telles que les abonnements, le contrôle d’accès, la surveillance ou la gestion des erreurs. Le serveur GraphQL peut fournir plusieurs services, incluant une couche de mise en cache, des règles d’autorisation et une traçabilité des accès. Il est également possible de fédérer plusieurs serveurs pour qu’ils agissent en tant que fournisseur de données avec point d’entrée unique. Des bibliothèques comme le client Appolo s’assurent que votre code est robuste en imposant à l’intégrateur la gestion des échecs.

Pas uniquement pour le web

GraphQL est agnostique en matière de transport et n’est pas lié à HTTP et JSON. Comme gRPC et Thrift, il peut sérialiser les données dans un format binaire et les transporter via des protocoles plus efficaces. Le langage de requête associé à un schéma dans le backend est la principale fonctionnalité et ne se restreint pas qu’aux applications Web. De nombreux utilisateurs dans les domaines du Big Data et de la Data Science bénéficieront de l’intégration des données exposées par GraphQL.

Considérations

Les personnes qui bénéficieront le plus de l’importation de GraphQL dans leur entreprise sont les grandes équipes, en particulier celles confrontées à des problèmes d’intégration. Les utilisateurs individuels tireront probablement peu avantage de l’utilisation de GraphQL par rapport aux requêtes REST dédiées.

À ce stade, la plupart des API GraphQL sont publiées en interne dans les entreprises mais ne sont pas encore exposées publiquement. GitHub l’a fait mais cela implique l’ajout de mécanismes pour assurer la sécurité et contrôler tout abus potentiel. Il permet aux gens d’écrire des requêtes semi-arbitraires sur des ensembles de données exposés. Par exemple, il est possible de définir des alertes lorsque les requêtes atteignent un certain seuil et sont considérées comme particulièrement lentes.