Rest ou GraphQL ?

That is the question …

REST. A vrai dire, j’ai toujours considéré qu’il s’agissait d’un standard incontournable qui répond très bien aux problématiques d’architecture actuelles. J’ai néanmoins été plusieurs fois confronté à ses limites et depuis plusieurs mois j’entends souvent parler de GraphQL comme un successeur qui pourrait combler certaines des lacunes de REST. La présentation “GraphQL, l’avenir du REST” donnée par François Zaninotto, lors de la conférence Blend Web Mix 2017 à Lyon, a été pour moi l’occasion d’en apprendre un peu plus sur cette technologie. Voici un résumé de ce que j’en ai retenu.

L’hégémonie de REST

Les applications de type SPA (Simple Page Application) et les architectures centrées API sont aujourd’hui la norme et dans ce domaine REST est LE standard. Ce succès, REST le doit à sa simplicité et son efficacité. Cinq verbes http : GET, POST, PUT, PATCH et DELETE, pour les quatre opérations de persistance (Create, Read, Update, Delete) nécessaires à la communication entre client et serveur. Mais bien qu’universellement adopté par le Web, REST n’est pas exempt de défauts.

Les limites de REST

Le premier problème souvent rencontré avec les API REST, c’est la taille importante de certaines réponses du serveur. Lorsqu’on souhaite récupérer une ressource en particulier, le serveur renvoie tout le détail de celle-ci. Par exemple, si l’on demande les informations concernant un utilisateur simplement pour afficher son nom et prénom, le serveur nous renvoie aussi sa date de naissance, son adresse, son téléphone, … C’est gênant côté front parce qu’on se retrouve avec des informations superflues mais surtout cela engendre parfois des réponses serveur avec un gros volume de données et donc un temps de transfert plus long qui dégrade l’expérience utilisateur (surtout dans le cas d’une application mobile avec une connexion à faible débit). On appelle cela l’over-fetching.

Le second problème, c’est que bien souvent, pour les besoins de l’application, le développeur Front doit récupérer des ressources hétérogènes et se retrouve vite à faire une multitude de requêtes (parfois indépendantes et non parallélisables) et croiser ensuite les résultats pour parvenir à l’affichage final souhaité. C’est particulièrement le cas pour une application avec un modèle de données complexes. Dans ce cas là, on parle d’under-fetching.

Pour pallier ce genre de problèmes, le développeur Front doit alors se retourner vers les développeurs Back de l’API pour demander des points d’entrées spécifiques à certains cas d’utilisation. Cela engendre alors des coûts de développement et de maintenance supplémentaires et complexifie le processus de développement.

GraphQL et ses bénéfices

GraphQL est une technologie développée en interne chez Facebook depuis 2012 et devenue publique en 2015. Contrairement à une API REST, une API développée selon la spécification GraphQL n’a qu’un seul point d’entrée (de type POST). Les données ne sont plus vues comme des ressources indépendantes accessibles via des points d’entrées différents mais sous forme de graphe.
Le schéma qui décrit ces données sert alors de contrat (et de documentation) entre le client et le serveur. Le langage de définition de ce schéma utilise un typage fort permettant une meilleure gestion des erreurs et donc tester et valider plus facilement ses requêtes. A ce titre, l’interface graphique GraphiQL constitue un outil indispensable pour explorer et tester les requêtes envoyées à l’API.

Le client est alors en mesure d’écrire une requête (dans un langage qui ressemble fort à du JSON) lui permettant de récupérer, avec un seul appel, les données précises dont il a besoin. Cela résout les problèmes d’over-fetching et under-fetching rencontrés avec une API REST. L’approche flexible de GraphQL constitue un avantage majeur dans le processus de développement, le Front n’ayant plus besoin de demander de points d’entrées spécifiques pour les besoins de l’interface graphique de l’application.

Côté serveur, pour chaque type de données accessibles via l’API, une fonction resolver sera implémentée pour interroger la base de données (ou une autre source de données comme une autre API, car les resolvers peuvent être asynchrones !) et produire la réponse. A noter que GraphQL est une spécification et que son implémentation a été portée dans les principaux langages serveurs : Java, NodeJS, Python, …

Les inconvénients de GraphQL

Bien que GraphQL semble une solution idéale, François Zaninotto a souligné le fait que celle-ci peut s’avérer complexe à mettre en œuvre et que de par sa jeunesse, celle-ci présente encore des incertitudes et risques non-négligeables.

Ainsi, les problèmes liés à la sécurité et à l’optimisation de l’API paraissent complexes. En effet, la grande flexibilité de GraphQL présente un certains revers car n’importe quel client d’une API publique est alors en mesure d’adresser des requêtes extrêmement complexes qui prendraient beaucoup de temps pour être résolues. Le risque que des utilisateurs malintentionnés tentent de faire tomber le serveur en l’inondant de requêtes (attaques DOS) semble encore plus important qu’avec une API REST. Il semble bien que des solutions soient proposées par GraphQL mais malheureusement le temps imparti n’a pas permis à François Zaninotto d’aborder ce sujet plus en détails…

L’avenir de REST ?

Une série de questions a ensuite été soumises à l’audience, celles-ci devant permettre de déterminer si GraphQL constitue vraiment un meilleur choix que REST en fonction des problématiques métiers de chacun. Car même si REST vieillit et connaît certaines limites, sa maturité et sa simplicité en font toujours une très bonne solution aux besoins applicatifs. Il semble donc qu’on puisse dire que même si GraphQL semble très prometteur, il n’a pas encore enterré REST !

François Zaninotto a publié une série d’articles très détaillés, à lire absolument si vous souhaitez en savoir plus sur GraphQL : https://marmelab.com/blog/2017/09/03/dive-into-graphql.html

Maxime Chasles, Développeur ReactJS