graphql relayjs falcor

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



relayjs (6)

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)?

ACTUALIZACIÓN: He encontrado un comentario muy útil debajo de mi publicación que quiero compartir con ustedes como un elemento complementario del contenido principal:

Con respecto a la falta de ejemplos, puede encontrar útil el repositorio de awesome-falcorjs, hay diferentes ejemplos de 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):

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:

En mi breve resumen: ve por Falcor. Use Falcor en su próximo proyecto hasta que 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) falcor-router: 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 " reactjs.co/2016/02/03/… ".

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 listo - 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.9Nombres
  • 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 Valor
  • 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
  • Apéndice AA: 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:

Simple y brevemente documentada Falcor JS VERSUS 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, entonces la implementación de gráficos JSON del equipo de Falcor es la mejor manera de hacer su proyecto de desarrollo completo.

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 momento 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 sobre 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 la película, su valor de retorno mejor dice ''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.

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

He visto el Episodio 26 de Angular Air: FalcorJS y Angular 2, donde Jafar Husain responde cómo https://github.com/facebook/graphql 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á basado en conjuntos: 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 potente 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 memoria 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.

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 de 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 se presentan cada uno de ellos:

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 a lo largo del 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 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 pidan 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. Recuperas tus datos usando operaciones familiares de JavaScript como get, set y call. 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.

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 de nuevo 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 se diseñó originalmente para operar las 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 con el fin de 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 manejan 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 incorrecto. Gracias a @PrzeoR