Falcor vs GraphQL : les différences clés

Que sont Falcor et GraphQL ?

Falcor est une bibliothèque JavaScript conçue « pour une extraction efficace des données ». Elle a été développée par Netflix pour soutenir sa plateforme de streaming vidéo avant que l’entreprise en fasse un projet open source en 2015. Grâce à Falcor, les développeurs peuvent représenter les données sous la forme d’un graphe JSON virtuel et unique, ce qui facilite la création et la maintenance d’applications web et mobiles complexes.

GraphQL, développé par Facebook en 2012 et libéré en 2015, est un langage de requête de type applicatif couplé à un moteur d’exécution. Le projet permet aux développeurs de définir la structure des données qu’ils interrogent auprès d’un serveur. Il permet également de récupérer efficacement des données à partir de sources multiples, ce qui rend les applications plus efficaces et plus sûres.

Falcor et GraphQL fournissent tous deux un moyen efficace d’interroger des données pour les applications mobiles et web. Ils présentent également des similitudes d’un point de vue opérationnel, puisqu’ils présentent tous deux les caractéristiques suivantes :

• Ils utilisent un langage ou une syntaxe de requêtes de type déclaratif.
• Ils nécessitent de déployer un seul point de terminaison, une API unique et unifiée pour toutes les requêtes.
• Ils assurent un contrôle granulaire des requêtes de données.
• Ils offrent la possibilité de regrouper plusieurs requêtes en une seule.

Les principales différences entre Falcor et GraphQL

Malgré leurs qualités communes, il est important de comprendre les différences fonctionnelles entre Falcor et GraphQL. Il s’agit en particulier des spécificités de leur mise en œuvre, de leur souplesse en matière d’interrogation et de leur performance respective.

Approche d’implémentation

Comme il est avant tout un langage de requêtes, GraphQL fournit un ensemble de règles régissant les opérations d’interrogation des données. Cela signifie que la mise en œuvre de GraphQL nécessite l’utilisation de bibliothèques conformes aux « standards » du langage. À l’inverse, comme il s’agit d’une librairie JavaScript, Falcor fournit à la fois un modèle de requête et une implémentation unique de ce modèle.

En pratique, cette différence n’est pas très importante : il existe de nombreuses bibliothèques GraphQL disponibles pour la plupart des langages de programmation courants, dont Javascript, Java, Go, Ruby, Scala ou encore Python.

Pour autant, JavaScript est conforme à pratiquement tous les types d’applications web et mobiles. Dans la plupart des cas, il est assez facile pour les développeurs d’utiliser Falcor et GraphQL côte à côte.

Néanmoins, leurs spécificités d’implémentation ont une incidence sur les librairies que vous devez appeler. GraphQL offre de nombreuses options que Falcor ne propose pas. Les requêtes Falcor sont sans doute plus simples que les requêtes GraphQL, ce qui rend Falcor plus simple à apprendre et à exploiter, à condition d’être familier avec JavaScript. Mais si vous n’aimez pas JavaScript, vous n’aimerez probablement pas Falcor non plus (une implémentation .NET de Falcor existe, mais le projet n’a pas été mis à jour depuis huit ans).

Flexibilité des requêtes

GraphQL offre des possibilités avancées, notamment en ce qui concerne la recherche et le filtrage de motifs. Falcor, quant à lui, prend en charge les requêtes partiellement ouvertes telles que les plages de nombres. S’il est plus simple à prendre en main, la recherche de motifs complexes est beaucoup plus laborieuse avec Falcor qu’avec GraphQL.

Dans les situations où vous connaissez les données spécifiques que vous devez récupérer, la flexibilité des types de requêtes de GraphQL n’offre pas un avantage aussi important. En revanche, lorsque vous n’êtes pas sûr du contenu des données, GraphQL vous permet de filtrer plus facilement les informations dont vous avez besoin sans savoir à l’avance à quoi elles ressemblent.

Efficacité des requêtes

En général, il est plus facile de mettre en œuvre des requêtes très efficaces avec GraphQL qu’avec Falcor. En effet, GraphQL fournit un moteur puissant qui permet aux développeurs d’écrire des requêtes qui récupèrent toutes les données nécessaires en une seule fois. Avec Falcor, si vous ne connaissez pas d’emblée les données que vous cherchez, il est plus probable que vous deviez exécuter plusieurs requêtes pour obtenir la totalité des données dont vous avez besoin.

Cette différence est importante dans les cas d’usage où l’efficacité et les performances de l’application sont une priorité. Moins vous faites de requêtes, moins vous chargez les serveurs, les clients et le réseau. GraphQL est donc le choix le plus efficace lorsque l’on est confronté à des réseaux potentiellement peu fiables ou à des dispositifs dotés de ressources minimales côté client. Les avantages de GraphQL dans ce domaine sont moins importants dans les cas d’usage où les clients disposent davantage de puissance de calcul et d’un réseau performant.

Pourquoi Falcor est si discret

Falcor ne bénéficie pas de l’aura de GraphQL. Il suffit d’observer l’activité sur GitHub et sur NPM pour se rendre compte que l’industrie et les entreprises ont choisi leur champion. En 2023, quand les paquets Falcor sont téléchargés moins de 800 fois par mois, quand ceux de GraphQL sont téléchargés plus de 10 millions de fois par mois, selon npm trends. À y regarder de plus près, le projet de Netflix ne semble pas avoir bénéficié de mise à jour majeure depuis deux ans. De fait, le spécialiste de la SVOD déploie massivement GraphQL depuis 2019. Dailymotion a, lui aussi, opté pour ce projet après avoir considéré Falcor. La technologie imaginée par Facebook a profité d’un soutien élargi quand certains reprochent à Netflix de ne pas avoir suffisamment promu Falcor.

Les différences décrites ci-dessus ont joué : GraphQL a fait ses preuves à large échelle, dans des piles technologiques hétéroclites. Falcor continue de bénéficier d’un avantage : sa simplicité d’implémentation et d’utilisation. Bien que porté par une fondation, le projet libéré par GraphQL souffre (encore) de sa courbe d’apprentissage abrupte. Enfin, sa capacité à remplacer ou à compléter une architecture REST, a fait de ce projet un choix évident pour les entreprises et les éditeurs.