Qual è la differenza tra Falcor e GraphQL?

GraphQL è costituito da un sistema di tipi, linguaggio di query e semantica di esecuzione, convalida statica e introspezione dei tipi, ciascuna descritta di seguito. Per guidarti attraverso ciascuno di questi componenti, abbiamo scritto un esempio progettato per illustrare i vari pezzi di GraphQL.

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

Falcor ti consente di rappresentare tutte le tue origini dati remote come un singolo modello di dominio tramite un grafico JSON virtuale. Si codifica allo stesso modo, indipendentemente da dove si trovino i dati, sia in memoria sul client che sulla rete sul server.

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

Qual è la differenza tra Falcor e GraphQL (nel contesto di Relay)?

Ho visto l' episodio angolare Air 26: FalcorJS e angolare 2 dove Jafar Husain risposte Come GraphQL paragona a FalcorJS . Questo è il riassunto (parafrasando):

• FalcorJS e GraphQL stanno affrontando lo stesso problema (interrogazione dei dati, gestione dei dati).
• La distinzione importante è che GraphQL è un linguaggio di query e FalcorJS no.
• Quando chiedi risorse a FalcorJS, chiedi esplicitamente serie finite di valori. FalcorJS supporta cose come intervalli, ad es genres[0..10]. Ma non supporta query aperte, ad es genres[0..*].
• GraphQL è basato su set: dammi tutti i record dove vero, ordina secondo questo, ecc. In questo senso, il linguaggio di query GraphQL è più potente di FalcorJS.
• Con GraphQL hai un linguaggio di query potente, ma devi interpretare quel linguaggio di query sul server.

Jafar sostiene che nella maggior parte delle applicazioni, i tipi di query che vanno dal client al server condividono la stessa forma. Pertanto, avere operazioni specifiche e prevedibili come get e set espone più opportunità per sfruttare la cache. Inoltre, molti sviluppatori hanno familiarità con la mappatura delle richieste utilizzando un semplice router nell'architettura REST.

La discussione finale risolve se la potenza fornita da GraphQL supera la complessità.

Ora ho scritto app con entrambe le biblioteche e posso essere d'accordo con tutto nel post di Gajus, ma ho trovato alcune cose diverse molto importanti nel mio uso dei framework.

• Probabilmente la più grande differenza pratica è che la maggior parte degli esempi e presumibilmente il lavoro svolto fino a questo punto su GraphQL si è concentrato sull'integrazione di GraphQL con Relay, il sistema di Facebook per l'integrazione dei widget ReactJS con i loro requisiti di dati. FalcorJS, d'altra parte, tende ad agire separatamente dal sistema di widget, il che significa che potrebbe essere più facile integrarsi in un client non React / Relay e che farà di meno automaticamente in termini di abbinamento delle dipendenze dei dati del widget con i widget.
• Il rovescio della medaglia di FalcorJS è flessibile nelle integrazioni lato client è che può essere molto motivato su come il server deve agire. FalcorJS in realtà ha una capacità "Call this Query over HTTP" diretta - anche se Jafar Husain non sembra parlarne molto - e una volta inclusi quelli, il modo in cui le librerie client reagiscono alle informazioni del server è abbastanza simile tranne che GraphQL / Relay aggiunge un livello di configurazione. In FalcorJS, se stai restituendo un valore per il film, il tuo valore di ritorno è meglio dire "film", mentre in GraphQL puoi descrivere che anche se la query restituisce "film", dovresti metterlo nel datastore sul lato client come "film '. - fa parte del compromesso tra potenza e complessità menzionato da Gajus.
• Su base pratica, GraphQL e Relay sembrano essere più sviluppati. Jafar Husain ha menzionato che la prossima versione del frontend Netflix sarà in esecuzione almeno in parte su FalcorJS mentre il team di Facebook ha menzionato che stanno usando una versione dello stack GraphQL / Relay in produzione da oltre 3 anni.
• La comunità di sviluppatori open source attorno a GraphQL e Relay sembra essere fiorente. Ci sono un gran numero di progetti di supporto ben frequentati intorno a GraphQL e Relay, mentre personalmente ne ho trovati pochissimi intorno a FalcorJS. Anche il repository github di base per Relay ( https://github.com/facebook/relay/pulse ) è significativamente più attivo del repository github per FalcorJS ( https://github.com/netflix/falcor/pulse ). Quando ho estratto per la prima volta il repository di Facebook, gli esempi sono stati interrotti. Ho aperto un problema con github ed è stato risolto in poche ore. D'altra parte, il problema github che ho aperto su FalcorJS non ha avuto risposta ufficiale in due settimane.

Lee Byron, uno degli ingegneri dietro GraphQL, ha fatto un AMA sull'hashnode , ecco la sua risposta quando viene posta questa domanda:

• Falcor restituisce osservabili, solo valori GraphQL. Per come Netflix voleva usare Falcor, questo ha molto senso per loro. Effettuano più richieste e presentano dati non appena sono pronti, ma significa anche che lo sviluppatore del client deve lavorare direttamente con gli osservabili. GraphQL è un modello di richiesta / risposta e restituisce JSON, che è banalmente facile da usare. Il relè aggiunge un po 'del dinamismo che Falcor presenta pur mantenendo solo valori semplici.
• Tipo di sistema. GraphQL è definito in termini di un sistema di tipi e questo ci ha permesso di creare molti strumenti interessanti come GraphiQL, generatori di codice, rilevamento di errori, ecc. Falcor è molto più dinamico, che è prezioso a sé stante ma limita la capacità di fare questo genere di cose.
• Utilizzo della rete. GraphQL è stato originariamente progettato per far funzionare il feed di notizie di Facebook su dispositivi di fascia bassa su reti anche di fascia più bassa, quindi fa di tutto per permetterti di dichiarare tutto ciò di cui hai bisogno in una singola richiesta di rete al fine di ridurre al minimo la latenza. Falcor, d'altra parte, spesso esegue più viaggi di andata e ritorno per raccogliere dati aggiuntivi. Questo è davvero solo un compromesso tra la semplicità del sistema e il controllo della rete. Per Netflix, hanno anche a che fare con dispositivi di fascia bassa (ad es. Roku stick) ma si presume che la rete sarà abbastanza buona per lo streaming video.

Modifica: Falcor può effettivamente batchare le richieste , rendendo inaccurato il commento sull'uso della rete. Grazie a @PrzeoR

AGGIORNAMENTO: Ho trovato il commento molto utile sotto il mio post che voglio condividere con te come una cosa complementare al contenuto principale:

Per quanto riguarda la mancanza di esempi, puoi trovare utile il repository awesome-falcorjs, ci sono diversi esempi di utilizzo CRUD di Falcor: https://github.com/przeor/awesome-falcorjs ... In secondo luogo, c'è un libro chiamato " Mastering Full Stack React Development "che include anche Falcor (buon modo per imparare ad usarlo):

POSTO ORGINALE SOTTO:

FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) è molto più semplice per essere efficiente rispetto a Relay / GraphQL.

La curva di apprendimento per GraphQL + Relay è ENORME:

Nel mio breve riassunto: scegli Falcor. Usa Falcor nel tuo prossimo progetto fino a quando non avrai un budget elevato e un sacco di tempo di apprendimento per il tuo team, quindi utilizza RELAY + GRAPHQL.

GraphQL + Relay ha un'enorme API in cui devi essere efficiente. Falcor ha una piccola API ed è molto facile da comprendere per qualsiasi sviluppatore front-end che abbia familiarità con JSON.

Se hai un progetto AGILE con risorse limitate -> scegli FalcorJS!

IL MIO SOGGETTO: FalcorJS è più semplice del 500% per essere efficiente in javascript full-stack.

Ho anche pubblicato alcuni starter kit FalcorJS sul mio progetto (+ altri progetti di esempio di falcor full-stack): https://www.github.com/przeor

Per essere più nei dettagli tecnici:

1) Quando si utilizza Falcor, è possibile utilizzare sia sul front-end che sul back-end:

importare falcor da 'falcor';

e quindi costruire il tuo modello basato su.

... hai bisogno anche di due librerie che sono semplici da usare sul backend: a) falcor-express - lo usi una volta (es. 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-router - qui si definiscono route SEMPLICI (es. route: '_view.length' ). Fonte: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Falcor è un gioco da ragazzi in termini di curva di apprendimento.

Puoi anche vedere la documentazione che è molto più semplice della lib di FB e consultare anche l'articolo " perché dovresti preoccuparti di falcorjs (netflix falcor) ".

2) Relay / GraphQL è più probabile come un enorme strumento aziendale.

Ad esempio, hai due diverse documentazioni di cui si parla separatamente:

a) Relay: https://facebook.github.io/relay/docs/tutorial.html - Contenitori - Percorsi - Contenitore radice - Stato pronto - Mutazioni - Livello di rete - Plugin relè Babel - GRAPHQL

• Specifiche dei relè GraphQL
• Identificazione dell'oggetto
• Connessione
• mutazioni
• Ulteriori letture

• RIFERIMENTO API

• staffetta

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

• INTERFACCE

• RelayNetworkLayer

• RelayMutationRequest
• RelayQueryRequest

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

• 2Language
• 2.1 Testo sorgente
• 2.1.1Unicode
• 2.1.2 Spazio bianco
• 2.1.3 Terminatori di linea
• 2.1.4Comments
• 2.1.5 Virgole non significative
• 2.1.6 Token lessicali
• 2.1.7 Token ignorati
• 2.1.8Punctuators
• 2.1.9Names
• 2.2 Documento di richiesta
• 2.2.1Operations
• 2.2.2 Set di selezione
• 2.2.3Fields
• 2.2.4Arguments
• 2.2.5 Alias ​​campo
• 2.2.6Fragments
• 2.2.6.1 Condizioni del tipo
• 2.2.6.2Inline Fragments
• 2.2.7 Valori di input
• 2.2.7.1Int Value
• 2.2.7.2 Valore di galleggiamento
• 2.2.7.3Boolean Value
• 2.2.7.4 Valore stringa
• 2.2.7.5 Valore di entrata
• 2.2.7.6 Valore elenco
• 2.2.7.7Input Valori oggetto
• 2.2.8Variables
• 2.2.8.1 Uso variabile all'interno dei frammenti
• 2.2.9 Tipi di input
• 2.2.10Directives
• 2.2.10.1 Direttive sui frammenti
• Sistema 3Type
• 3.1Types
• 3.1.1Scalars
• 3.1.1.1 Scalari integrati
• 3.1.1.1.1Int
• 3.1.1.1.2Float
• 3.1.1.1.3String
• 3.1.1.1.4Boolean
• 3.1.1.1.5ID
• 3.1.2Objects
• 3.1.2.1 Argomenti del campo oggetto
• 3.1.2.2 Svalutazione campo oggetto
• 3.1.2.3 Convalida del tipo di oggetto
• 3.1.3Interfaces
• 3.1.3.1 Convalida del tipo di interfaccia
• 3.1.4Unions
• 3.1.4.1 Convalida del tipo di unione
• 3.1.5Enums
• 3.1.6 Oggetti di input
• 3.1.7Lists
• 3.1.8Non-Null
• 3.2Directives
• 3.2.1@skip
• 3.2.2@include
• 3.3 Tipi di avvio
• 4Introspection
• 4.1 Principi generali
• 4.1.1 Convenzioni di denominazione
• 4.1.2Documentation
• 4.1.3Deprecation
• 4.1.4 Digitare Nome Introspection
• 4.2 Introspezione dello schema
• 4.2.1 Il tipo "__Type"
• 4.2.2 Tipi di tipi
• 4.2.2.1Scalar
• 4.2.2.2Object
• 4.2.2.3Union
• 4.2.2.4Interface
• 4.2.2.5Enum
• 4.2.2.6 Oggetto di input
• 4.2.2.7List
• 4.2.2.8Non-null
• 4.2.2.9 Elenco combinato e Non null
• 4.2.3 Il tipo __Campo
• 4.2.4 Il tipo __InputValue
• 5Validation
• 5.1Operations
• 5.1.1 Definizioni operative denominate
• 5.1.1.1 Nome operativo Unicità
• 5.1.2 Definizioni operative anonime
• 5.1.2.1 Operazione anonima solitaria
• 5.2Fields
• 5.2.1 Selezioni di campo su tipi di oggetti, interfacce e unioni
• 5.2.2 Unione selezione campo
• 5.2.3 Selezioni del campo di caduta
• 5.3Arguments
• 5.3.1 Nomi degli oggetti
• 5.3.2 Unicità degli oggetti
• 5.3.3 Validità del tipo di valori degli oggetti
• 5.3.3.1 Valori compatibili
• 5.3.3.2 Argomenti necessari
• 5.4Fragments
• 5.4.1 Dichiarazioni di frammento
• 5.4.1.1 Nome del frammento Unicità
• 5.4.1.2 Esistenza del tipo di diffusione del frammento
• 5.4.1.3 Frammenti su tipi compositi
• 5.4.1.4 I frammenti devono essere utilizzati
• 5.4.2 Diffusioni di frammenti
• 5.4.2.1 Target di diffusione del frammento definito
• 5.4.2.2 Gli spread di frammentazione non devono formare cicli
• 5.4.2.3 La diffusione del frammento è possibile
• 5.4.2.3.1Object Spreads in Object Scope
• 5.4.2.3.2 Spread astratti nell'ambito dell'oggetto
• 5.4.2.3.3 Diffusione di oggetti in ambito astratto
• 5.4.2.3.4 Spread astratti in ambito astratto
• 5.5Values
• 5.5.1 Unicità del campo oggetto di input
• 5.6Directives
• 5.6.1 Le direttive sono definite
• 5.7Variables
• 5.7.1 Unicità variabile
• 5.7.2 I valori predefiniti variabili sono digitati correttamente
• 5.7.3 I variabili sono tipi di input
• 5.7.4 Tutti gli usi delle variabili definiti
• 5.7.5Tutte le variabili utilizzate
• 5.7.6 Sono consentiti tutti gli usi variabili
• 6Execution
• 6.1Valutazione delle richieste
• 6.2 Variabili di perforazione
• 6.3Valutazione delle operazioni
• 6.4Valutazione dei set di selezione
• 6.5Valutazione di un set di campi raggruppati
• 6.5.1 Voci di campo
• 6.5.2 Valutazione normale
• 6.5.3 Esecuzione seriale
• 6.5.4 Gestione degli errori
• 6.5.5Nullability
• 7Response
• 7.1 Formato di serializzazione
• 7.1.1 Serializzazione JSON
• 7.2 Formato di risposta
• 7.2.1Data
• 7.2.2Errors
• AAppendice: Convenzioni sulla notazione
• A.1 Grammatica libera da contenuti
• A.2 Grammatica lessicale e sintattica
• A.3 Notazione grammaticale
• A.4 Semantica grammatica
• A.5Algorithms
• BAppendix: Riepilogo grammaticale
• B.1 Token ignorati
• B.2 Token lessicali
• B.3 Documento di richiesta

È la vostra scelta:

Falcor JS VERSUS semplice, dolce e breve, documentato Strumento di livello enterprise con documentazione lunga e avanzata come GraphQL e relè

Come ho detto prima, se sei un sviluppatore front-end che capisce l'idea di utilizzare JSON, l'implementazione dei grafici JSON da parte del team di Falcor è il modo migliore per realizzare il tuo progetto di sviluppo full-stack.

In breve, Falcor o GraphQL o Restful risolvono lo stesso problema: forniscono uno strumento per interrogare / manipolare i dati in modo efficace.

La differenza è nel modo in cui presentano i loro dati:

• Falcor vuole che tu pensi ai loro dati come un grande albero JSON virtuale e usa get , set e call per leggere, scrivere dati.
• GraphQL vuole che i tuoi dati vengano considerati come un gruppo di oggetti tipizzati predefiniti e utilizza query e mutazioni per leggere, scrivere dati.
• Restful vuole che tu pensi ai loro dati come un gruppo di risorse e usa i verbi HTTP per leggere, scrivere i dati.

Ogni volta che dobbiamo fornire dati per l'utente, finiamo con qualcosa che ci piace: client -> query -> {un livello traduce query in dati ops} -> dati.

Dopo aver lottato con GraphQL, Falcor e JSON API (e persino ODdata), ho scritto il mio livello di query di dati . È più semplice, più facile da imparare e più equivalente con GraphQL.

Dai un'occhiata a:
https://github.com/giapnguyen74/nextql

Si integra anche con featherjs per query / mutazione in tempo reale. https://github.com/giapnguyen74/nextql-feathers

OK, inizia da una differenza semplice ma importante, GraphQL è una query basata mentre Falcor no!

Ma come ti aiutano?

Fondamentalmente, entrambi ci aiutano a gestire e interrogare i dati, ma GraphQL ha un modello req / res e restituisce i dati come JSON , fondamentalmente l'idea in GraphQL è avere una singola richiesta per ottenere tutti i tuoi dati in un unico obiettivo ... Inoltre, avere una risposta esatta avendo una richiesta esatta, quindi qualcosa da eseguire su Internet a bassa velocità e dispositivi mobili, come le reti 3G ... Quindi se hai molti utenti mobili o per alcuni motivi ti piacerebbe avere meno richieste e una risposta più rapida , usa GraphQL ... Mentre Faclor non è troppo lontano da questo, quindi continua a leggere ...

D'altra parte, Falcor di Netflix, di solito ha una richiesta extra (di solito più di una volta) per recuperare tutti i tuoi dati, anche se stanno cercando di migliorarli in una singola richiesta ... Falcor è più limitato per le query e non ha pre helper di query definiti come range ed ecc ...

Ma per maggiori chiarimenti, vediamo come si presentano ciascuno di essi:

GraphQL, un linguaggio di query per la tua API

GraphQL è un linguaggio di query per le API e un runtime per soddisfare tali query con i dati esistenti. GraphQL fornisce una descrizione completa e comprensibile dei dati nella tua API, offre ai clienti il ​​potere di chiedere esattamente ciò di cui hanno bisogno e niente di più, facilita l'evoluzione delle API nel tempo e abilita potenti strumenti di sviluppo.

Invia una query GraphQL alla tua API e ottieni esattamente ciò di cui hai bisogno, niente di più e niente di meno. Le query GraphQL restituiscono sempre risultati prevedibili. Le app che usano GraphQL sono veloci e stabili perché controllano i dati che ottengono, non il server.

Le query GraphQL accedono non solo alle proprietà di una risorsa, ma seguono anche senza problemi i riferimenti tra di esse. Mentre le API REST tipiche richiedono il caricamento da più URL, le API GraphQL ottengono tutti i dati necessari all'app in un'unica richiesta. Le app che utilizzano GraphQL possono essere veloci anche su connessioni di rete mobili lente.

Le API GraphQL sono organizzate in termini di tipi e campi, non di endpoint. Accedi a tutte le funzionalità dei tuoi dati da un singolo endpoint. GraphQL utilizza i tipi per garantire che le app chiedano solo ciò che è possibile e forniscono errori chiari e utili. Le app possono utilizzare i tipi per evitare di scrivere codice di analisi manuale.

Falcor, una libreria JavaScript per un efficiente recupero dei dati

Falcor ti consente di rappresentare tutte le tue origini dati remote come un singolo modello di dominio tramite un grafico JSON virtuale. Si codifica allo stesso modo, indipendentemente da dove si trovino i dati, sia in memoria sul client che sulla rete sul server.

Una sintassi del percorso simile a JavaScript semplifica l'accesso a tutti i dati che desideri, quando lo desideri. Recuperi i tuoi dati utilizzando operazioni JavaScript familiari come get, set e call. Se conosci i tuoi dati, conosci la tua API.

Falcor attraversa automaticamente i riferimenti nel grafico ed effettua le richieste secondo necessità. Falcor gestisce in modo trasparente tutte le comunicazioni di rete, opportunisticamente il batch e il de-duping delle richieste.