GraphQL vs Falcor, le match !


Le 22 juin dernier se tenait la deuxième édition du Voxxed Day au Luxembourg. À l’occasion de cet événement IT destiné aux développeurs, on pouvait assister à de nombreuses conférences, dont une passionnante intitulée “GraphQL vs Falcor”, que nous allons décortiquer dans cet article.

Antoine Cellier et Hugo Wood, deux employés de la société Zenika, sont venus de Nantes pour nous présenter comment ces deux technologies peuvent nous aider à développer des applications Web plus rapidement.

C’est sous la forme d’une “battle” dans une ambiance bon enfant qu’ils nous ont présenté tout ça, en développant une application mobile de transport en commun avec REST, GraphQL et Falcor afin de comparer l’impact de ces technologies sur les propriétés du code et les coûts de développement.

La plupart des développeurs utilisent REST pour communiquer entre un client et un serveur. Par exemple, pour demander les données relatives à un arrêt sur un réseau de transport en commun au serveur, le client utilise cette requête :

GET /stations/COMM

(Avec “stations” et “COMM” qui représentent respectivement les arrêts et un identifiant d’arrêt.)

Le serveur lui renvoie alors, généralement en JSON, les données suivantes :

{
    id: /stations/COMM
    label: Commerce
    latitude: 47.2134
    longitude: -1.5563
}

Ici, c’est l’objet complet qui est retourné, il n’y a pas de contrôle sur la quantité de données retournée.

Avec GraphQL on utilise une fonction “station” à laquelle on passe un paramètre “COMM”, et on peut choisir quels champs on souhaite recevoir :

{
  station(id: COMM) {
    latitude
    longitude
  }
}

Cette requête retournera alors uniquement les données demandées dans la requête :

{
  station: {
    latitude: 47.2134
    longitude: -1.5563
  }
}

GraphQL est un nouveau langage pour écrire des requêtes. Il est développé et utilisé par Facebook depuis deux ans, notamment pour leurs applications mobiles. Il fournit une implémentation officielle côté serveur dans l’environnement NodeJS qui permet d’interpréter les requêtes et de donner une réponse.

Avec Falcor, on utilise du JSON, la syntaxe n’est donc pas la même, mais on peut également demander les champs qui nous intéressent :

[stations,
  COMM, [
    latitude,
    longitude
  ]
]

Le serveur répond alors avec les champs voulus :

stations: {
  COMM: {
    latitude: 47.2134
    longitude: -1.5563
  }
}

Falcor est une technologie développée par Netflix. C’est un dialecte JSON pour écrire des requêtes. Il y a une libraire côté serveur, comme pour GraphQL, pour que le serveur puisse interpréter les requêtes et trouver les données et les renvoyer. Là où Facebook ne fournit pas de librairie officielle côté client (mais dispose de librairies externes comme Apollo), Netflix en propose une en JavaScript.

Une architecture GraphQL ou Falcor se situe au même niveau qu’une architecture REST. C’est donc un middleware entre une application cliente et une source de données.

Pour ces deux technologies, c’est le client qui pilote et qui choisit quelles données il veut recevoir. On peut également choisir quelle relation on souhaite traverser. Grâce à cela, on peut faire une seule requête pour avoir l’intégralité des données nécessaires pour alimenter un écran.

Mais ces technologies diffèrent tout de même sur plusieurs points.

GraphQL est un nouveau langage qui utilise du typage statique, alors que Falcor utilise uniquement du JSON et le typage est dynamique. De ce fait, Falcor sera plus facile à intégrer et à utiliser.
GraphQL utilise l’introspection, ce qui facilite la génération de la documentation et l’autocomplétion. Mais Falcor possède un système de batching, qui permet de fusionner les requêtes clientes dans le cas d’une application cliente modulaire. Il y a également un cache côté client. De fait, seuls les champs manquants dans le cache sont demandés au serveur.

Contrairement à Falcor, GraphQL est déjà très utilisé et est mis en avant par Facebook. Il y a une meilleure adoption du langage par la communauté.

La suite de la conférence s’est déroulée sous forme d’un “fight” entre les deux outils, Antoine prenant part pour GraphQL et Hugo pour Falcor. De petites user stories étaient proposées et chacun expliquait comment répondre à la demande avec la technologie qu’il défendait en exposant les morceaux de code correspondant.

Pour la visualisation du code, les présentateurs ont utilisé un outil nommé “Raccord”, qu’ils ont développé ensemble, sur lequel on pouvait voir les requêtes GraphQL traduites en Falcor et inversement. Raccord permet également d’exécuter ces requêtes et de visualiser les résultats obtenus.

L’application à réaliser était une app Web de transport en commun.

Voici un exemple de user story proposée : “Je veux pouvoir rechercher les arrêts textuellement.”

Avec REST, nous écrivons cette requête de la façon suivante:

GET /stations?search=Cat

On cherche ici les arrêts contenant la chaîne “Cat”.

En premier lieu, Antoine a écrit le code GraphQL (deuxième colonne de l’image qui suit) qui a été interprété en Falcor (première colonne). Après exécution du code GraphQL, on obtient le résultat de la requête retournée par le serveur dans la troisième colonne de l’outil “Raccord”.

Raccord - GraphQL vs Falcor 1

Hugo a ensuite codé la partie Falcor (première colonne), qui a été interprétée en GraphQL dans la colonne suivante. L’exécution du code Falcor génère le code JSON de la dernière colonne.

Raccord - GraphQL vs Falcor 2

À travers une dizaine de user stories, nous avons pu voir les points communs et différences, les avantages et les inconvénients de REST, GraphQL et Falcor.

Nous en retenons que l’utilisation de l’une ou l’autre de ces technologies dépend avant tout du besoin que nous avons. Malgré un code plus verbeux et un support quasiment inexistant de la part de Netflix, Falcor reste une librairie très légère et tout à fait utilisable. L’écosystème plus développé de GraphQL et son autocomplétion sont très appréciables pour les développeurs. Ce n’est pas pour autant une victoire écrasante pour la tech de Facebook : malgré ses avantages, Antoine nous avouait à la fin de cette confrontation que GraphQL se cherche encore.

Cet article n’est qu’un résumé partiel de la conférence et je ne peux que vous encourager à la regarder dans son intégralité sur YouTube.

Vous aimerez aussi...