Quelle est la différence entre Falcor et GraphQL?
GraphQL comprend un système de types, un langage de requête et une sémantique d'exécution, une validation statique et une introspection de types, décrits ci-dessous. Pour vous guider à travers chacun de ces composants, nous avons écrit un exemple conçu pour illustrer les différentes parties de GraphQL.
- https://github.com/facebook/graphql
Falcor vous permet de représenter toutes vos sources de données distantes en tant que modèle à domaine unique via un graphique JSON virtuel. Vous codez de la même manière, où que se trouvent les données, que ce soit en mémoire sur le client ou sur le réseau sur le serveur.
- http://netflix.github.io/falcor/
Quelle est la différence entre Falcor et GraphQL (dans le contexte de Relay)?
J'ai visualisé le Angular Air Episode 26: FalcorJS et Angular 2 où Jafar Husain répond comment GraphQL se compare à FalcorJS . Ceci est le résumé (paraphrasant):
- FalcorJS et GraphQL s’attaquent au même problème (interroger des données, gérer des données).
- La distinction importante est que GraphQL est un langage de requête et que FalcorJS ne l’est pas.
- Lorsque vous demandez des ressources à FalcorJS, vous demandez très explicitement des séries finies de valeurs. FalcorJS prend en charge des éléments tels que les plages, par exemple.
genres[0..10]. Mais il ne prend pas en charge les requêtes ouvertes, par exemple.genres[0..*]. - GraphQL est basé sur les paramètres: donnez-moi tous les enregistrements où true, order by this, etc. En ce sens, le langage de requête GraphQL est plus puissant que FalcorJS.
- Avec GraphQL, vous disposez d’un puissant langage de requête, mais vous devez l’interpréter sur le serveur.
Jafar affirme que dans la plupart des applications, les types de requêtes qui vont d'un client à un serveur partagent la même forme. Par conséquent, le fait d'avoir des opérations spécifiques et prévisibles telles que get et set expose plus d'opportunités pour exploiter le cache. En outre, de nombreux développeurs sont habitués à mapper les demandes à l’aide d’un simple routeur dans l’architecture REST.
La discussion finale a pour but de déterminer si la puissance fournie par GraphQL l'emporte sur la complexité.
J'ai maintenant écrit des applications avec les deux bibliothèques et je peux accepter tout ce qui est écrit dans le message de Gajus, mais j'ai constaté que certains éléments différents étaient les plus importants dans ma propre utilisation des frameworks.
- La différence pratique la plus importante réside probablement dans le fait que la plupart des exemples et des travaux effectués jusqu’à présent sur GraphQL ont été concentrés sur l’intégration de GraphQL avec Relay - le système de Facebook permettant d’intégrer les widgets ReactJS à leurs besoins en données. FalcorJS, d’autre part, tend à agir séparément du système de widgets, ce qui signifie qu’il peut être plus facile de l’intégrer à un client non-React/Relay et qu’il fera moins pour vous automatiquement en termes de mise en correspondance des dépendances de données de widgets avec des widgets.
- Le côté opposé de la flexibilité de FalcorJS dans les intégrations côté client est qu’il peut être très déterminé sur la façon dont le serveur doit agir. FalcorJS a en fait une fonctionnalité directe "Appelez cette requête via HTTP" - bien que Jafar Husain ne semble pas en parler beaucoup - et une fois que vous les avez incluses, la façon dont les bibliothèques clientes réagissent aux informations du serveur est assez similaire, sauf que GraphQL/Relay ajoute une couche de configuration. Dans FalcorJS, si vous renvoyez une valeur pour movie, votre valeur renvoyée vaut mieux "movie", alors que dans GraphQL, vous pouvez décrire cela même si la requête renvoie "film", vous devez l'insérer dans le magasin de données côté client sous la forme "movie". '. - Cela fait partie du compromis puissance vs complexité mentionné par Gajus.
- Sur le plan pratique, GraphQL et Relay semblent être plus développés. Jafar Husain a indiqué que la prochaine version de l'interface Netflix fonctionnera au moins en partie sur FalcorJS, tandis que l'équipe Facebook a indiqué qu'elle utilisait une version de la pile GraphQL/Relay en production depuis plus de 3 ans.
- La communauté de développeurs open source autour de GraphQL et de Relay semble prospérer. Il existe un grand nombre de projets d’appui bien suivis autour de GraphQL et Relay, alors que j’en ai personnellement trouvé très peu autour de FalcorJS. Le référentiel github de base pour Relay ( https://github.com/facebook/relay/Pulse ) est considérablement plus actif que le référentiel github pour FalcorJS ( https: // github. com/netflix/falcor/Pulse ). Lorsque j'ai extrait le dépôt Facebook, les exemples étaient cassés. J'ai ouvert un problème avec github et le problème a été résolu en quelques heures. D'autre part, le problème de github que j'ai ouvert sur FalcorJS n'a pas eu de réponse officielle depuis deux semaines.
Lee Byron l'un des ingénieurs derrière GraphQL a fait un AMA sur hashnode , voici sa réponse à cette question:
- Falcor renvoie les valeurs observables et GraphQL. La façon dont Netflix a voulu utiliser Falcor a beaucoup de sens pour elles. Ils font plusieurs demandes et présentent des données dès qu’ils sont prêts, mais cela signifie également que le développeur client doit travailler directement avec les observables. GraphQL est un modèle de requête/réponse et renvoie JSON, qui est trivialement facile à utiliser. Relay rajoute au dynamisme présenté par Falcor tout en ne conservant que des valeurs claires.
- Système de type. GraphQL est défini en termes de système de type, ce qui nous a permis de construire de nombreux outils intéressants tels que GraphiQL, des générateurs de code, la détection d'erreur, etc. Falcor est beaucoup plus dynamique, ce qui est précieux, mais limite la capacité de faire ce genre de chose.
- Utilisation du réseau. GraphQL a été conçu à l’origine pour faire fonctionner le fil de nouvelles de Facebook sur des appareils bas de gamme, même sur des réseaux bas de gamme. déclarez tout ce dont vous avez besoin dans une seule demande réseau afin de minimiser la latence. Falcor, en revanche, effectue souvent plusieurs allers-retours pour collecter des données supplémentaires. Il ne s’agit en réalité que d’un compromis entre la simplicité du système et le contrôle du réseau. Pour Netflix, ils s’appliquent également à des appareils très bas de gamme (par exemple, une clé Roku), mais l’hypothèse est que le réseau sera suffisamment bon pour diffuser de la vidéo.
Edit: Falcor peut en effet requêtes par lots , rendant le commentaire sur l’utilisation du réseau inexact. Merci à @PrzeoR
MISE À JOUR: J'ai trouvé le commentaire très utile sous mon message que je souhaite partager avec vous en complément du contenu principal: 
En ce qui concerne le manque d’exemples, vous pouvez trouver le dépôt awesome-falcorjs convivial, il existe différents exemples d’utilisation d’un CRUD par Falcor: https://github.com/przeor/awesome-falcorjs ... Deuxième chose , il existe un livre intitulé " Mastering Full Stack React Développement) " ", qui inclut également Falcor (bon moyen d'apprendre à l'utiliser):
ORGINAL POST CI-DESSOUS:
FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) est beaucoup plus simple pour être efficace par rapport à Relay/GraphQL.
La courbe d’apprentissage de GraphQL + Relay est énorme: 
Dans mon bref résumé: Allez pour Falcor. Utilisez Falcor dans votre prochain projet jusqu'à ce que VOUS ayez un budget important et beaucoup de temps d’apprentissage pour votre équipe, puis utilisez RELAY + GRAPHQL.
GraphQL + Relay a une API énorme dans laquelle vous devez être efficace. Falcor a une petite API et est très facile à comprendre pour tout développeur front-end qui connaît JSON.
Si vous avez un projet AGILE avec des ressources limitées -> alors optez pour FalcorJS!
Mon opinion SUBJECTIVE: FalcorJS est 500% + plus facile d’être efficace en javascript full-stack.
J'ai également publié des kits de démarrage FalcorJS sur mon projet (+ plusieurs exemples de projets Falcor complets): https://www.github.com/przeor
Pour être plus dans les détails techniques:
1) Lorsque vous utilisez Falcor, vous pouvez utiliser à la fois le front-end et le back-end:
importer falcor de 'falcor';
puis construisez votre modèle en fonction de.
... vous avez également besoin de deux bibliothèques simples à utiliser sur le backend: a) falcor-express - vous l’utilisez une fois (ex. app.use ('/ model.json', FalcorServer .dataSourceRoute (() => new NamesRouter ())) ). Source: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js
b) falcor-router - là vous définissez des routes SIMPLE (ex. route: '_view.length'). Source: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js
Falcor est un jeu d'enfant en termes de courbe d'apprentissage.
Vous pouvez également voir la documentation qui est beaucoup plus simple que la bibliothèque de FB et consulter également l'article " pourquoi vous devriez vous soucier de falcorjs (netflix falcor)) ".
2) Relay/GraphQL ressemble plus à un énorme outil d’entreprise.
Par exemple, vous avez deux documentations distinctes qui parlent séparément:
a) Relais: https://facebook.github.io/relay/docs/tutorial.html - Conteneurs - Routes - Conteneur racine - Etat Prêt - Mutations - Couche réseau - Plugin Babel Relay - GRAPHQL
- Spécification de relais GraphQL
- Identification d'objet
- Lien
- Mutations
- Lectures complémentaires
RÉFÉRENCE API
Relais
- RelaisConteneur
- Relais.Route
- Relay.RootContainer
- Relay.QL
- Relais.Mutation
- Relay.PropTypes
- Relay.Store
INTERFACES
RelayNetworkLayer
- RelayMutationRequest
- RelayQueryRequest
b) GrapQL: https://facebook.github.io/graphql/
- 2langue
- 2.1Source texte
- 2.1.1Unicode
- 2.1.2Espace Blanc
- 2.1.3 Terminateurs linéaires
- 2.1.4Commentaires
- 2.1.5Cas minuscules
- 2.1.6Personnes Lexiques
- 2.1.7 Jetons Ignorés
- 2.1.8Ponctuateurs
- 2.1.9Noms
- 2.2Query Document
- 2.2.1Opérations
- 2.2.2 Ensembles de sélection
- 2.2.3Les champs
- 2.2.4Arguments
- 2.2.5 alias de champ
- 2.2.6Fragments
- 2.2.6.1Type de conditions
- 2.2.6.2 Fragments en ligne
- 2.2.7Valeurs d'entrée
- 2.2.7.1Int Valeur
- 2.2.7.2 Valeur flottante
- 2.2.7.3Boolean Value
- 2.2.7.4Valeur de chaîne
- 2.2.7.5 Valeur de la somme
- 2.2.7.6Liste valeur
- 2.2.7.7Valeurs d'objet d'entrée
- 2.2.8Variables
- 2.2.8.1Utilisation variable dans les fragments
- 2.2.9 Types d'entrée
- 2.2.10Directives
- 2.2.10.1 Directives de fragmentation
- Système 3Type
- 3.1Types
- 3.1.1Scalaires
- 3.1.1.1 Scalaires intégrés
- 3.1.1.1.1Int
- 3.1.1.1.2Float
- 3.1.1.1.3Chaîne
- 3.1.1.1.4Booléen
- 3.1.1.1.5ID
- 3.1.2Objets
- 3.1.2.1 Arguments de champ objet
- 3.1.2.2 Obsolète de champ objet
- 3.1.2.3 Validation du type d'objet
- 3.1.3Interfaces
- 3.1.3.1Validation de type d'interface
- 3.1.4Unions
- 3.1.4.1Validation de type Union
- 3.1.5Enums
- 3.1.6Objets d'entrée
- 3.1.7Listes
- 3.1.8Non-Null
- 3.2Directives
- 3.2.1@skip
- 3.2.2@include
- 3.3Types de départ
- 4Introspection
- 4.1 Principes généraux
- 4.1.1 Conventions de nommage
- 4.1.2Documentation
- 4.1.3Déprécation
- 4.1.4Introspection du nom du type
- 4.2Introspection du Schéma
- 4.2.1Le type "__Type"
- 4.2.2Type de types
- 4.2.2.1Scalaire
- 4.2.2.2Objet
- 4.2.2.3Union
- 4.2.2.4Interface
- 4.2.2.5Enum
- 4.2.2.6Objet d'entrée
- 4.2.2.7Liste
- 4.2.2.8Non-null
- 4.2.2.9Liste combinée et non nulle
- 4.2.3Le type de __Field
- 4.2.4Le type __InputValue
- 5Validation
- 5.1Opérations
- 5.1.1 Définitions d'opération nommée
- 5.1.1.1 Unicité du nom de l'opération
- 5.1.2 Définitions d'opération anonyme
- 5.1.2.1Opération anonyme unique
- 5.2Droits
- 5.2.1 Sélections de champ sur les types d'objets, d'interfaces et d'unions
- 5.2.2 Fusion de sélection de champ
- 5.2.3 Sélections de champs de feuilles
- 5.3Arguments
- 5.3.1 Noms des arguments
- 5.3.2 Unicité des arguments
- 5.3.3Argument Values Type Correctness
- 5.3.3.1Valeurs compatibles
- 5.3.3.2 Arguments requis
- 5.4 Fragments
- 5.4.1 Déclarations de fragment
- 5.4.1.1 Unicité du nom du fragment
- 5.4.1.2 Existence de type d'épandage de fragment
- 5.4.1.3 Fragments sur les types composites
- 5.4.1.4Les fragments doivent être utilisés
- 5.4.2Fragment Spreads
- 5.4.2.1La cible de propagation de fragment définie
- 5.4.2.2Les tartinades ne doivent pas former de cycles
- 5.4.2.3La propagation du fragment est possible
- 5.4.2.3.1 Spreads d'objet dans la portée d'un objet
- 5.4.2.3.2Répartition abstraite dans la portée d'un objet
- 5.4.2.3.3Les spreads d'objet dans la portée abstraite
- 5.4.2.3.4Les spreads abstraits dans la portée abstraite
- 5.5Valeurs
- 5.5.1 Caractère unique du champ d'objet d'entrée
- 5.6Directives
- 5.6.1Directives sont définies
- 5.7Variables
- 5.7.1Unicité variable
- 5.7.2Les valeurs par défaut variables sont correctement saisies
- 5.7.3Les variables sont des types d'entrée
- 5.7.4Toutes les utilisations variables définies
- 5.7.5Toutes les variables utilisées
- 5.7.6Toutes les utilisations variables sont autorisées
- 6Exécution
- 6.1Évaluer les demandes
- 6.2 Variables commerciales
- 6.3Evaluer les opérations
- 6.4Évaluer les jeux de sélection
- 6.5Evaluer un ensemble de champs groupé
- 6.5.1Entrées de terrain
- 6.5.2Évaluation normale
- 6.5.3Exécution en série
- 6.5.4 Traitement des erreurs
- 6.5.5Nullabilité
- 7Réponse
- 7.1 Format de sérialisation
- 7.1.1 Sérialisation JSON
- 7.2 Format de réponse
- 7.2.1Données
- 7.2.2Error
- AAnnexe: Conventions de notation
- A.1 Grammaire sans contexte
- A.2 Grammaire syntaxique et syntaxique
- A.3Grammar Notation
- A.4Gémantique Sémantique
- A.5Algorithmes
- BAppendix: Résumé de grammaire
- B.1 Jetons Ignorés
- B.2. Jetons Lexiques
- B.3Query Document
C'est ton choix:
Simple et court documenté Falcor JS VERSUS Outil de taille entreprise avec une documentation longue et avancée en tant que GraphQL & Relay
Comme je l'ai déjà dit, si vous êtes un développeur front-end et que vous avez une idée de l'utilisation de JSON, l'implémentation de graphes JSON par l'équipe de Falcor est la meilleure façon de réaliser votre projet de développement complet.
En bref, Falcor ou GraphQL ou Restful résolvent le même problème - fournissent un outil pour interroger/manipuler les données efficacement.
La différence entre eux réside dans la manière dont ils présentent leurs données:
- Falcor souhaite que vous pensiez ses données comme une très grande arborescence JSON virtuelle et utilise get , set et appelez pour lire, écrire des données.
- GraphQL veut que vous pensiez leurs données comme un groupe d'objets typés prédéfinis, et utilise des requêtes et des mutations pour lire, écrire des données.
- Restful veut que vous pensiez leurs données comme un groupe de ressources et utilise des verbes HTTP pour lire et écrire des données.
Chaque fois que nous avons besoin de fournir des données à l'utilisateur, nous obtenons quelque chose d'aimé: client -> requête -> {une requête de traduction de couche en opération de données} -> data.
Après avoir lutté avec GraphQL, Falcor et JSON API (et même ODdata), j'ai écrit ma propre couche de requête de données . C'est plus simple, plus facile à apprendre et plus équivalent avec GraphQL.
Vérifiez-le à:
https://github.com/giapnguyen74/nextql
Il s’intègre également à featherjs pour les requêtes/mutations en temps réel. https://github.com/giapnguyen74/nextql-feathers
OK, commencez simplement par une différence simple mais importante, GraphQL est une requête basée sur Falcor n'est pas!
Mais comment ils vous aident?
Fondamentalement, ils nous aident tous les deux à gérer et à interroger des données, mais GraphQL a un modèle req/res et renvoie les données sous la forme JSON , en gros, l'idée dans GraphQL est d'avoir une seule requête pour obtenir toutes vos données dans un seul objectif ... De plus, une réponse exacte en ayant une requête exacte, donc quelque chose à Si vous avez de nombreux utilisateurs mobiles ou pour certaines raisons, si vous souhaitez avoir moins de demandes et une réponse plus rapide, utilisez GraphQL .. Bien que Faclor ne soit pas trop éloigné de cela, alors poursuivez votre lecture ...
D'autre part, Falcor de Netflix, demande généralement (généralement plus d'une fois) de récupérer toutes vos données, même s'ils tentent de l'améliorer à un seul ... Falcor est plus limité pour les requêtes et n’a pas d’aides aux requêtes prédéfinies comme range et etc ...
Mais pour plus de précisions, voyons comment chacun d’entre eux se présente:
GraphQL, un langage de requête pour votre API
GraphQL est un langage de requête pour les API et un environnement d'exécution permettant de répondre à ces requêtes avec vos données existantes. GraphQL fournit une description complète et compréhensible des données de votre API, donne aux clients le pouvoir de demander exactement ce dont ils ont besoin et rien de plus, facilite l'évolution des API au fil du temps et permet l'utilisation d'outils puissants pour les développeurs.
Envoyez une requête GraphQL à votre API et obtenez exactement ce dont vous avez besoin, rien de plus, rien de moins. Les requêtes GraphQL renvoient toujours des résultats prévisibles. Les applications utilisant GraphQL sont rapides et stables car elles contrôlent les données qu'elles obtiennent, pas le serveur.
Les requêtes GraphQL accèdent non seulement aux propriétés d'une ressource, mais suivent également les références entre elles. Bien que les API typiques REST nécessitent le chargement à partir de plusieurs URL, les API GraphQL obtiennent toutes les données dont votre application a besoin en une seule requête. Les applications utilisant GraphQL peuvent être rapides, même sur des connexions de réseau mobile lentes.
Les API GraphQL sont organisées en termes de types et de champs, pas de points de terminaison. Accédez à toutes les fonctionnalités de vos données à partir d'un seul point de terminaison. GraphQL utilise des types pour s'assurer que les applications ne demandent que ce qui est possible et fournissent des erreurs claires et utiles. Les applications peuvent utiliser des types pour éviter d'écrire du code d'analyse manuelle.
Falcor, une bibliothèque JavaScript pour une récupération efficace des données
Falcor vous permet de représenter toutes vos sources de données distantes en tant que modèle à domaine unique via un graphique JSON virtuel. Vous codez de la même manière, où que se trouvent les données, que ce soit en mémoire sur le client ou sur le réseau sur le serveur.
Une syntaxe de chemin semblable à celle de JavaScript facilite l'accès à autant de données que vous le souhaitez, quand vous le souhaitez. Vous récupérez vos données en utilisant des opérations JavaScript familières telles que get, set et call. Si vous connaissez vos données, vous connaissez votre API.
Falcor parcourt automatiquement les références dans votre graphique et effectue les demandes nécessaires. Falcor gère de manière transparente toutes les communications réseau, le traitement opportun et le traitement en différé des demandes.