Was ist der Unterschied zwischen Falcor und GraphQL?


163

GraphQL besteht aus einem Typsystem, einer Abfragesprache und einer Ausführungssemantik, einer statischen Validierung und einer Typ-Introspektion, die jeweils unten beschrieben werden. Um Sie durch jede dieser Komponenten zu führen, haben wir ein Beispiel geschrieben, das die verschiedenen Teile von GraphQL veranschaulicht.

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

Mit Falcor können Sie alle Ihre entfernten Datenquellen als ein einzelnes Domänenmodell über ein virtuelles JSON-Diagramm darstellen. Sie codieren auf dieselbe Weise, unabhängig davon, wo sich die Daten befinden, ob im Speicher auf dem Client oder über das Netzwerk auf dem Server.

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

Was ist der Unterschied zwischen Falcor und GraphQL (im Kontext von Relay)?


5
Schauen Sie sich diesen Podcast an, in dem Jafar über den Unterschied zwischen Relay / GraphQL und Falcor / JSON Graph spricht. youtu.be/WL54eYbTJUw?t=53m55s
gdi2290

Antworten:


131

Ich habe mir die Angular Air Episode 26: FalcorJS und Angular 2 angesehen, in der Jafar Husain antwortet, wie GraphQL mit FalcorJS verglichen wird . Dies ist die Zusammenfassung (Paraphrasierung):

  • FalcorJS und GraphQL lösen das gleiche Problem (Abfragen von Daten, Verwalten von Daten).
  • Der wichtige Unterschied besteht darin, dass GraphQL eine Abfragesprache ist und FalcorJS nicht.
  • Wenn Sie FalcorJS nach Ressourcen fragen, fragen Sie sehr explizit nach endlichen Werteserien. FalcorJS unterstützt Dinge wie Bereiche, z genres[0..10]. Offene Abfragen, z genres[0..*].
  • GraphQL ist satzbasiert: Geben Sie mir alle Datensätze, wo sie wahr sind, ordnen Sie sie nach dieser Reihenfolge usw. In diesem Sinne ist die GraphQL-Abfragesprache leistungsfähiger als FalcorJS.
  • Mit GraphQL haben Sie eine leistungsstarke Abfragesprache, aber Sie müssen diese Abfragesprache auf dem Server interpretieren.

Jafar argumentiert, dass in den meisten Anwendungen die Abfragetypen, die vom Client zum Server gehen, dieselbe Form haben. Daher bietet eine bestimmte und vorhersehbare Operation wie get und set mehr Möglichkeiten, den Cache zu nutzen. Darüber hinaus sind viele Entwickler mit der Zuordnung der Anforderungen mithilfe eines einfachen Routers in der REST-Architektur vertraut.

In der Enddiskussion geht es darum, ob die mit GraphQL verbundene Leistung die Komplexität überwiegt.


82

Ich habe jetzt Apps mit beiden Bibliotheken geschrieben und kann mit allem in Gajus 'Beitrag einverstanden sein, fand aber einige verschiedene Dinge, die für meine eigene Verwendung der Frameworks am wichtigsten sind.

  • Der wahrscheinlich größte praktische Unterschied besteht darin, dass sich die meisten Beispiele und vermutlich bis zu diesem Zeitpunkt in GraphQL durchgeführten Arbeiten auf die Integration von GraphQL in Relay konzentriert haben - das Facebook-System zur Integration von ReactJS-Widgets in ihre Datenanforderungen. FalcorJS hingegen agiert in der Regel getrennt vom Widget-System. Dies bedeutet, dass die Integration in einen Nicht-React / Relay-Client möglicherweise einfacher ist und dass Sie automatisch weniger für die Zuordnung von Widget-Datenabhängigkeiten zu Widgets tun.
  • Die Kehrseite von FalcorJS, das bei clientseitigen Integrationen flexibel ist, ist, dass es sehr einschätzend darüber sein kann, wie der Server handeln muss. FalcorJS verfügt tatsächlich über die direkte Funktion "Diese Abfrage über HTTP aufrufen" - obwohl Jafar Husain nicht viel darüber zu sprechen scheint - und wenn Sie diese einbeziehen, ist die Art und Weise, wie die Clientbibliotheken auf Serverinformationen reagieren, bis auf diese ziemlich ähnlich GraphQL / Relay fügt eine Konfigurationsebene hinzu. Wenn Sie in FalcorJS einen Wert für einen Film zurückgeben, lautet Ihr Rückgabewert besser "Film", während Sie in GraphQL beschreiben können, dass Sie, obwohl die Abfrage "Film" zurückgibt, diesen Wert als "Film" in den clientseitigen Datenspeicher einfügen sollten '. - Dies ist Teil des Kompromisses zwischen Macht und Komplexität, den Gajus erwähnt hat.
  • Auf praktischer Basis scheinen GraphQL und Relay weiter entwickelt zu sein. Jafar Husain hat erwähnt, dass die nächste Version des Netflix-Frontends zumindest teilweise auf FalcorJS ausgeführt wird, während das Facebook-Team erwähnt hat, dass sie seit über 3 Jahren eine Version des GraphQL / Relay-Stacks in der Produktion verwenden.
  • Die Open-Source-Entwickler-Community rund um GraphQL und Relay scheint zu florieren. Es gibt eine große Anzahl gut besuchter unterstützender Projekte rund um GraphQL und Relay, während ich persönlich nur sehr wenige rund um FalcorJS gefunden habe. Auch das Basis-Github-Repository für Relay ( https://github.com/facebook/relay/pulse ) ist wesentlich aktiver als das Github-Repository für FalcorJS ( https://github.com/netflix/falcor/pulse ). Als ich das Facebook-Repo zum ersten Mal zog, waren die Beispiele gebrochen. Ich habe ein Github-Problem geöffnet und es wurde innerhalb weniger Stunden behoben. Andererseits hat die Github-Ausgabe, die ich auf FalcorJS eröffnet habe, seit zwei Wochen keine offizielle Antwort mehr erhalten.

1
GraphQL (2012) gab es schon lange vor React and Relay, daher ist Ihr erster Punkt möglicherweise nicht ganz richtig.
Burgi

Du könntest Recht haben. Ich bin kein Facebooker, daher kann ich nicht wirklich mit der Geschichte sprechen. Mein Kommentar stammt eher aus dem aktuellen Stand der Dokumentation und der Gespräche von Facebook. Sie wurden der Welt als Gefährten vorgestellt ( facebook.github.io/react/blog/2015/02/20/… ) und beide gehen ziemlich weit zurück. Ich habe in Kommentaren vom Anfang 2015 einige vage Handbewegungen über Relay gesehen, die 3 Jahre zurückliegen, so dass es möglich ist, dass beide mehrere Jahre intern entwickelt wurden, bevor sie der Außenwelt präsentiert wurden. Aber ich habe sicherlich keine besonderen Kenntnisse.
OverclockedTim

25

Lee Byron, einer der Ingenieure hinter GraphQL, hat eine AMA auf dem Hashnode durchgeführt . Hier ist seine Antwort, wenn diese Frage gestellt wird:

  • Falcor gibt Observables zurück, GraphQL nur Werte. Für die Art und Weise, wie Netflix Falcor verwenden wollte, ist dies für sie sehr sinnvoll. Sie stellen mehrere Anforderungen und präsentieren Daten, sobald sie fertig sind. Dies bedeutet jedoch auch, dass der Client-Entwickler direkt mit den Observables arbeiten muss. GraphQL ist ein Anforderungs- / Antwortmodell und gibt JSON zurück, das dann einfach zu verwenden ist. Relay fügt einen Teil der Dynamik hinzu, die Falcor bietet, während nur einfache Werte verwendet werden.
  • Typ System. GraphQL wird als Typsystem definiert, und so konnten wir viele interessante Tools wie GraphiQL, Codegeneratoren, Fehlererkennung usw. erstellen. Falcor ist viel dynamischer, was an sich wertvoll ist, aber die Möglichkeiten einschränkt so etwas.
  • Netzwerknutzung. GraphQL wurde ursprünglich für den Betrieb des Facebook-Newsfeeds auf Low-End-Geräten in noch niedrigeren Netzwerken entwickelt. Daher ist es sehr wichtig, dass Sie alles, was Sie benötigen, in einer einzigen Netzwerkanforderung deklarieren können, um die Latenz zu minimieren. Falcor hingegen führt häufig mehrere Rundreisen durch, um zusätzliche Daten zu sammeln. Dies ist wirklich nur ein Kompromiss zwischen der Einfachheit des Systems und der Steuerung des Netzwerks. Für Netflix handelt es sich auch um sehr Low-End-Geräte (z. B. Roku-Stick), aber die Annahme ist, dass das Netzwerk gut genug ist, um Videos zu streamen.

Edit: Falcor kann in der Tat Batch - Anforderungen , so dass der Kommentar über die Netzwerknutzung ungenau. Vielen Dank an @PrzeoR


4
NICHT WAHR -> "" Falcor hingegen führt häufig mehrere Roundtrips durch, um zusätzliche Daten zu sammeln. Dies ist eigentlich nur ein Kompromiss zwischen der Einfachheit des Systems und der Steuerung des Netzwerks. "". Überprüfen Sie einfach die Falcor Batch-Funktionalität und sie ist gleich oder sogar besser als in Relay.
PrzeoR

1
@PrzeoR Danke für die Korrektur! Ich habe den Beitrag bearbeitet!
YasserKaddour

Gern geschehen :-) im Zusammenhang mit FalcorJS Weitere Informationen finden Sie hier: reactjs.co/2016/02/03/…
PrzeoR

Großartiger Artikel Falcor ist in der Tat großartig, leider bin ich ein Scala-Entwickler und es gibt keine Falcor-Implementierung in Scala und in einer anderen Sprache, aber es gibt Sangria, eine ausgezeichnete GraphQL-Implementierung in Scala
YasserKaddour

Und es gibt andere Alternativen zu Relais, die Redux wie Apollo-Client und Cashay verwenden
YasserKaddour

21

UPDATE: Ich habe den sehr nützlichen Kommentar unter meinem Beitrag gefunden, den ich als Ergänzung zum Hauptinhalt mit Ihnen teilen möchte: Geben Sie hier die Bildbeschreibung ein

In Bezug auf das Fehlen von Beispielen finden Sie das Repo von awesome-falcorjs benutzerfreundlich. Es gibt verschiedene Beispiele für die CRUD-Verwendung eines Falcor: https://github.com/przeor/awesome-falcorjs ... Zweitens gibt es ein Buch mit dem Titel " Mastering Full Stack React Development ", zu dem auch Falcor gehört (ein guter Weg, um zu lernen, wie man es benutzt):

Geben Sie hier die Bildbeschreibung ein

ORGINAL POST UNTEN:

FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) ist im Vergleich zu Relay / GraphQL viel einfacher effizient zu sein.

Die Lernkurve für GraphQL + Relay ist RIESIG: Geben Sie hier die Bildbeschreibung ein

In meiner kurzen Zusammenfassung: Gehen Sie für Falcor. Verwenden Sie Falcor in Ihrem nächsten Projekt, bis Sie ein großes Budget und viel Lernzeit für Ihr Team haben. Verwenden Sie dann RELAY + GRAPHQL.

GraphQL + Relay verfügt über eine große API, in der Sie effizient sein müssen. Falcor verfügt über eine kleine API und ist für jeden Front-End-Entwickler, der mit JSON vertraut ist, sehr einfach zu verstehen.

Wenn Sie ein AGILE-Projekt mit begrenzten Ressourcen haben -> dann entscheiden Sie sich für FalcorJS!

MEINE SUBJEKTIVE Meinung: FalcorJS ist 500% + einfacher, um in Full-Stack-Javascript effizient zu sein.

Ich habe auch einige FalcorJS-Starter-Kits für mein Projekt veröffentlicht (+ weitere Full-Stack-Falcor-Beispielprojekte): https://www.github.com/przeor

Um mehr über technische Details zu erfahren:

1) Wenn Sie Falcor verwenden, können Sie sowohl im Frontend als auch im Backend Folgendes verwenden:

Import von Falcor aus 'Falcor';

und bauen Sie dann Ihr Modell basierend auf.

... Sie benötigen außerdem zwei Bibliotheken, die im Backend einfach zu verwenden sind: a) falcor-express - Sie verwenden es einmal (z. B. app.use ('/ model.json', FalcorServer.dataSourceRoute (() => new NamesRouter) ())) ). Quelle: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b) Falcor-Router - dort definieren Sie EINFACHE Routen (zB Route: '_view.length' ). Quelle: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Falcor ist ein Kinderspiel in Bezug auf die Lernkurve.

Sie können auch eine Dokumentation sehen, die viel einfacher ist als die Bibliothek von FB, und den Artikel " Warum Sie sich für Falcorjs (Netflix Falcor) interessieren sollten " lesen .

2) Relay / GraphQL ähnelt eher einem riesigen Unternehmenstool.

Sie haben beispielsweise zwei verschiedene Dokumentationen, über die separat gesprochen wird:

a) Relay: https://facebook.github.io/relay/docs/tutorial.html - Container - Routen - Root-Container - Bereitschaftszustand - Mutationen - Netzwerkschicht - Babel-Relay-Plugin - GRAPHQL

  • GraphQL-Relay-Spezifikation
  • Objektidentifikation
  • Verbindung
  • Mutationen
  • Weiterführende Literatur
  • API-REFERENZ

  • Relais

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

  • RelayNetworkLayer

  • RelayMutationRequest
  • RelayQueryRequest

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

  • 2Sprache
  • 2.1Quelltext
  • 2.1.1Unicode
  • 2.1.2Weißraum
  • 2.1.3Leitungsterminatoren
  • 2.1.4Kommentare
  • 2.1.5 Unwichtige Kommas
  • 2.1.6 Sexuelle Token
  • 2.1.7 Ignorierte Token
  • 2.1.8Punktzeichen
  • 2.1.9Namen
  • 2.2 Abfragedokument
  • 2.2.1Operationen
  • 2.2.2Auswahlsätze
  • 2.2.3Felder
  • 2.2.4Argumente
  • 2.2.5Feldalias
  • 2.2.6Fragmente
  • 2.2.6.1Typbedingungen
  • 2.2.6.2 Inline-Fragmente
  • 2.2.7Eingabewerte
  • 2.2.7.1Int Wert
  • 2.2.7.2Float-Wert
  • 2.2.7.3Boolescher Wert
  • 2.2.7.4String-Wert
  • 2.2.7.5Enum Value
  • 2.2.7.6Listenwert
  • 2.2.7.7Eingabeobjektwerte
  • 2.2.8Variablen
  • 2.2.8.1Variable Verwendung innerhalb von Fragmenten
  • 2.2.9Eingabetypen
  • 2.2.10Directives
  • 2.2.10.1Fragment-Richtlinien
  • 3Type System
  • 3.1Typen
  • 3.1.1Skalare
  • 3.1.1.1 Eingebaute Skalare
  • 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.2Objekte
  • 3.1.2.1Objektfeldargumente
  • 3.1.2.2Objektfeldverfall
  • 3.1.2.3Objekttypüberprüfung
  • 3.1.3 Schnittstellen
  • 3.1.3.1 Validierung des Schnittstellentyps
  • 3.1.4Unionen
  • 3.1.4.1 Überprüfung des Unionstyps
  • 3.1.5Enums
  • 3.1.6Eingabeobjekte
  • 3.1.7Listen
  • 3.1.8Non-Null
  • 3.2Directives
  • 3.2.1@skip
  • 3.2.2@include
  • 3.3Typen starten
  • 4Introspektion
  • 4.1Allgemeine Grundsätze
  • 4.1.1 Namenskonventionen
  • 4.1.2Dokumentation
  • 4.1.3 Verachtung
  • 4.1.4Typ Name Introspection
  • 4.2Schema-Selbstbeobachtung
  • 4.2.1Der Typ "__Type"
  • 4.2.2Typen
  • 4.2.2.1Skalar
  • 4.2.2.2Objekt
  • 4.2.2.3Union
  • 4.2.2.4Interface
  • 4.2.2.5Enum
  • 4.2.2.6Eingabeobjekt
  • 4.2.2.7Liste
  • 4.2.2.8Non-null
  • 4.2.2.9Kombination kombinieren und nicht Null
  • 4.2.3Der Feldtyp
  • 4.2.4Der __InputValue-Typ
  • 5Validierung
  • 5.1Operationen
  • 5.1.1 Definierte Betriebsdefinitionen
  • 5.1.1.1 Eindeutigkeit des Betriebsnamens
  • 5.1.2Anonyme Betriebsdefinitionen
  • 5.1.2.1 Einzelne anonyme Operation
  • 5.2Felder
  • 5.2.1Feldauswahl für Objekte, Schnittstellen und Gewerkschaftstypen
  • 5.2.2 Zusammenführen der Feldauswahl
  • 5.2.3 Blattfeldauswahl
  • 5.3Argumente
  • 5.3.1Argumentnamen
  • 5.3.2 Eindeutigkeit des Arguments
  • 5.3.3Argument Values ​​Type Correctness
  • 5.3.3.1Kompatible Werte
  • 5.3.3.2 Erforderliche Argumente
  • 5.4Fragmente
  • 5.4.1Fragmenterklärungen
  • 5.4.1.1 Eindeutigkeit des Fragmentnamens
  • 5.4.1.2Fragment Spread Type Existence
  • 5.4.1.3Fragmente auf zusammengesetzten Typen
  • 5.4.1.4Fragmente müssen verwendet werden
  • 5.4.2Fragment Spreads
  • 5.4.2.1Fragment Spread Ziel definiert
  • 5.4.2.2Fragment-Spreads dürfen keine Zyklen bilden
  • 5.4.2.3Fragment Spread ist möglich
  • 5.4.2.3.1Objektspreads im Objektbereich
  • 5.4.2.3.2Abstrakt-Spreads im Objektbereich
  • 5.4.2.3.3Objektspreads im abstrakten Bereich
  • 5.4.2.3.4Abstrakt-Spreads im abstrakten Bereich
  • 5.5Werte
  • 5.5.1 Eindeutigkeit des Eingabeobjektfelds
  • 5.6Directives
  • 5.6.1Directives sind definiert
  • 5.7Variablen
  • 5.7.1Variable Einzigartigkeit
  • 5.7.2Variable Standardwerte werden korrekt eingegeben
  • 5.7.3Variablen sind Eingabetypen
  • 5.7.4Alle Variablenverwendungen definiert
  • 5.7.5Alle verwendeten Variablen
  • 5.7.6Alle Variablenverwendungen sind zulässig
  • 6Ausführung
  • 6.1Auswertung von Anfragen
  • 6.2 Variablen erzwingen
  • 6.3 Auswerten von Operationen
  • 6.4Auswertung von Auswahlsätzen
  • 6.5Auswertung eines gruppierten Feldsatzes
  • 6.5.1Feldeinträge
  • 6.5.2 Normale Bewertung
  • 6.5.3 Serielle Ausführung
  • 6.5.4Fehlerbehandlung
  • 6.5.5 Nichtigkeit
  • 7Antwort
  • 7.1Serialisierungsformat
  • 7.1.1JSON-Serialisierung
  • 7.2 Antwortformat
  • 7.2.1Daten
  • 7.2.2 Spiegel
  • Anhang: Notationskonventionen
  • A.1Kontextfreie Grammatik
  • A.2Lexikalische und syntaktische Grammatik
  • A.3Grammar-Notation
  • A.4Grammar Semantik
  • A.5Algorithmen
  • Anhang: Grammatikübersicht
  • B.1 Ignorierte Token
  • B.2Lexikalische Token
  • B.3 Abfragedokument

Es ist deine Wahl:

Einfaches, süßes und kurz dokumentiertes Falcor JS VERSUS Riesiges Tool für Unternehmen mit langer und erweiterter Dokumentation als GraphQL & Relay

Wie ich bereits sagte, wenn Sie ein Front-End-Entwickler sind, der die Idee der Verwendung von JSON versteht, ist die Implementierung des JSON-Diagramms von Falcors Team der beste Weg, um Ihr Full-Stack-Entwicklungsprojekt durchzuführen.


13
Subjektive Antwort. Beinhaltet keinen technischen Vergleich. Eher als Kommentar geeignet.
Gajus

2
@ GajusKuizinas subjektive Antwort? Überprüfen Sie die Dokumentationen von beiden ;-) Ich sage nur, dass Falcor schneller und schneller zu lernen ist - und das ist eine Tatsache ;-) Ich habe auch mit beiden gearbeitet - Einfachheit wird auf lange Sicht überzeugen, selbst wenn FB eine großartige Leistung erbringt Job mit Hype ;-)
PrzeoR

2
Das ist nur eine Meinung und beantwortet die Frage überhaupt nicht.
Michał Miszczyszyn

14
Ich denke, dies ist eine großartige Antwort. Die Lernkurve einer Technologie ist nicht unbedingt subjektiv und kann leicht gemessen werden. Hier werden Fakten präsentiert, damit klare Schlussfolgerungen gezogen werden können. In der realen Welt berücksichtigen ernsthafte Fachleute diese Tatsachen. Dies ist schließlich eine offene Frage, die eindeutig von solchen Antworten profitiert.
Bmaggi

2
Ich stimme @MorgenCheng zu, hochgestimmt! Ich habe in den letzten Wochen die Runde gemacht und GraphQL / Relay, Cashay, Redux und jetzt Falcor evaluiert. Ich stimme PrzeoR zu 100% zu. Relay und GraphQL sind großartige Technologien, aber sie erfordern viel mehr Brainpower und sind für Neulinge schwerer zu finden. Es ist eine erhebliche Menge an Lernen erforderlich. Der Nachteil von Falcor ist das Fehlen von Beispielen für eine vollständige CRUD-basierte App. Und ich würde gerne sehen, wie PostgreSQL- und RethinkDB-Projekte JsonGraph ausspucken.
Dom

5

Kurz gesagt, Falcor oder GraphQL oder Restful lösen dasselbe Problem - bieten ein Tool zum effektiven Abfragen / Bearbeiten von Daten.

Sie unterscheiden sich darin, wie sie ihre Daten präsentieren:

  • Falcor möchte, dass Sie ihre Daten als einen sehr großen virtuellen JSON-Baum betrachten, und verwendet get , set und call , um Daten zu lesen und zu schreiben.
  • GraphQL möchte, dass Sie ihre Daten als eine Gruppe vordefinierter typisierter Objekte betrachten und verwendet Abfragen und Mutationen zum Lesen und Schreiben von Daten.
  • Restful möchte, dass Sie ihre Daten als eine Gruppe von Ressourcen betrachten und verwendet HTTP-Verben zum Lesen und Schreiben von Daten.

Wann immer wir Daten für den Benutzer bereitstellen müssen, erhalten wir etwas, das uns gefällt: client -> query -> {eine Ebene übersetzt Abfrage in Datenoperationen} -> Daten.

Nachdem ich mit GraphQL, Falcor und JSON API (und sogar ODdata) zu kämpfen hatte, schrieb ich meine eigene Datenabfrageschicht . Es ist einfacher, leichter zu erlernen und mit GraphQL gleichwertiger.

Überprüfen Sie es heraus an:
https://github.com/giapnguyen74/nextql

Es lässt sich auch in Federjs für Echtzeitabfragen / -mutationen integrieren. https://github.com/giapnguyen74/nextql-feathers


2

OK, fangen Sie einfach mit einem einfachen, aber wichtigen Unterschied an: GraphQL ist eine Abfrage, Falcor nicht!

Aber wie helfen sie dir?

Grundsätzlich helfen uns beide beim Verwalten und Abfragen von Daten, aber GraphQL verfügt über ein Anforderungs- / Res-Modell und gibt die Daten als JSON zurück , im Grunde die Idee in GraphQL darin, eine einzige Anforderung zu haben, alle Ihre Daten in einem Ziel zu erhalten. Haben Sie eine genaue Antwort, indem Sie eine genaue Anfrage haben. Also etwas, das auf langsamen Internet- und Mobilgeräten wie 3G-Netzwerken ausgeführt werden kann. Wenn Sie also viele mobile Benutzer haben oder aus bestimmten Gründen weniger Anfragen und eine schnellere Antwort wünschen , benutze GraphQL ... Während Faclor nicht zu weit davon entfernt ist, lies weiter ...

Andererseits, Falcor von Netflix normalerweise eine zusätzliche Anfrage (normalerweise mehr als einmal), um alle Ihre Daten abzurufen, obwohl sie versuchen, sie auf eine einzige Anforderung zu verbessern ... Falcor ist für Abfragen eingeschränkter und hat keine Vorabanforderung -definierte Abfrage-Helfer wie Range und etc ...

Aber zur weiteren Verdeutlichung wollen wir sehen, wie sich jeder von ihnen vorstellt:

GraphQL, eine Abfragesprache für Ihre API

GraphQL ist eine Abfragesprache für APIs und eine Laufzeit, um diese Abfragen mit Ihren vorhandenen Daten zu erfüllen. GraphQL bietet eine vollständige und verständliche Beschreibung der Daten in Ihrer API, gibt Kunden die Möglichkeit, genau zu fragen, was sie benötigen, und nicht mehr, erleichtert die Entwicklung von APIs im Laufe der Zeit und ermöglicht leistungsstarke Entwicklertools.

Senden Sie eine GraphQL-Abfrage an Ihre API und erhalten Sie genau das, was Sie brauchen, nicht mehr und nicht weniger. GraphQL-Abfragen liefern immer vorhersehbare Ergebnisse. Apps, die GraphQL verwenden, sind schnell und stabil, da sie die Daten steuern, die sie erhalten, nicht den Server.

GraphQL-Abfragen greifen nicht nur auf die Eigenschaften einer Ressource zu, sondern folgen auch reibungslos den Referenzen zwischen ihnen. Während typische REST-APIs das Laden von mehreren URLs erfordern, erhalten GraphQL-APIs alle Daten, die Ihre App benötigt, in einer einzigen Anforderung. Apps, die GraphQL verwenden, können auch bei langsamen Mobilfunknetzverbindungen schnell sein.

GraphQL-APIs sind nach Typen und Feldern organisiert, nicht nach Endpunkten. Greifen Sie von einem einzigen Endpunkt aus auf alle Funktionen Ihrer Daten zu. GraphQL verwendet Typen, um sicherzustellen, dass Apps nur nach dem Möglichen fragen und klare und hilfreiche Fehler liefern. Apps können Typen verwenden, um das Schreiben von manuellem Parsing-Code zu vermeiden.


Falcor, eine JavaScript-Bibliothek zum effizienten Abrufen von Daten

Mit Falcor können Sie alle Ihre entfernten Datenquellen als ein einzelnes Domänenmodell über ein virtuelles JSON-Diagramm darstellen. Sie codieren auf dieselbe Weise, unabhängig davon, wo sich die Daten befinden, ob im Speicher auf dem Client oder über das Netzwerk auf dem Server.

Eine JavaScript-ähnliche Pfadsyntax erleichtert den Zugriff auf so viele oder so wenig Daten, wie Sie möchten, wann Sie möchten. Sie rufen Ihre Daten mit bekannten JavaScript-Vorgängen wie get, set und call ab. Wenn Sie Ihre Daten kennen, kennen Sie Ihre API.

Falcor durchläuft automatisch Referenzen in Ihrem Diagramm und stellt bei Bedarf Anforderungen. Falcor verarbeitet die gesamte Netzwerkkommunikation transparent und stapelt Anfragen opportunistisch.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.