GraphQL

Les API REST ont rempli de bons et loyaux services. Mais, les usages changent : on utilise de plus en plus souvent nos applications sur mobile, ce qui est souvent synonyme de mauvais réseau, de débit minime ou de latence énorme (je te regarde, cher métro)... Et, pour récupérer toutes les données souhaitées, REST nécessite potentiellement plusieurs requêtes, ce qui ne fait pas bon ménage.

Des... Solutions ?

Certaines solutions ont alors été mises en place : un paramètre GET en plus permettant de spécifier plus ou moins finement quels champs supplémentaires récupérer, ou alors des wrappers permettant de batcher des calls HTTP en une seule requête. Mais ces solutions ne sont pas flexibles, standardisées et mènent de toute façon toutes à de l'overfetching, puisque, la plupart du temps, nous n'utilisons pas toutes les données renvoyées par une API REST.

GraphQL in the place

Est alors arrivé, en 2015 GraphQL, un langage de requêtes créé par Facebook, permettant de spécifier exactement quelles données nous intéressent. Le langage est simple, les API sont auto-documentées à travers un schéma, l'écosystème se développe de plus en plus, et de grandes entreprises disposent maintenant d'API GraphQL.

J'ai eu l'occasion de créer plusieurs serveurs GraphQL, notamment grâce à Apollo Server et GraphQL Code Generator, pour le typage TypeScript. J'ai notamment mis en place, dans le cadre d'un PoC, une API GraphQL dans le cadre de mon travail à SharingCloud, pour remplacer les différentes API utilisées en production, qui n'étaient pas normalisées.

Ainsi, j'ai une connaissance intermédiaire des mécanismes de fonctionnement et d'implémentation de GraphQL. GraphQL représentant, je pense, l'avenir des API, j'aurais l'occasion de travailler sur d'autres projets où GraphQL prend une place importante, et je pourrais maîtriser GraphQL de façon plus efficace et précise.