Découvrez comment faire collaborer vos prochaines applications client/serveur.

1. REST in peace avec
GraphQL
Fabian Vilers
Dev Day, 2017

2. Qui suis-je ?
Software Craftsman
.NET / ASP.NET / Node.js / Angular
React / Docker / …
Open Source Activist
Freelance for Dev One
Follow me on Twitter (@fvilers)
and LinkedIn

3. REST in peace avec
GraphQL

4. Est-ce un appel au meurtre ?
Non, GraphQL ne va pas « tuer » REST
Tout comme REST n’a pas tué SOAP
Oui, GraphQL apporte de la souplesse dans les interactions
Mais avec une plus grande flexibilité, vient un plus grand coût

5. Et il n’y a pas que moi qui l’affirme

6. Pourquoi GraphQL ?
GraphQL solutionne 3 principaux problèmes
Le besoin de faire plusieurs aller-retours entre le serveur et le client pour charger les
données d’une vue complexe
La dépendance des clients vis-à-vis du serveur
Le decalage entre l’expression declarative du client par rapport à la façon dont on récupère
les données

7. Qu’est-ce que GraphQL ?
Un langage déclaratif
Une fine couche de « traduction » côté serveur
Cette couche peut-être écrite dans n’importe quel langage
Expression d’une requête peut être de deux types
Query (lecture)
Mutation (écriture)
GraphQL n’est pas un moteur de stockage de données

8. N’importe quel langage, vraiment ?
C#/.NET
Clojure
Elixir
Erlang
Go
Groovy
Java
JavaScript
PHP
Phython
Scala
Ruby

9. N’importe quel langage, vraiment ?

10. Quels sont les bénéfices de GraphQL ?
Efficacité
Les requêtes multiples et complexes sont regroupées
La couche GraphQL peut jouer le rôle de façade pour récupérer les données de plusieurs
micro-services
Performance
Les résultats peuvent être mis en cache
GraphQL ne renvoie que les données demandées par le client

11. Qu’est-ce qui ne va pas avec REST ?
REST est orienté ressource, et implique de multiples terminaisons d’API
Donc, de multiples aller-retours entre client et serveur
REST n’offre pas de langage de requête
Impossible d’affiner la requête
Trop de données sont rapatriées
Encombrement de la réponse avec des métadonnées (pagination, tri, etc.)
REST n’est pas orienté multi versions
Une nouvelle version impliquera souvent de nouvelles terminaisons d’API

12. REST, ce n’est pas de tout repos

13. Comment la magie opère-t-elle ?
GraphQL, c’est un schéma fortement typé
Il est composé de champs et de types (primitifs et/ou complexes)
Il est accessible, ce qui permet l’introspection, la validation, et la génération d’outils ad hoc
GraphQL expose les données sous forme de graphe
Totalement indiqué pour récupérer des données hiérarchiques, ou liées sémantiquement
Les clients expriment leur besoin de manière déclarative
Ce qui les rapproche du langage naturel

14. Le coût de la flexibilité
Sensible aux attaques par déni de service
Avec des requêtes complexes et une structure imbriquée
Haute charge sur plusieurs micro-services
Solutions
Liste blanche
Délai de temporisation
Limiter la profondeur du graphe et le temps d’exécution

15. Le coût de la flexibilité
Caching
La nature flexible des query rend le caching plus complexe qu’avec REST
Solutions
Côté client, les librairies Relay, ou Apollo facilite la gestion de cette problématique
N+1 SQL
La nature du graphe peut impacter les performances serveur car le sous-requêtage sera
dissocié
Solutions
Côté serveur, la librairie DataLoader permet d’y palier en analysant la query, et en optimisant les
appels DB, et en cachant une partie des données

16. Démo !
https://github.com/fvilers/devday-graphql

17. Alors, c’est pas génial GraphQL ?

18. Merci !