Qual é a diferença entre Falcor e GraphQL?

O GraphQL consiste em um sistema de tipos, linguagem de consulta e semântica de execução, validação estática e introspecção de tipos, cada um deles descrito abaixo. Para guiá-lo por cada um desses componentes, escrevemos um exemplo projetado para ilustrar as várias partes do GraphQL.

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

O Falcor permite representar todas as suas fontes de dados remotas como um modelo de domínio único por meio de um gráfico JSON virtual. Você codifica da mesma maneira, não importa onde estejam os dados, seja na memória do cliente ou na rede no servidor.

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

Qual é a diferença entre Falcor e GraphQL (no contexto do relé)?

Eu assisti ao Angular Air Episode 26: FalcorJS e Angular 2, onde Jafar Husain responde como o GraphQL se compara ao FalcorJS . Este é o resumo (parafraseando):

• O FalcorJS e o GraphQL estão enfrentando o mesmo problema (consulta de dados, gerenciamento de dados).
• A distinção importante é que o GraphQL é uma linguagem de consulta e o FalcorJS não.
• Quando você solicita recursos ao FalcorJS, solicita muito explicitamente séries finitas de valores. O FalcorJS suporta coisas como intervalos, por exemplo genres[0..10]. Mas ele não suporta consultas abertas, por exemplo genres[0..*].
• O GraphQL é baseado em conjunto: dê-me todos os registros onde verdadeiro, ordene por isso, etc. Nesse sentido, a linguagem de consulta do GraphQL é mais poderosa que o FalcorJS.
• Com o GraphQL, você possui uma poderosa linguagem de consulta, mas precisa interpretá-la no servidor.

Jafar argumenta que, na maioria dos aplicativos, os tipos de consultas que vão do cliente para o servidor compartilham a mesma forma. Portanto, ter operações específicas e previsíveis como obter e definir expõe mais oportunidades de alavancar o cache. Além disso, muitos desenvolvedores estão familiarizados com o mapeamento de solicitações usando um roteador simples na arquitetura REST.

A discussão final resolve se o poder que acompanha o GraphQL supera a complexidade.

Agora escrevi aplicativos com as duas bibliotecas e posso concordar com tudo no post de Gajus, mas achei algumas coisas diferentes mais importantes no meu próprio uso das estruturas.

• Provavelmente, a maior diferença prática é que a maioria dos exemplos e, presumivelmente, o trabalho realizado até o momento no GraphQL se concentrou na integração do GraphQL ao Relay - o sistema do Facebook para integrar os widgets ReactJS com seus requisitos de dados. O FalcorJS, por outro lado, tende a agir separadamente do sistema de widgets, o que significa que pode ser mais fácil integrar-se a um cliente que não seja do React / Relay e que fará menos por você automaticamente em termos de correspondência das dependências de dados do widget com os widgets.
• O outro lado do FalcorJS ser flexível nas integrações do lado do cliente é que ele pode ser muito opinativo sobre como o servidor precisa agir. Na verdade, o FalcorJS possui o recurso "Chame esta consulta por HTTP" direto - embora Jafar Husain pareça não falar muito sobre isso - e depois de incluí-los, a maneira como as bibliotecas clientes reagem às informações do servidor é bastante semelhante, exceto que O GraphQL / Relay adiciona uma camada de configuração. No FalcorJS, se você estiver retornando um valor para filme, seu valor de retorno dirá 'filme', enquanto no GraphQL, você pode descrever que, embora a consulta retorne 'filme', você deve colocá-lo no armazenamento de dados do cliente como 'filme ' - isso faz parte da troca entre poder e complexidade que Gajus mencionou.
• Em termos práticos, o GraphQL e o Relay parecem estar mais desenvolvidos. Jafar Husain mencionou que a próxima versão do frontend da Netflix estará rodando pelo menos em parte no FalcorJS, enquanto a equipe do Facebook mencionou que eles usam alguma versão da pilha do GraphQL / Relay na produção há mais de 3 anos.
• A comunidade de desenvolvedores de código aberto em torno do GraphQL e Relay parece estar prosperando. Há um grande número de projetos de suporte bem-atendidos no GraphQL e Relay, enquanto eu pessoalmente encontrei muito poucos no FalcorJS. Além disso, o repositório base do github para o Relay ( https://github.com/facebook/relay/pulse ) é significativamente mais ativo que o repositório do github para o FalcorJS ( https://github.com/netflix/falcor/pulse ). Quando puxei o repositório do Facebook pela primeira vez, os exemplos foram quebrados. Abri um problema no github e ele foi corrigido em poucas horas. Por outro lado, a questão do github que abri no FalcorJS não teve resposta oficial em duas semanas.

Lee Byron, um dos engenheiros por trás do GraphQL, fez uma AMA no hashnode . Aqui está sua resposta quando essa pergunta é feita:

• Falcor retorna Observables, GraphQL apenas valores. Para como a Netflix queria usar o Falcor, isso faz muito sentido para eles. Eles fazem várias solicitações e apresentam dados quando estiverem prontos, mas isso também significa que o desenvolvedor do cliente precisa trabalhar diretamente com o Observables. O GraphQL é um modelo de solicitação / resposta e retorna JSON, que é trivialmente fácil de usar. O relé acrescenta um pouco do dinamismo que o Falcor apresenta, mantendo apenas os valores simples.
• Digite sistema. O GraphQL é definido em termos de um sistema de tipos, e isso nos permitiu criar muitas ferramentas interessantes, como GraphiQL, geradores de código, detecção de erros, etc. O Falcor é muito mais dinâmico, que é valioso por si só, mas limita a capacidade de executar esse tipo de coisa.
• Uso de rede. O GraphQL foi originalmente projetado para operar o feed de notícias do Facebook em dispositivos de ponta e em redes ainda mais baixas, por isso faz todo o possível para permitir que você declare tudo o que precisa em uma única solicitação de rede para minimizar a latência. O Falcor, por outro lado, costuma realizar várias viagens de ida e volta para coletar dados adicionais. Isso é realmente apenas uma troca entre a simplicidade do sistema e o controle da rede. Para a Netflix, eles também lidam com dispositivos de extremidade muito baixa (por exemplo, Roku stick), mas a suposição é de que a rede será boa o suficiente para transmitir vídeo.

Edit: O Falcor pode de fato fazer solicitações em lote , tornando impreciso o comentário sobre o uso da rede. Graças a @PrzeoR

ATUALIZAÇÃO: Encontrei o comentário muito útil no meu post que quero compartilhar com você como uma coisa complementar ao conteúdo principal:

Com relação à falta de exemplos, você pode achar útil o repo awesome-falcorjs, existem diferentes exemplos de uso de CRUD do Falcor: https://github.com/przeor/awesome-falcorjs ... Segundo, existe um livro chamado " Dominando o desenvolvimento do Full Stack React ", que também inclui o Falcor (boa maneira de aprender como usá-lo):

POST ORGINAL ABAIXO:

O FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) é muito mais simples de ser eficiente em comparação com o Relay / GraphQL.

A curva de aprendizado do GraphQL + Relay é ENORME:

No meu breve resumo: Vá para o Falcor. Use o Falcor em seu próximo projeto até que você tenha um orçamento grande e muito tempo de aprendizado para sua equipe, depois use RELAY + GRAPHQL.

O GraphQL + Relay possui uma enorme API na qual você deve ser eficiente. O Falcor possui uma pequena API e é muito fácil de entender para qualquer desenvolvedor front-end que esteja familiarizado com o JSON.

Se você tem um projeto AGILE com recursos limitados -> então vá para o FalcorJS!

MINHA opinião SUBJETIVA: O FalcorJS é 500% + mais fácil de ser eficiente em javascript de pilha completa.

Também publiquei alguns kits de iniciação do FalcorJS no meu projeto (+ mais projetos de exemplo do falcor com pilha cheia): https://www.github.com/przeor

Para ter mais detalhes técnicos:

1) Ao usar o Falcor, você pode usar o front-end e o back-end:

importar falcor de 'falcor';

e então construa seu modelo com base.

... você também precisa de duas bibliotecas simples de usar no back-end: a) falcor-express - você usa uma vez (por exemplo, app.use ('/ model.json', FalcorServer.dataSourceRoute (() => new NamesRouter ())) ). Fonte: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b) falcor-roteador - lá você define rotas SIMPLES (por exemplo, rota: '_view.length' ). Fonte: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

O Falcor é um pedaço de bolo em termos de curva de aprendizado.

Você também pode ver a documentação que é muito mais simples que a lib do FB e também verificar o artigo " por que você deve se preocupar com os falcorjs (netflix falcor) ".

2) O Relay / GraphQL é mais provável como uma grande ferramenta corporativa.

Por exemplo, você tem duas documentações diferentes que estão falando separadamente:

a) Retransmissão: https://facebook.github.io/relay/docs/tutorial.html - Contêineres - Rotas - Contêiner raiz - Estado pronto - Mutações - Camada de rede - Babel Relay Plugin - GRAPHQL

• Especificação de relé GraphQL
• Identificação de Objetos
• Conexão
• Mutações
• Leitura adicional

• REFERÊNCIA DA API

• Retransmissão

• RelayContainer
• Relay.Route
• Relay.RootContainer
• Relay.QL
• Relay.Mutation
• Relay.PropTypes
• Relay.Store

• INTERFACES

• RelayNetworkLayer

• RelayMutationRequest
• RelayQueryRequest

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

• 2Idioma
• 2.1Source Text
• 2.1.1Unicode
• 2.1.2 Espaço em branco
• 2.1.3 Terminadores de linha
• 2.1.4 Comentários
• 2.1.5Vírgulas insignificantes
• 2.1.6 Tokens lexicais
• 2.1.7 Tokens ignorados
• 2.1.8 Pontuadores
• 2.1.9 Nomes
• 2.2 Documento de consulta
• 2.2.1 Operações
• 2.2.2 Conjuntos de seleção
• 2.2.3Campos
• 2.2.4Argumentos
• 2.2.5 Alias ​​do campo
• 2.2.6 Fragmentos
• 2.2.6.1 Condições de tipo
• 2.2.6.2 Fragmentos em linha
• 2.2.7 Valores de entrada
• 2.2.7.1Int Value
• 2.2.7.2 Valor do flutuador
• 2.2.7.3 Valor booleano
• 2.2.7.4 Valor da sequência
• 2.2.7.5 Valor total
• 2.2.7.6 Valor da lista
• 2.2.7.7 Valores dos objetos de entrada
• 2.2.8 Variáveis
• 2.2.8.1 Uso variável dentro dos fragmentos
• 2.2.9 Tipos de entrada
• 2.2.10 Diretivas
• 2.2.10.1 Diretivas de fragmento
• 3Tipo Sistema
• 3.1 Tipos
• 3.1.1 Escalares
• 3.1.1.1 Escalares incorporados
• 3.1.1.1.1Int
• 3.1.1.1.2 Flutuador
• 3.1.1.1.3String
• 3.1.1.1.4Boolean
• 3.1.1.1.5ID
• 3.1.2 Objetos
• 3.1.2.1 Argumentos do campo de objeto
• 3.1.2.2Desaprovação do campo de objeto
• 3.1.2.3Validação do tipo de objeto
• 3.1.3 Interfaces
• 3.1.3.1 Validação do tipo de interface
• 3.1.4Uniões
• 3.1.4.1 Validação do tipo de união
• 3.1.5Enums
• 3.1.6 Objetos de entrada
• 3.1.7 Listas
• 3.1.8 Não nulo
• 3.2Diretivas
• 3.2.1@skip
• 3.2.2@include
• 3.3 Tipos de inicialização
• 4Introspecção
• 4.1 Princípios Gerais
• 4.1.1 Convenções de nomenclatura
• 4.1.2 Documentação
• 4.1.3 Deprecação
• 4.1.4 Introspecção de nome de tipo
• 4.2 Introspecção Esquema
• 4.2.1O tipo "__Type"
• 4.2.2 Tipos de tipos
• 4.2.2.1 Escalar
• 4.2.2.2. Objeto
• 4.2.2.3 União
• 4.2.2.4.
• 4.2.2.5Enum
• 4.2.2.6 Objeto de entrada
• 4.2.2.7Lista
• 4.2.2.8 Não nulo
• 4.2.2.9 Combinando lista e não nulo
• 4.2.3 O tipo de campo
• 4.2.4 Tipo __InputValue
• 5Validação
• 5.1 Operações
• 5.1.1 Definições de operação nomeadas
• 5.1.1.1 Exclusividade do nome da operação
• 5.1.2 Definições de operação anônimas
• 5.1.2.1 Operação anônima solitária
• 5.2Campos
• 5.2.1 Seleções de campo em tipos de objetos, interfaces e uniões
• 5.2.2Fusão de seleção de campo
• 5.2.3 Seleções de campos de folhas
• 5.3 Argumentos
• 5.3.1 Nomes de argumentos
• 5.3.2 Exclusividade do argumento
• 5.3.3 Correção do tipo de valores de argumento
• 5.3.3.1 Valores compatíveis
• 5.3.3.2 Argumentos necessários
• 5.4Fragmentos
• 5.4.1 Declarações de fragmento
• 5.4.1.1 Exclusividade do nome do fragmento
• 5.4.1.2 Existência de tipo de propagação de fragmento
• 5.4.1.3 Fragmentos em tipos compostos
• 5.4.1.4 Fragmentos devem ser usados
• 5.4.2 Spreads de fragmentos
• 5.4.2.1 Meta de spread de fragmento definida
• 5.4.2.2 Spreads de fragmentos não devem formar ciclos
• 5.4.2.3 É possível espalhar fragmentos
• 5.4.2.3.1 Spreads de objetos no escopo do objeto
• 5.4.2.3.2 Spreads abstratos no escopo do objeto
• 5.4.2.3.3 Spreads de objetos no escopo abstrato
• 5.4.2.3.4 Spreads abstratos no escopo abstrato
• 5.5Valores
• 5.5.1 Exclusividade do campo de objeto de entrada
• 5.6Diretivas
• 5.6.1 Diretivas são definidas
• 5.7Variáveis
• 5.7.1 Exclusividade variável
• 5.7.2Os valores padrão variáveis ​​são digitados corretamente
• 5.7.3As variáveis ​​são tipos de entrada
• 5.7.4Todos os usos variáveis ​​definidos
• 5.7.5Todas as variáveis ​​usadas
• 5.7.6 Todos os usos variáveis ​​são permitidos
• 6Execução
• 6.1Avaliando solicitações
• 6.2 Variáveis ​​de coagulação
• 6.3Avaliação de operações
• 6.4Avaliando conjuntos de seleção
• 6.5Avaliando um conjunto de campos agrupados
• 6.5.1 Entradas de campo
• 6.5.2 Avaliação normal
• 6.5.3 Execução serial
• 6.5.4 Manipulação de erros
• 6.5.5 Anulabilidade
• 7Response
• 7.1 Formato de serialização
• 7.1.1 Serialização JSON
• 7.2 Formato de resposta
• 7.2.1 Dados
• 7.2.2Espelhos
• AApêndice: Convenções de Notação
• A.1 Gramática livre de contexto
• A.2 Gramática lexical e sintática
• A.3 Notação gramatical
• A.4 Semântica gramatical
• A.5 Algoritmos
• BApêndice: Resumo da gramática
• B.1 Tokens ignorados
• B.2 Tokens lexicais
• B.3 Documento de consulta

É a sua escolha:

Falcor JS VERSUS simples e doce documentada simples Ferramenta de nível empresarial enorme com documentação longa e avançada como GraphQL & Relay

Como eu disse antes, se você é um desenvolvedor front-end que entende do uso do JSON, a implementação de gráficos JSON da equipe da Falcor é a melhor maneira de fazer seu projeto de desenvolvimento com pilha completa.

Em resumo, o Falcor, o GraphQL ou o Restful resolvem o mesmo problema - forneça uma ferramenta para consultar / manipular dados de maneira eficaz.

Como eles diferem é na forma como apresentam seus dados:

• O Falcor quer que você pense nos dados deles como uma grande árvore JSON virtual e usa get , set e call para ler, gravar dados.
• O GraphQL quer que você pense nos dados deles como um grupo de objetos digitados predefinidos e usa consultas e mutações para ler e gravar dados.
• Restful quer que você pense nos dados deles como um grupo de recursos e usa verbos HTTP para ler e gravar dados.

Sempre que precisamos fornecer dados para o usuário, terminamos com algo como: cliente -> consulta -> {uma camada converte a consulta em operações de dados} -> dados.

Depois de lutar com o GraphQL, Falcor e JSON API (e até com ODdata), escrevi minha própria camada de consulta de dados . É mais simples, mais fácil de aprender e mais equivalente ao GraphQL.

Confira em:
https://github.com/giapnguyen74/nextql

Ele também se integra ao featherjs para consulta / mutação em tempo real. https://github.com/giapnguyen74/nextql-feathers

OK, basta começar com uma diferença simples, mas importante, o GraphQL é uma consulta baseada no Falcor não é!

Mas como eles te ajudam?

Basicamente, ambos nos ajudam a gerenciar e consultar dados, mas o GraphQL possui um modelo de req / res e retorna os dados como JSON , basicamente a idéia no GraphQL é ter uma única solicitação para obter todos os seus dados em um objetivo ... tenha uma resposta exata com uma solicitação exata. Portanto, algo para ser executado em Internet e dispositivos móveis de baixa velocidade, como redes 3G ... Portanto, se você tiver muitos usuários móveis ou, por algum motivo, gostaria de receber menos solicitações e respostas mais rápidas , use GraphQL ... Enquanto o Faclor não esteja muito longe disso, continue lendo ...

Por outro lado, o Falcor da Netflix, geralmente tem uma solicitação extra (geralmente mais de uma vez) para recuperar todos os seus dados, mesmo que eles tentem aprimorá- los para um único requisito ... O Falcor é mais limitado para consultas e não possui pré- requisitos. auxiliares de consulta definidos como intervalo e etc ...

Mas, para mais esclarecimentos, vamos ver como cada um deles se apresenta:

GraphQL, uma linguagem de consulta para sua API

O GraphQL é uma linguagem de consulta para APIs e um tempo de execução para atender essas consultas com os dados existentes. O GraphQL fornece uma descrição completa e compreensível dos dados em sua API, oferece aos clientes o poder de solicitar exatamente o que eles precisam e nada mais, facilita a evolução das APIs ao longo do tempo e permite poderosas ferramentas de desenvolvedor.

Envie uma consulta GraphQL à sua API e obtenha exatamente o que você precisa, nada mais e nada menos. As consultas do GraphQL sempre retornam resultados previsíveis. Os aplicativos que usam o GraphQL são rápidos e estáveis, porque controlam os dados que obtêm, não o servidor.

As consultas do GraphQL acessam não apenas as propriedades de um recurso, mas também seguem suavemente as referências entre eles. Embora as APIs REST típicas exijam o carregamento de vários URLs, as APIs do GraphQL obtêm todos os dados que seu aplicativo precisa em uma única solicitação. Aplicativos que usam o GraphQL podem ser rápidos, mesmo em conexões de rede móveis lentas.

As APIs do GraphQL são organizadas em termos de tipos e campos, não terminais. Acesse todos os recursos de seus dados a partir de um único terminal. O GraphQL usa tipos para garantir que os aplicativos solicitem apenas o que é possível e forneçam erros claros e úteis. Os aplicativos podem usar tipos para evitar a criação de código de análise manual.

Falcor, uma biblioteca JavaScript para busca eficiente de dados

O Falcor permite representar todas as suas fontes de dados remotas como um modelo de domínio único por meio de um gráfico JSON virtual. Você codifica da mesma maneira, não importa onde estejam os dados, seja na memória do cliente ou na rede no servidor.

Uma sintaxe de caminho semelhante ao JavaScript facilita o acesso à quantidade de dados que você deseja, quando desejar. Você recupera seus dados usando operações JavaScript familiares, como obter, definir e ligar. Se você conhece seus dados, conhece sua API.

O Falcor percorre automaticamente as referências em seu gráfico e faz solicitações conforme necessário. O Falcor lida de forma transparente com todas as comunicações de rede, solicitando em lotes e desduplicando oportunamente.