¿Cuál es la diferencia entre Falcor y GraphQL?


163

GraphQL consta de un sistema de tipos, lenguaje de consulta y semántica de ejecución, validación estática e introspección de tipos, cada uno de los cuales se describe a continuación. Para guiarlo a través de cada uno de estos componentes, hemos escrito un ejemplo diseñado para ilustrar las diversas piezas de GraphQL.

- https://github.com/facebook/graphql

Falcor le permite representar todas sus fuentes de datos remotas como un modelo de dominio único a través de un gráfico JSON virtual. Usted codifica de la misma manera sin importar dónde estén los datos, ya sea en la memoria del cliente o en la red del servidor.

- http://netflix.github.io/falcor/

¿Cuál es la diferencia entre Falcor y GraphQL (en el contexto de Relay)?


55
mira este podcast donde Jafar habla sobre la diferencia entre Relay / GraphQL y Falcor / JSON Graph youtu.be/WL54eYbTJUw?t=53m55s
gdi2290

Respuestas:


131

He visto el Episodio 26 de Angular Air: FalcorJS y Angular 2, donde Jafar Husain responde cómo GraphQL se compara con FalcorJS . Este es el resumen (parafraseando):

  • FalcorJS y GraphQL están abordando el mismo problema (consultar datos, gestionar datos).
  • La distinción importante es que GraphQL es un lenguaje de consulta y FalcorJS no lo es.
  • Cuando le pide recursos a FalcorJS, está pidiendo de manera muy explícita series de valores finitos. FalcorJS admite cosas como rangos, por ejemplo genres[0..10]. Pero no admite consultas abiertas, por ejemplo genres[0..*].
  • GraphQL está configurado en base: dame todos los registros donde sea verdadero, ordena por esto, etc. En este sentido, el lenguaje de consulta GraphQL es más poderoso que FalcorJS.
  • Con GraphQL, tiene un poderoso lenguaje de consulta, pero debe interpretar ese lenguaje de consulta en el servidor.

Jafar argumenta que en la mayoría de las aplicaciones, los tipos de consultas que van del cliente al servidor comparten la misma forma. Por lo tanto, tener operaciones específicas y predecibles como obtener y establecer expone más oportunidades para aprovechar la caché. Además, muchos de los desarrolladores están familiarizados con el mapeo de las solicitudes utilizando un enrutador simple en la arquitectura REST.

La discusión final se resuelve en torno a si el poder que viene con GraphQL supera la complejidad.


82

Ahora he escrito aplicaciones con ambas bibliotecas y puedo estar de acuerdo con todo en la publicación de Gajus, pero encontré algunas cosas diferentes más importantes en mi propio uso de los marcos.

  • Probablemente la mayor diferencia práctica es que la mayoría de los ejemplos y, presumiblemente, el trabajo realizado hasta este punto en GraphQL se ha concentrado en integrar GraphQL con Relay, el sistema de Facebook para integrar los widgets ReactJS con sus requisitos de datos. FalcorJS, por otro lado, tiende a actuar por separado del sistema de widgets, lo que significa que puede ser más fácil integrarse en un cliente que no sea React / Relay y que hará menos por usted automáticamente en términos de emparejar las dependencias de datos de widgets con widgets.
  • La otra cara de que FalcorJS es flexible en las integraciones del lado del cliente es que puede ser muy obstinado acerca de cómo debe actuar el servidor. FalcorJS en realidad tiene una capacidad directa de "Llamar a esta consulta a través de HTTP", aunque Jafar Husain no parece hablar mucho de eso, y una vez que los incluye, la forma en que las bibliotecas del cliente reaccionan a la información del servidor es bastante similar, excepto que GraphQL / Relay agrega una capa de configuración. En FalcorJS, si está devolviendo un valor para película, su valor de retorno es mejor decir 'película', mientras que en GraphQL, puede describir que aunque la consulta devuelva 'película', debe poner eso en el almacén de datos del lado del cliente como 'película' '. - Esto es parte de la compensación de poder versus complejidad que Gajus mencionó.
  • Sobre una base práctica, GraphQL y Relay parecen estar más desarrollados. Jafar Husain ha mencionado que la próxima versión de la interfaz de Netflix se ejecutará al menos en parte en FalcorJS, mientras que el equipo de Facebook ha mencionado que han estado usando alguna versión de la pila GraphQL / Relay en producción durante más de 3 años.
  • La comunidad de desarrolladores de código abierto en torno a GraphQL y Relay parece estar prosperando. Hay una gran cantidad de proyectos de asistencia con asistencia en torno a GraphQL y Relay, mientras que personalmente he encontrado muy pocos en FalcorJS. Además, el repositorio github base para Relay ( https://github.com/facebook/relay/pulse ) es significativamente más activo que el repositorio github para FalcorJS ( https://github.com/netflix/falcor/pulse ). Cuando saqué por primera vez el repositorio de Facebook, los ejemplos estaban rotos. Abrí un problema de github y se solucionó en cuestión de horas. Por otro lado, el problema de Github que abrí en FalcorJS no ha tenido respuesta oficial en dos semanas.

1
GraphQL (2012) ha existido mucho antes de React and Relay, por lo que su primer punto podría no ser del todo exacto.
Burgi

Puede que tengas razón. No soy facebooker, así que realmente no puedo hablar de la historia. Mi comentario proviene más del estado actual de la documentación y las conversaciones de Facebook. Fueron introducidos al mundo como compañeros ( facebook.github.io/react/blog/2015/02/20/… ) y ambos se remontan bastante. He visto algunos vagos movimientos manuales sobre Relay que se remontan 3 años en comentarios de principios de 2015, por lo que es posible que ambos se hayan desarrollado internamente durante varios años antes de presentarse al mundo exterior. Pero ciertamente no tengo ningún conocimiento especial.
OverclockedTim

25

Lee Byron uno de los ingenieros detrás de GraphQL hizo un AMA en hashnode , aquí está su respuesta cuando se le hizo esta pregunta:

  • Falcor devuelve Observables, GraphQL solo valores. Por cómo Netflix quería usar Falcor, esto tiene mucho sentido para ellos. Realizan múltiples solicitudes y presentan datos cuando están listos, pero también significa que el desarrollador del cliente tiene que trabajar directamente con los Observables. GraphQL es un modelo de solicitud / respuesta, y devuelve JSON, que es trivialmente fácil de usar. La retransmisión agrega algo del dinamismo que presenta Falcor mientras mantiene solo el uso de valores simples.
  • Sistema de tipos. GraphQL se define en términos de un sistema de tipos, y eso nos permitió construir muchas herramientas interesantes como GraphiQL, generadores de código, detección de errores, etc. Falcor es mucho más dinámico, lo que es valioso por sí mismo pero limita la capacidad de hacerlo. Este tipo de cosas.
  • Uso de la red. GraphQL fue diseñado originalmente para operar el servicio de noticias de Facebook en dispositivos de gama baja en redes incluso más bajas, por lo que hace todo lo posible para que pueda declarar todo lo que necesita en una sola solicitud de red para minimizar la latencia. Falcor, por otro lado, a menudo realiza múltiples viajes de ida y vuelta para recopilar datos adicionales. Esto es realmente solo una compensación entre la simplicidad del sistema y el control de la red. Para Netflix, también se ocupan de dispositivos de muy bajo nivel (por ejemplo, Roku stick), pero se supone que la red será lo suficientemente buena como para transmitir video.

Editar: Falcor puede procesar solicitudes por lotes , haciendo que el comentario sobre el uso de la red sea inexacto. Gracias a @PrzeoR


44
NO ES VERDADERO -> "" "Falcor, por otro lado, a menudo realiza múltiples viajes de ida y vuelta para recopilar datos adicionales. Esto es realmente solo una compensación entre la simplicidad del sistema y el control de la red." "". Simplemente verifique la funcionalidad de Falcor Batch y es igual o incluso mejor que en Relay.
PrzeoR

1
@PrzeoR ¡Gracias por la corrección! ¡Edité la publicación!
YasserKaddour

de nada :-) relacionado con FalcorJS, consulte para obtener más detalles aquí: reactjs.co/2016/02/03/…
PrzeoR

Gran artículo, de hecho, Falcor es excelente, desafortunadamente soy un desarrollador de Scala y no hay implementación de Falcor en Scala y en ningún otro idioma, sin embargo, hay una sangría excelente implementación de GraphQL en Scala
YasserKaddour

Y hay otra alternativa a la retransmisión que usa redux como apollo-client y cashay
YasserKaddour

21

ACTUALIZACIÓN: He encontrado un comentario muy útil debajo de mi publicación que quiero compartir con ustedes como algo complementario al contenido principal: ingrese la descripción de la imagen aquí

Con respecto a la falta de ejemplos, puede encontrar útil el repositorio de awesome-falcorjs, hay diferentes ejemplos del uso de CRUD de Falcor: https://github.com/przeor/awesome-falcorjs ... En segundo lugar, hay un libro llamado " Dominar el desarrollo de Full Stack React ", que también incluye Falcor (buena forma de aprender a usarlo):

ingrese la descripción de la imagen aquí

POST ORIGINAL ABAJO:

FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) es mucho más simple para ser eficiente en comparación con Relay / GraphQL.

La curva de aprendizaje para GraphQL + Relay es ENORME: ingrese la descripción de la imagen aquí

En mi breve resumen: ve por Falcor. Use Falcor en su próximo proyecto hasta que USTED tenga un gran presupuesto y mucho tiempo de aprendizaje para su equipo, luego use RELAY + GRAPHQL.

GraphQL + Relay tiene una API enorme en la que debe ser eficiente. Falcor tiene una API pequeña y es muy fácil de entender para cualquier desarrollador front-end que esté familiarizado con JSON.

Si tiene un proyecto AGILE con recursos limitados -> ¡entonces elija FalcorJS!

Mi opinión subjetiva: FalcorJS es 500% + más fácil de ser eficiente en JavaScript de pila completa.

También he publicado algunos kits de inicio de FalcorJS en mi proyecto (+ más proyectos de ejemplo de falcor de pila completa): https://www.github.com/przeor

Para estar más en detalles técnicos:

1) Cuando usa Falcor, puede usar tanto en el front-end como en el backend:

importar falcor de 'falcor';

y luego construye tu modelo basado en.

... también necesita dos bibliotecas que sean fáciles de usar en el backend: a) falcor-express: lo usa una vez (por ejemplo, app.use ('/ model.json', FalcorServer.dataSourceRoute (() => new NamesRouter) ())) ). Fuente: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b) enrutador falcor: allí se definen rutas SIMPLES (por ejemplo, ruta: '_view.length' ). Fuente: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Falcor es pan comido en términos de curva de aprendizaje.

También puede ver documentación que es mucho más simple que la biblioteca de FB y consultar también el artículo " por qué debería preocuparse por los falcorjs (netflix falcor) ".

2) Relay / GraphQL es más probable como una gran herramienta empresarial.

Por ejemplo, tiene dos documentaciones diferentes de las que se habla por separado:

a) Relé: https://facebook.github.io/relay/docs/tutorial.html - Contenedores - Rutas - Contenedor raíz - Estado preparado - Mutaciones - Capa de red - Complemento de relé Babel - GRAPHQL

  • Especificación de retransmisión GraphQL
  • Identificación de objeto
  • Conexión
  • Mutaciones
  • Otras lecturas
  • REFERENCIA API

  • Relé

  • RelayContainer
  • Relé.Ruta
  • Relay.RootContainer
  • Relay.QL
  • Relé Mutación
  • Relay.PropTypes
  • Relay.Store
  • INTERFACES

  • RelayNetworkLayer

  • RelayMutationRequest
  • RelayQueryRequest

b) GrapQL: https://facebook.github.io/graphql/

  • 2Idioma
  • 2.1 Texto de origen
  • 2.1.1 Unicode
  • 2.1.2 Espacio blanco
  • 2.1.3 Terminadores de línea
  • 2.1.4Comentarios
  • 2.1.5 Comas insignificantes
  • 2.1.6 Fichas Léxicas
  • 2.1.7 Fichas ignoradas
  • 2.1.8 Puntuadores
  • 2.1.9 Nombres
  • 2.2 Documento de consulta
  • 2.2.1 Operaciones
  • 2.2.2 Conjuntos de selección
  • 2.2.3 Campos
  • 2.2.4 Argumentos
  • 2.2.5 Alias ​​de campo
  • 2.2.6 Fragmentos
  • 2.2.6.1 Condiciones de tipo
  • 2.2.6.2 Fragmentos en línea
  • 2.2.7 Valores de entrada
  • 2.2.7.1 Valor entrante
  • 2.2.7.2 Valor flotante
  • 2.2.7.3 Valor booleano
  • 2.2.7.4 Valor de cadena
  • 2.2.7.5 Valor de enumeración
  • 2.2.7.6 Valor de la lista
  • 2.2.7.7 Valores de objeto de entrada
  • 2.2.8 Variables
  • 2.2.8.1 Uso variable dentro de fragmentos
  • 2.2.9 Tipos de entrada
  • 2.2.10 Directivas
  • 2.2.10.1 Directivas de fragmentos
  • Sistema 3Type
  • 3.1 Tipos
  • 3.1.1 Escalares
  • 3.1.1.1 Escalares incorporados
  • 3.1.1.1.1 En
  • 3.1.1.1.2 Flotador
  • 3.1.1.1.3String
  • 3.1.1.1.4 Booleano
  • 3.1.1.1.5ID
  • 3.1.2 Objetos
  • 3.1.2.1 Argumentos de campo de objeto
  • 3.1.2.2 Desuso de campo de objeto
  • 3.1.2.3 Validación de tipo de objeto
  • 3.1.3 Interfaces
  • 3.1.3.1 Validación de tipo de interfaz
  • 3.1.4 Uniones
  • 3.1.4.1 Validación de tipo de unión
  • 3.1.5 Enums
  • 3.1.6 Objetos de entrada
  • 3.1.7Listas
  • 3.1.8 No nulo
  • 3.2Directivas
  • 3.2.1@skip
  • 3.2.2@include
  • 3.3 Tipos de inicio
  • 4Introspección
  • 4.1 Principios generales
  • 4.1.1 Convenciones de nomenclatura
  • 4.1.2Documentación
  • 4.1.3Deprecación
  • 4.1.4 Introspección de nombre de tipo
  • 4.2 Introspección de esquemas
  • 4.2.1 El tipo "__Type"
  • 4.2.2 Tipos de tipos
  • 4.2.2.1 Escalar
  • 4.2.2.2 Objeto
  • 4.2.2.3 Unión
  • 4.2.2.4 Interfaz
  • 4.2.2.5 Enum
  • 4.2.2.6 Objeto de entrada
  • 4.2.2.7 Lista
  • 4.2.2.8 No nulo
  • 4.2.2.9 Lista combinada y no nula
  • 4.2.3 El __Tipo de campo
  • 4.2.4 El tipo __InputValue
  • 5 Validación
  • 5.1 Operaciones
  • 5.1.1 Definiciones de operación nombradas
  • 5.1.1.1 Nombre único de la operación
  • 5.1.2 Definiciones de operaciones anónimas
  • 5.1.2.1 Operación anónima solitaria
  • 5.2 Campos
  • 5.2.1 Selecciones de campo en objetos, interfaces y tipos de uniones
  • 5.2.2 Fusión de selección de campo
  • 5.2.3 Selecciones de campo de hoja
  • 5.3 Argumentos
  • 5.3.1 Nombres de argumentos
  • 5.3.2 Singularidad del argumento
  • 5.3.3 Valores del argumento Tipo Corrección
  • 5.3.3.1 Valores compatibles
  • 5.3.3.2 Argumentos requeridos
  • 5.4 Fragmentos
  • 5.4.1 Declaraciones de fragmentos
  • 5.4.1.1 Unicidad del nombre del fragmento
  • 5.4.1.2 Existencia de tipo de extensión de fragmento
  • 5.4.1.3 Fragmentos en tipos compuestos
  • 5.4.1.4 Deben usarse fragmentos
  • 5.4.2 Extensiones de fragmentos
  • 5.4.2.1 Objetivo de propagación de fragmentos definido
  • 5.4.2.2 Los diferenciales de fragmentos no deben formar ciclos
  • 5.4.2.3 Se puede extender el fragmento
  • 5.4.2.3.1 Extensiones de objeto en el alcance del objeto
  • 5.4.2.3.2 Extensiones abstractas en el alcance del objeto
  • 5.4.2.3.3 Extensiones de objeto en alcance abstracto
  • 5.4.2.3.4 Extensiones abstractas en alcance abstracto
  • 5.5 Valores
  • 5.5.1 Singularidad del campo del objeto de entrada
  • 5.6Directivas
  • 5.6.1 Se definen las directivas
  • 5.7 Variables
  • 5.7.1 Singularidad variable
  • 5.7.2 Los valores predeterminados variables se escriben correctamente
  • 5.7.3 Las variables son tipos de entrada
  • 5.7.4 Todos los usos variables definidos
  • 5.7.5 Todas las variables utilizadas
  • 5.7.6 Se permiten todos los usos variables
  • 6ejecución
  • 6.1 Evaluaciones de solicitudes
  • 6.2 Variables de coacción
  • 6.3 Operaciones de evaluación
  • 6.4 Evaluación de conjuntos de selección
  • 6.5 Evaluación de un conjunto de campos agrupados
  • 6.5.1 Entradas de campo
  • 6.5.2 Evaluación normal
  • 6.5.3 Ejecución en serie
  • 6.5.4 Manejo de errores
  • 6.5.5 Anulabilidad
  • 7Respuesta
  • 7.1 Formato de serialización
  • 7.1.1 Serialización JSON
  • 7.2 Formato de respuesta
  • 7.2.1 Datos
  • 7.2.2 Errores
  • AApéndice: Convenciones de notación
  • A.1 Gramática sin contexto
  • A.2 Gramática léxica y sintáctica
  • A.3 Notación Gramática
  • A.4 Semántica de gramática
  • A.5 Algoritmos
  • BAppendix: Resumen de gramática
  • B.1 Fichas ignoradas
  • B.2 Fichas Léxicas
  • B.3 Documento de consulta

Es tu elección:

Falcor JS VERSUS documentado simple y dulce, herramienta de grado empresarial enorme con documentación larga y avanzada como GraphQL y Relay

Como dije antes, si usted es un desarrollador front-end que comprende la idea de usar JSON, la implementación de gráficos JSON del equipo de Falcor es la mejor manera de hacer su proyecto de desarrollo completo.


13
Respuesta subjetiva No incluye comparación técnica. Más apropiado como comentario.
Gajus

2
@GajusKuizinas respuesta subjetiva? Verifique las documentaciones de ambos ;-) Solo digo que Falcor es cada vez más rápido de aprender, y eso es un hecho ;-) también he estado trabajando con ambos: la simplicidad ganará a largo plazo incluso si FB está haciendo un gran trabajo trabajo con bombo ;-)
PrzeoR

2
Eso es simplemente una opinión y no responde a la pregunta en absoluto.
Michał Miszczyszyn

14
Creo que esta es una gran respuesta, hasta el punto, la curva de aprendizaje de una tecnología no es necesariamente subjetiva y se puede medir fácilmente, los hechos se presentan aquí para poder extraer conclusiones claras. En el mundo real, los profesionales serios toman en consideración estos hechos. Después de todo, esta es una pregunta abierta, que claramente se beneficia de las respuestas como esta.
bmaggi

2
Estoy de acuerdo con @MorgenCheng, ¡voté a favor! He estado haciendo rondas las últimas semanas evaluando GraphQL / Relay, Cashay, Redux y ahora Falcor, y estoy 100% de acuerdo con PrzeoR. Relay y GraphQL son tecnologías increíbles, pero requieren mucha más capacidad intelectual y son más difíciles de asimilar para los novatos. Hay una cantidad significativa de aprendizaje involucrado. La desventaja de Falcor es la falta de ejemplos para una aplicación completa basada en CRUD. Y me encantaría ver proyectos de PostgreSQL y RethinkDB escupiendo JsonGraph.
Dom

5

En resumen, Falcor o GraphQL o Restful resuelven el mismo problema: proporcionan una herramienta para consultar / manipular datos de manera efectiva.

En qué se diferencian es en cómo presentan sus datos:

  • Falcor quiere que pienses que sus datos son un árbol JSON virtual muy grande, y usa get , set y call para leer, escribir datos.
  • GraphQL quiere que piense en sus datos como un grupo de objetos mecanografiados predefinidos, y utiliza consultas y mutaciones para leer, escribir datos.
  • Restful quiere que pienses en sus datos como un grupo de recursos, y usa verbos HTTP para leer, escribir datos.

Siempre que necesitemos proporcionar datos para el usuario, terminamos con algo como: cliente -> consulta -> {una consulta de traducción de capa en operaciones de datos} -> datos.

Después de luchar con GraphQL, Falcor y JSON API (e incluso ODdata), escribí mi propia capa de consulta de datos . Es más simple, más fácil de aprender y más equivalente con GraphQL.

Compruébalo en:
https://github.com/giapnguyen74/nextql

También se integra con featherjs para consulta / mutación en tiempo real. https://github.com/giapnguyen74/nextql-feathers


2

OK, solo comienza con una diferencia simple pero importante, ¡ GraphQL es una consulta basada en Falcor !

¿Pero cómo te ayudan?

Básicamente, ambos nos ayudan a administrar y consultar datos, pero GraphQL tiene un modelo de requisitos / res y devuelve los datos como JSON , básicamente la idea en GraphQL es tener una sola solicitud para obtener todos sus datos en un solo objetivo ... Además, tener una respuesta exacta al tener una solicitud exacta, entonces algo para ejecutar en Internet de baja velocidad y dispositivos móviles, como redes 3G ... Entonces, si tiene muchos usuarios móviles o, por alguna razón, le gustaría tener menos solicitudes y una respuesta más rápida , use GraphQL ... Si bien Faclor no está muy lejos de esto, siga leyendo ...

Por otro lado, Falcor by Netflix, por lo general, tiene una solicitud adicional (generalmente más de una vez) para recuperar todos sus datos, a pesar de que intentan mejorarlo a una sola solicitud ... Falcor es más limitado para consultas y no tiene pre ayudantes de consulta definidos como rango y etc.

Pero para más aclaraciones, veamos cómo cada uno de ellos se presenta:

GraphQL, un lenguaje de consulta para su API

GraphQL es un lenguaje de consulta para API y un tiempo de ejecución para completar esas consultas con sus datos existentes. GraphQL proporciona una descripción completa y comprensible de los datos en su API, brinda a los clientes el poder de pedir exactamente lo que necesitan y nada más, facilita la evolución de las API con el tiempo y permite poderosas herramientas para desarrolladores.

Envíe una consulta GraphQL a su API y obtenga exactamente lo que necesita, nada más y nada menos. Las consultas GraphQL siempre devuelven resultados predecibles. Las aplicaciones que usan GraphQL son rápidas y estables porque controlan los datos que obtienen, no el servidor.

Las consultas GraphQL acceden no solo a las propiedades de un recurso sino que también siguen sin problemas las referencias entre ellos. Mientras que las API REST típicas requieren cargarse desde múltiples URL, las API GraphQL obtienen todos los datos que su aplicación necesita en una sola solicitud. Las aplicaciones que usan GraphQL pueden ser rápidas incluso en conexiones de red móvil lentas.

Las API de GraphQL están organizadas en términos de tipos y campos, no en puntos finales. Acceda a todas las capacidades de sus datos desde un único punto final. GraphQL usa tipos para garantizar que las aplicaciones solo soliciten lo que es posible y proporcionen errores claros y útiles. Las aplicaciones pueden usar tipos para evitar escribir código de análisis manual.


Falcor, una biblioteca de JavaScript para obtener datos de manera eficiente

Falcor le permite representar todas sus fuentes de datos remotas como un modelo de dominio único a través de un gráfico JSON virtual. Usted codifica de la misma manera sin importar dónde estén los datos, ya sea en la memoria del cliente o en la red del servidor.

Una sintaxis de ruta similar a JavaScript hace que sea fácil acceder a tantos o tan pocos datos como desee, cuando lo desee. Usted recupera sus datos utilizando operaciones de JavaScript familiares como obtener, establecer y llamar. Si conoce sus datos, conoce su API.

Falcor atraviesa automáticamente las referencias en su gráfico y realiza solicitudes según sea necesario. Falcor maneja de manera transparente todas las comunicaciones de red, por lotes de manera oportunista y eliminando solicitudes.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.