J’avais ça dans mes bookmarks. http://graphql.org/blog/
A noter un retour d’expérience dont on m’avait fait profiter il y a peu : GraphQL est excellent pour ce qu’on appelle du "back-for-front". C’est-à-dire une petite couche d’APIs destinée à des applications mobiles par exemple.
Aller coller du GraphQL directement sur un backend "lourd" (comprendre qui existe déjà, avec tout plein de sources de données, relationnelles ou non, etc.) ça devient vite un enfer à faire évoluer apparemment. En fait à travers GraphQL, le contrat d’exposition des données devient vite hyper fort et assez peu souple : en (très) gros : on expose un système de requêtage de sa BDD.
Du coup, les gens que j’ai croisés qui avaient bossé depuis quelques années déjà avec GraphQL, et en avait mis partout en revenait un peu, en disant que si c’était à refaire : leurs backends continueraient à exposer des ressources REST très "unitaires" (un path une ressource). Et ensuite, en "amont" en quelque sortes, ils continueraient à mettre une couche de GraphQL, qui potentiellement déclenche plusieurs appels REST pour reconstituer le schéma décrit par "contrat" avec les fronts (mobiles, web, etc.).
Bon après, c’était dans un domaine assez gros.