A la découverte de GraphQL, le futur des API ?

A la découverte de GraphQL, le futur des API ?

Aujourd’hui, l’une des grandes tendances en développement web est d'utiliser JavaScript pour la construction de toute l'interface utilisateur, avec côté serveur, la mise à disposition d’une API pour ce code client Javascript. On nomme ce type d’architecture applicative : Single Page Application (SPA).

Cette architecture réduisant grandement les interactions client/serveur, c’est le code JavaScript qui va gérer l’affichage mais aussi les règles « métier » du site ainsi que le routage des URLs. Dès lors, l’interface utilisateur est beaucoup plus réactive, se rapprochant des applications natives. Aujourd‘hui, les frameworks JavaScript les plus courants sont Angular, React, Vue.

Les applications web fonctionnent alors comme des applications mobiles, concentrant les requêtes sur les APIs comme sources uniques de données.

Les APIs sont aujourd’hui des services indispensables et nécessaires à toutes applications web ou mobiles qui se respectent. En effet, une Application Programmable Interface permet à tous serveurs, applications ou sites web d’intéragir avec d’autres services connectés en échangeant des données. Ces interfaces sont innombrables : je vous laisse juste parcourir les plus de 22 000 APIs référencées chez ProgrammableWeb, suivre le blog de API Evangelist ou encore participer aux conférences API Days à travers le monde.

API

D’un point de vue technique, les APIs ont bien évoluées depuis la naissance du web dans les années 90. Trois protocoles d’accès (manière de structurer et requêter un service) majeurs ont principalement marqué cette évolution : SOAP, REST et, enfin, le tout jeune GraphQL. Ils possèdent des similitudes, comme le fait qu’ils reposent sur le protocole de communication client-serveur HTTP.

SOAP puis REST

Pour faire quelques raccourcis, SOAP (Simple Object Access Protocol) est un ensemble plutôt rigide de modèles de requêtes. En effet, SOAP se base sur des règles qui permettent de normaliser fortement les échanges structurés au format XML.

https://www.seobility.net/en/wiki/REST_API

REST (REpresentational State Transfer), quant à lui, est naturellement plus souple, nécessitant peu ou pas de traitement. Nous ne pouvons pas nier que cela a plutôt bien fonctionné pendant un certain temps. Cependant, les applications et les services web devenant de plus en plus sophistiqués, les API ont naturellement évolué elles aussi.

Chaque ressource dans REST est représentée par un « endpoint » ou, en simplifiant, une URL. Ainsi, pour une application actuelle cela nécessite d’avoir beaucoup de « endpoints » pour beaucoup de ressources. Si vous voulez faire une requête GET (pour récupérer des données auprès d’un service), vous aurez besoin d’un « endpoint » spécifique à cette requête, incluant des paramètres également spécifiques. Si vous voulez faire une requête POST (pour envoyer des données), vous aurez besoin d’un autre « endpoints » pour cette requête.

Les problèmatiques de REST

La multiplicité de ces « endpoints » entraine une problématique de maintenance pour les développeurs. En effet, cela oblige à être très vigilants dans les moindres modifications de structure de ces APIs car cela pourrait entrainer un blocage du fonctionnement de ce service.

Un autre problème rencontré est la sur et la sous-consommation d’informations via ce type d’API. En effet, les API REST renvoient toujours une structure fixe. Nous ne pouvons pas obtenir exactement les données dont nous avons besoin, à moins de créer un « endpoint » spécifique pour cela.

Aussi, si nous n’avons besoin que d’une petite partie des données mises à disposition, nous devons travailler avec les données complètes fournies par la ressource de l’API. Par exemple, si nous n’avons besoin que du prénom, du nom et de l’âge d’un utilisateur dans une API REST, il n’y a aucun moyen d’obtenir uniquement ces données sans récupérer l’objet entier qui intégrera son adresse, son email etc.

https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/user-object

Il y a aussi le problème de sous-information. Si nous voulons obtenir des données à partir de deux ressources différentes, nous devons effectuer des appels différents vers deux « endpoints » différents. Dans une application incluant de nombreuses fonctionnalités, cela n’est pas très performant. Imaginons que nous construisions une application qui aura besoin de 100 ressources différentes pour répondre aux fonctionnalités souhaitées : la quantité de travail et de code que les développeurs devront écrire et maintenir dans le temps sera très importante et coûteuse. REST n’a pas la notion de champs, mais uniquement de ressources.

L’un des autres points contraignants des API REST est la création de versions. En effet, il est très courant de voir des API intégrant dans ses URLs l’information de version comme « v1 » ou « v2 » afin de garder une rétro-compatibilité avec les services utilisant telle ou telle version de l’API.

GraphQL, l’avenir du REST ? – François Zaninotto – Forum PHP 2017

REST n’est au final pas un standard mais un style d’architecture qui engendre à moyen/long terme de nombreuses difficultés.

On peut étendre REST, en ajoutant des paramètres de type « include » mais cela apporte de la complexité et n’est pas adapté aux architectures applicatives modernes. On pourrait penser à SQL : universel, déclaratif, facile à parser mais il reste très connoté base de données relationnelle. Google a proposé les « Protocol Buffers », format de sérialisation de la donnée avec un langage de description d’interface basé sur du RPC (comme SOAP).

Netflix a, de son côté, proposé une librairie client/serveur Open Source : Falcor, permettant d’échanger des structures de données complexes mais malheureusement sans typage fort et sans language de requête sophistiqué.

 

GraphQL, LA solution ?

En 2012, Facebook est confronté, lors du développement, de ses applications mobiles et APIs à ces problématiques :

  • Mauvaise performance ;
  • Beaucoup de « endpoints » ;
  • Sur ou sous-consommation de données ;
  • Envoi d’une nouvelle version chaque fois qu’il faut inclure ou retirer un élément ;
  • Difficulté à comprendre les APIs.

Avec ces difficultés en tête, les développeurs de Facebook ont conçu une nouvelle façon de concevoir les APIs : GraphQL. La terminologie apporte un peu de confusion car au-delà de QL pour Query Language, il n’est pas nécessaire d’avoir une base de Graph pour utiliser GraphQL. Cela fonctionne avec tout type de structure de données.

Avec GraphQL, nous levons les nombreuses problématiques soulevées lors de la création d’une API.

1 seul « endpoint »

Avec GraphQL, nous avons qu’un seul point d’entrée, une seule URL pour la requête à l’API. Grâce à cela, nous pouvons obtenir autant de données que nous voulons en une seule requête. GraphQL permet de centraliser et de regrouper toutes vos requêtes dans une seule URL. Cela améliore grandement votre cycle de développement car vous n’avez pas besoin de faire deux requêtes pour obtenir des données de deux ressources différentes.

L’un des points contraignant de REST, est la création de versions d’API. Avec les API REST, il est très courant d’avoir une évolution de l’API en introduisant la version attendue lors de la requête : v1 ou v2. Dans GraphQL, ce n’est pas nécessaire puisque vous pouvez faire évoluer vos API en ajoutant de nouveaux types ou en supprimant les anciens.

Dans GraphQL, tout ce que vous avez à faire pour faire évoluer votre API est d’écrire un nouveau code. Vous pouvez écrire de nouveaux types, requêtes et mutations sans avoir besoin de fournir une autre version de votre API.

Récupérer ce dont vous avez besoin

N’ayant plus qu’un seul « endpoint », il n’est plus nécessaire de requêter des ressources en cascade ou de récupérer des informations dont nous n’avons pas besoin. Vous ne récupérez que les données dont vous avez besoin. GraphQL améliore ainsi les performances de transaction vers votre API automatiquement en réduisant les requêtes et les données transmises (surtout en cas de connexion réseau lente).

Simplification et autonomie

L’approche de GraphQL peut paraître, pour beaucoup, assez complexe car cela implique l’utilisation d’un schéma avec paradoxalement un seul point d’entrée. Mais en réalité, c’est beaucoup plus simple : une API avec un seul point d’entrée optimise énormément la phase de conception d’un site web ou d’une application mobile ; votre API est plus autonome et agnostique, rendant la documentation plus légère. De plus, vous pouvez l’utiliser avec de nombreux langages de programmation.

 

Futur des APIs ?

Le fait que GraphQL soit un langage de requêtes Open Source signifie que la communauté peut y contribuer et y apporter des améliorations. Lorsque Facebook l’a mis à disposition de la communauté, cela a suscité beaucoup d’intérêt auprès des développeurs. Aujourd’hui, GraphQL connaît une croissance rapide, car de plus en plus de développeurs commencent à l’adopter dans leurs développements. Cependant, certains se demandent encore si cette méthode va vraiment remplacer REST ou devenir une façon complémentaire de créer des API pour des applications.

En novembre 2018, la Fondation GraphQL a été créée, en partenariat avec la Fondation Linux. Ce langage de requêtes encourage ses développeurs à créer plus de documentations, d’outils et de support. Cette fondation assure ainsi un avenir stable, neutre et durable à GraphQL. C’est donc une raison supplémentaire de considérer GraphQL comme l’avenir des APIs.

Bien sûr, rien de remplacera immédiatement REST car de nombreuses applications l’utilisent encore. Au fur et à mesure, de nombreux développeurs et entreprises adopteront GraphQL, améliorant ainsi l’ensemble des étapes de conception et développement de leurs applications web et mobiles.