L’écosystème de React
Caché derrière son blockbuster React (accompagné de Relay), GraphQL est une rafraichissante invention de Facebook permettant de manipuler un modèle de donnée en passant par un petit tuyau. Ciblant clairement les applications smartphones (webs ou natives), GraphQL remet à plat tout un tas d’habitudes et de cargo cult. D’abord utilisé comme arme secrète, il est maintenant libéré, spécifié avec une implémentation de référence (en nodejs) et d’autres implémentations (se basant sur des frameworks largement utilisés).
React fait le choix de franchement basculer un maximum d’intelligence du serveur vers le client, donnant sciemment le pouvoir à JavaScript, le vrai, celui dans le navigateur web.
Les échanges clients/serveurs
Malgré ses velléités d’autonomies, le HTML5 reste massivement utilisé comme une plaisante interface utilisateur connectée en HTTP à un serveur, qui va garder la main sur les données, et coordonner les interactions des multiples clients.
REST
Exposer une API REST est l’approche la plus neutre et la plus ouverte pour mettre à disposition des données et des fonctions via le protocole HTTP.
Par contre, implémenter avec ses petites mains un client à partir d’une API REST est chronophage, fragile, pénible à faire évoluer, douloureux à tester.
Modèle
Les données, côté client sont manipulées sous forme d’objets, mais il faut voir comment faire correspondre le modèle local avec le modèle distant.
Le choix d’utiliser le même langage, entre le client et le serveur, permet de partager le modèle. Il est possible de choisir JavaScript, comme le fait Meteor, ou pire, de choisir un langage tiers, qui sera compilé en JavaScript, client et serveur, comme OPA.
Une variante de cette approche est de garder son langage de prédilection pour le serveur et de ne générer que la partie cliente, comme le presque oublié GWT.
Plutôt que de partir d’un langage spécifique pour définir son modèle, il est plus sage de passer par une grammaire agnostique pour définir modèles et fonctions qui sera moulinée dans différents langages. C’est que propose Swagger (renommé il y a peu OpenAPI, surcouche à REST. Il existe aussi RAML, qui semble avoir moins de soutiens.
Il existe aussi des grammaires neutres, non REST mais pouvant utiliser HTTP comme couche transport, comme Thrift et Protobuff avec son grpc qui vient de sortir en version 1.0, mais lié à la toute nouvelle version 2 d’HTTP.
Toutes ces technologies permettent d’accéder à des données en clef/valeur, ou à des fonctions. Il faut donc implémenter une fonction côté serveur, qui sera utilisé côté client, avec du coup un aller-retour demandant des compétences distinctes.
Réseau et latences
Le premier ennemi des réseaux mobiles est la latence, bien avant le débit. Pour limiter les temps de latence, il faut limiter le nombre de requêtes. Pour pallier aux problèmes de débit, il ne faut rapatrier que le nécessaire pour afficher la réponse. Google, avec HTTP/2 (version normalisée de son SPDY), propose de multiplexer la connexion, sur un canal bidirectionnel qui reste ouvert, permettant ainsi d’envoyer les données sous une forme permettant de les utiliser au fur et à mesure.
GraphQL
Pour optimiser la communication réseau, Facebook se contente de reprendre la tactique du SQL : utiliser un langage concis permettant de sélectionner ce que l’on souhaite, et de préciser les objets et attributs attendus en réponse.
Ce langage de requête est le GraphQL.
La requête est en GraphQL, un nouveau format texte, mais la réponse est classiquement en JSON.
La ressemblance de GraphQL avec SQL est faible, et c’est une bonne nouvelle : il est clairement impensable de confier la rédaction de SQL au client web, de plus, le modèle relationnel, intimement lié à SQL est loin d’être un modèle universel, déjà mis à mal par les ORM et le cache.
Le GraphQL permet de rapatrier une grappe d’objets, avec un peu de dynamisme, surtout pas d’effectuer des calculs sur des regroupements ou tout autres action complexes.
Modèle abstrait
Le GraphQL ne sera pas traité directement par une base de données. Il travaille sur un modèle abstrait et orienté graphe. Facebook est fasciné par les graphes, presque autant que Linkedin, et ça tombe bien, c’est un modèle que notre cerveau arrive bien à appréhender, mais qu’il est difficile d’implémenter autrement que tout en RAM.
L’abstraction du modèle laisse toute liberté aux choix d’implémentations. Des outils sont fournis pour exposer les objets d’un ORM s’appuyant sur le classique modèle relationnel, mais rien n’empêche d’utiliser d’autres modèles, fichier par exemple (MongoDB, Couchbase, Elasticsearch…), voir même les modèles hybrides que nous propose l’intégration de JSON dans Postgresql et plus récemment Mysql. Des outils tiers permettent de faire des serveurs GraphQL dans autre chose que du Javascript, et il faut reconnaitre que l’implémentation pour Python, Graphene, a une bonne tête.
Typage
GraphQL utilise du typage, qui permet de systématiser la validation, mais aussi de l’introspection.
Le typage permet de garantir la réponse attendue, mais il est suffisement souple pour permettre une évolution du serveur sans imposer la mise à jour du client. Fort pratique pour faire évoluer un service pour une nouvelle application sans pour autant casser une ancienne application utilisant le même service.
Il existe un éditeur en ligne, avec une interface sympathique, GraphiQL (notez le i, comme interactif).
Paramètres
Une simple astuce permet de révolutionner ce classique usage de graphes : les attributs acceptent des arguments nommés, il est donc possible d’ajouter du dynamisme (comme une recherche) ou plus simplement du paramétrage (comme une taille d’image).
GraphQL ne va pas utiliser le principe de REST, mais se contenter d’un seul point d’entrée HTTP, /graphql, mais va profiter de la session, avec donc une connaissance de l’utilisateur.
Mutations
Initialement conçu pour un accès lecture seul, GraphQL permet maintenant des mutations.
Requêter simplement
Avec GraphQL, le serveur se contente de gérer le modèle (avec la garantie de cohérence, les droits, la persistance), avec du code métier, des middlewares, tout ce genre de bonnes choses.
Le client pourra librement composer à partir de ces données.
Par dessus, vous pouvez ajouter Relay et React, pour profiter de l’écosystème officiel. Mais vous pouvez utiliser d’autres choses, sans même vous limiter à JavaScript (il suffit de savoir lire du JSON sur de l’HTTP).