web-dev-qa-db-ja.com

FalcorとGraphQLの違いは何ですか?

GraphQLは、型システム、クエリ言語と実行セマンティクス、静的検証、型イントロスペクションで構成されます。それぞれの概要を以下に示します。これらの各コンポーネントをガイドするために、GraphQLのさまざまな部分を説明するための例を作成しました。

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

Falcorでは、仮想JSONグラフを介して、すべてのリモートデータソースを単一のドメインモデルとして表すことができます。データの場所に関係なく、クライアントのメモリ内でもサーバー上のネットワーク経由でも同じ方法でコーディングします。

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

FalcorとGraphQLの違いは何ですか(Relayのコンテキストで)?

153
Gajus

私は Angular Airエピソード26:FalcorJSとAngular 2 を見ました。ここで Jafar HusainGraphQLFalcorJS の比較。これは要約です(言い換え):

  • FalcorJSとGraphQLは同じ問題(データのクエリ、データの管理)に取り組んでいます。
  • 重要な違いは、GraphQLはクエリ言語であり、FalcorJSはそうではないことです。
  • FalcorJSにリソースを要求する場合、有限の値のシリーズを非常に明示的に要求します。 FalcorJSは、範囲などをサポートしています。 genres[0..10]。ただし、オープンエンドのクエリはサポートしていません。 genres[0..*]
  • GraphQLはベースに設定されます:true、これによる順序など、すべてのレコードを教えてください。この意味で、GraphQLクエリ言語はFalcorJSよりも強力です。
  • GraphQLには強力なクエリ言語がありますが、サーバー上でそのクエリ言語を解釈する必要があります。

Jafarは、ほとんどのアプリケーションでは、クライアントからサーバーに送信されるクエリのタイプは同じ形を共有していると主張します。したがって、getやsetなどの特定の予測可能な操作があると、キャッシュを活用する機会が増えます。さらに、多くの開発者は、RESTアーキテクチャの単純なルーターを使用してリクエストをマッピングすることに精通しています。

最後の議論は、GraphQLに付属するパワーが複雑さを上回るかどうかについて解決します。

125
Gajus

両方のライブラリを使用してアプリを作成しました。Gajusの投稿のすべてに同意できますが、フレームワークを使用する上でいくつかの異なることが最も重要であることがわかりました。

  • おそらく最大の実際的な違いは、GraphQLのほとんどの例とこれまでの作業が、ReactJSウィジェットとデータ要件を統合するFacebookのシステムであるGraphQLとRelayの統合に集中していたことです。一方、FalcorJSは、ウィジェットシステムとは別に動作する傾向があります。つまり、非React/Relayクライアントへの統合が容易になる可能性があることと、ウィジェットデータの依存関係をウィジェットと一致させるという点で、自動的に実行する処理が少なくなることを意味します。
  • クライアント側の統合でFalcorJSが柔軟であることの裏側は、サーバーがどのように動作する必要があるかについて非常に意見を述べることができるということです。 FalcorJSには実際には「HTTP経由でこのクエリを呼び出す」機能があります-Jafar Husainはそれについてあまり話していないようです-そしてそれらを含めると、クライアントライブラリがサーバー情報に反応する方法は非常に似ていますGraphQL/Relayは、構成のレイヤーを追加します。 FalcorJSでは、映画の値を返す場合、戻り値は「映画」と言う方が適切ですが、GraphQLでは、クエリが「映画」を返す場合でも、それをクライアント側のデータストアに「映画」として記述する必要があると説明できます'。 -これは、Gajusが言及したパワーと複雑さのトレードオフの一部です。
  • 実用的には、GraphQLとリレーはより開発されているようです。 Jafar Husainは、次のバージョンのNetflixフロントエンドは少なくとも部分的にFalcorJSで実行されると述べていますが、Facebookチームは、GraphQL/Relayスタックのいくつかのバージョンを3年以上実稼働で使用していると述べています。
  • GraphQLとRelay周辺のオープンソース開発者コミュニティは繁栄しているようです。私は個人的にFalcorJSの周りに非常に少数を発見したのに対し、GraphQLとリレーの周りに多数の有能な支援プロジェクトがあります。また、Relayのベースgithubリポジトリ( https://github.com/facebook/relay/Pulse )は、FalcorJSのgithubリポジトリ(- https:// github。 com/netflix/falcor/Pulse )。私が最初にFacebookのレポを引っ張ったとき、例は壊れていました。 githubの問題を開きましたが、数時間で修正されました。一方、私がFalcorJSで公開したgithubの問題は、2週間以内に公式の対応がありませんでした。
77
OverclockedTim

Lee Byron GraphQLの背後にいるエンジニアの1人が hashnodeのAMA を実行しました。この質問をしたときの答えは次のとおりです。

  • FalcorはObservablesを返し、GraphQLは値のみを返します。 NetflixがFalcorをどのように使用したいかについて、これは非常に理にかなっています。複数のリクエストを作成し、準備ができたらデータを提示しますが、クライアント開発者はObservablesを直接操作する必要があります。 GraphQLは要求/応答モデルであり、JSONを返します。JSONは簡単に使用できます。リレーは、単純な値のみを使用して維持しながら、Falcorが提示するダイナミズムの一部を追加します。
  • Type system。 GraphQLはタイプシステムの観点から定義されているため、GraphiQL、コードジェネレータ、エラー検出など、多くの興味深いツールを構築できます。Falcorははるかに動的で、価値がありますそれ自体が、この種のことを行う能力を制限します。
  • ネットワークの使用状況 GraphQLは、もともとローエンドネットワーク上のローエンドデバイスでFacebookのニュースフィードを操作するために設計されたため、1つのネットワークリクエストで必要なすべてを順番に宣言できるようになります遅延を最小限に抑えます。一方、Falcorは多くの場合、複数のラウンドトリップを実行して追加データを収集します。これは、システムのシンプルさとネットワークの制御とのトレードオフにすぎません。 Netflixの場合、非常にローエンドのデバイス(Rokuスティックなど)も処理しますが、ビデオをストリーミングするのに十分なネットワークであることが前提です。

編集:Falcorは実際に バッチ要求 を実行でき、ネットワークの使用に関するコメントを不正確にします。 @PrzeoRに感謝

23
YasserKaddour

更新:投稿の下で、メインコンテンツの補足として共有したい非常に有用なコメントを見つけました。 enter image description here

例の欠如については、awesome-falcorjsリポジトリが使いやすいことがわかります。FalcorのCRUDの使用例がいくつかあります。 https://github.com/przeor/awesome-falcorjs ... 、「 Mastering Full Stack React Development 」という本があります。これにはFalcorも含まれています(使用方法を学ぶための良い方法です)。

enter image description here

元のPOST以下:

FalcorJS( https://www.facebook.com/groups/falcorjs/ )は、Relay/GraphQLと比較して効率がはるかに簡単です。

GraphQL + Relayの学習曲線は巨大です: enter image description here

私の短い要約では、Falcorに行きましょう。次のプロジェクトでFalcorを使用して、チームに大きな予算と多くの学習時間を与えてから、RELAY + GRAPHQLを使用します。

GraphQL + Relayには巨大なAPIがあり、それを効率的にする必要があります。Falcorには小さなAPIがあり、JSONに精通しているフロントエンド開発者であれば非常に簡単に把握できます。

リソースが限られているAGILEプロジェクトがある場合-> FalcorJSをお試しください!

私の主観的な意見:FalcorJSは、フルスタックJavaScriptで500%以上簡単に効率化できます。

また、私のプロジェクトでFalcorJSスターターキットを公開しました(フルスタックのfalcorのサンプルプロジェクトがさらにあります): https://www.github.com/przeor

技術的な詳細を確認するには:

1)Falcorを使用している場合、フロントエンドとバックエンドの両方で使用できます。

「falcor」からfalcorをインポートします。

そして、それに基づいてモデルを構築します。

...バックエンドで簡単に使用できる2つのライブラリも必要です。a)falcor-express-1回使用します(例app.use( '/ model.json'、FalcorServer.dataSourceRoute(( )=>新しいNamesRouter())))。ソース: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b)falcor-router-単純なルートを定義します(例:route: '_view.length')。ソース: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Falcorは、学習曲線の点で非常に簡単です。

また、FBのlibよりもはるかに簡単なドキュメントを参照して、記事「 なぜfalcorjs(netflix falcor) 」を確認することもできます。

2)Relay/GraphQLは、巨大なエンタープライズツールのようです。

たとえば、次の2つの異なるドキュメントがあり、それぞれ個別に説明しています。

a)リレー: https://facebook.github.io/relay/docs/tutorial.html -コンテナー-ルート-ルートコンテナー-準備完了状態-突然変異-ネットワーク層-Babel Relayプラグイン-GRAPHQL

  • GraphQLリレー仕様
  • オブジェクト識別
  • 接続
  • 突然変異
  • 参考文献
  • APIリファレンス

  • リレー

  • リレーコンテナ
  • 中継ルート
  • Relay.RootContainer
  • Relay.QL
  • リレー突然変異
  • Relay.PropTypes
  • Relay.Store
  • インターフェース

  • RelayNetworkLayer

  • RelayMutationRequest
  • RelayQueryRequest

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

  • 2言語
  • 2.1ソーステキスト
  • 2.1.1Unicode
  • 2.1.2ホワイトスペース
  • 2.1.3ラインターミネータ
  • 2.1.4コメント
  • 2.1.5重要でないコンマ
  • 2.1.6字句トークン
  • 2.1.7無視されたトークン
  • 2.1.8句読点
  • 2.1.9名前
  • 2.2クエリドキュメント
  • 2.2.1操作
  • 2.2.2選択セット
  • 2.2.3フィールド
  • 2.2.4引数
  • 2.2.5フィールドエイリアス
  • 2.2.6フラグメント
  • 2.2.6.1型条件
  • 2.2.6.2インラインフラグメント
  • 2.2.7入力値
  • 2.2.7.1整数値
  • 2.2.7.2フロート値
  • 2.2.7.3ブール値
  • 2.2.7.4文字列値
  • 2.2.7.5列挙値
  • 2.2.7.6リスト値
  • 2.2.7.7入力オブジェクト値
  • 2.2.8変数
  • 2.2.8.1フラグメント内の変数の使用
  • 2.2.9入力タイプ
  • 2.2.10ディレクティブ
  • 2.2.10.1フラグメントディレクティブ
  • 3タイプシステム
  • 3.1タイプ
  • 3.1.1スカラー
  • 3.1.1.1組み込みスカラー
  • 3.1.1.1.1Int
  • 3.1.1.1.2フロート
  • 3.1.1.1.3文字列
  • 3.1.1.1.4ブール
  • 3.1.1.1.5ID
  • 3.1.2オブジェクト
  • 3.1.2.1オブジェクトフィールドの引数
  • 3.1.2.2オブジェクトフィールドの廃止
  • 3.1.2.3オブジェクトタイプの検証
  • 3.1.3インターフェース
  • 3.1.3.1インターフェースタイプの検証
  • 3.1.4組合
  • 3.1.4.1ユニオン型検証
  • 3.1.5列挙
  • 3.1.6入力オブジェクト
  • 3.1.7リスト
  • 3.1.8非ヌル
  • 3.2ディレクティブ
  • 3.2.1@skip
  • 3.2.2@include
  • 3.3起動タイプ
  • 4内観
  • 4.1一般原則
  • 4.1.1命名規則
  • 4.1.2ドキュメント
  • 4.1.3廃止
  • 4.1.4型名のイントロスペクション
  • 4.2スキーマイントロスペクション
  • 4.2.1「__ Type」タイプ
  • 4.2.2タイプの種類
  • 4.2.2.1スカラー
  • 4.2.2.2オブジェクト
  • 4.2.2.3連合
  • 4.2.2.4インターフェース
  • 4.2.2.5列挙
  • 4.2.2.6入力オブジェクト
  • 4.2.2.7リスト
  • 4.2.2.8非ヌル
  • 4.2.2.9リストとNull以外の組み合わせ
  • 4.2.3 __Fieldタイプ
  • 4.2.4 __InputValueタイプ
  • 5検証
  • 5.1操作
  • 5.1.1名前付き操作定義
  • 5.1.1.1操作名の一意性
  • 5.1.2匿名操作の定義
  • 5.1.2.1ローン匿名操作
  • 5.2フィールド
  • 5.2.1オブジェクト、インターフェース、およびユニオン型のフィールド選択
  • 5.2.2フィールド選択のマージ
  • 5.2.3リーフフィールドの選択
  • 5.3引数
  • 5.3.1引数名
  • 5.3.2引数の一意性
  • 5.3.3引数値の型の正確さ
  • 5.3.3.1互換性のある値
  • 5.3.3.2必須の引数
  • 5.4フラグメント
  • 5.4.1フラグメント宣言
  • 5.4.1.1フラグメント名の一意性
  • 5.4.1.2フラグメントスプレッドタイプの存在
  • 5.4.1.3複合型のフラグメント
  • 5.4.1.4フラグメントを使用する必要があります
  • 5.4.2フラグメントスプレッド
  • 5.4.2.1フラグメントスプレッドターゲットの定義
  • 5.4.2.2フラグメントスプレッドはサイクルを形成してはならない
  • 5.4.2.3フラグメントの広がりが可能
  • 5.4.2.3.1オブジェクトスコープ内のオブジェクトの広がり
  • 5.4.2.3.2オブジェクトスコープの抽象的なスプレッド
  • 5.4.2.3.3抽象スコープでのオブジェクトの広がり
  • 5.4.2.3.4抽象スコープでの抽象的なスプレッド
  • 5.5値
  • 5.5.1入力オブジェクトフィールドの一意性
  • 5.6指令
  • 5.6.1ディレクティブが定義されている
  • 5.7変数
  • 5.7.1変数の一意性
  • 5.7.2変数のデフォルト値が正しく入力されている
  • 5.7.3変数は入力タイプです
  • 5.7.4定義されているすべての変数の使用
  • 5.7.5使用されるすべての変数
  • 5.7.6すべての変数の使用が許可されています
  • 6実行
  • 6.1リクエストの評価
  • 6.2変数の強制
  • 6.3操作の評価
  • 6.4選択セットの評価
  • 6.5グループ化されたフィールドセットの評価
  • 6.5.1フィールドエントリ
  • 6.5.2通常の評価
  • 6.5.3シリアル実行
  • 6.5.4エラー処理
  • 6.5.5無効性
  • 7応答
  • 7.1シリアル化形式
  • 7.1.1JSONシリアル化
  • 7.2応答形式
  • 7.2.1データ
  • 7.2.2エラー
  • 付録:表記規則
  • A.1文脈自由文法
  • A.2字句と構文の文法
  • A.3文法表記
  • A.4文法セマンティクス
  • A.5アルゴリズム
  • B付録:文法のまとめ
  • B.1無視されたトークン
  • B.2字句トークン
  • B.3クエリ文書

あなたの選択です:

GraphQL&Relayのように長くて高度なドキュメントを備えた、シンプルで短いドキュメントFalcor JS VERSUS巨大エンタープライズグレードのツール

前にも言ったように、JSONを使用するというアイデアを理解しているフロントエンド開発者であれば、FalcorのチームによるJSONグラフ実装がフルスタックの開発プロジェクトを行うのに最適な方法です。

20
PrzeoR

要するに、FalcorまたはGraphQLまたはRestfulは同じ問題を解決します-データを効率的に照会/操作するツールを提供します。

それらの違いは、データの表示方法にあります。

  • Falcorは、自分のデータを非常に大きな仮想JSONツリーと見なしてほしいと考えており、getsetおよびcallデータの読み取り、書き込み。
  • GraphQLは、データを事前定義された型付きオブジェクトのグループと考えて、queriesおよびmutationsデータの読み取り、書き込み。
  • Restfulは、データをリソースのグループと考えてもらい、HTTP動詞を使用してデータを読み書きします。

ユーザーにデータを提供する必要があるときはいつでも、クライアント->クエリ-> {レイヤーがクエリをデータopsに変換します}->データのようになります。

GraphQL、Falcor、JSON API(およびODdata)に苦労した後、私は独自の データクエリレイヤー を作成しました。 GraphQLの方がシンプルで、学習しやすく、同等です。

でそれをチェックしてください:
https://github.com/giapnguyen74/nextql

また、リアルタイムのクエリ/突然変異のためにfeatherjsと統合します。 https://github.com/giapnguyen74/nextql-feathers

5
Giap Nguyen

OK、単純だが重要な違いから始めてください。GraphQLはクエリベースですが、Falcorは違います!

しかし、彼らはあなたをどのように助けますか?

基本的に、データの管理とクエリの両方に役立ちますが、GraphQLにはreq/res Modelがあり、データをJSONとして返します。基本的にGraphQLのアイデアは、1つの目標ですべてのデータを取得するための単一の要求を持っていることです...また、正確な要求を持つことによって正確な応答を持っているので、低速インターネットとモバイルで実行するもの3Gネットワ​​ークなどのデバイス...したがって、多くのモバイルユーザーがいる場合、または何らかの理由でリクエストを減らして応答を速くしたい場合は、GraphQL ...を使用しますFaclorこれからそれほど遠くないので、読んでください...

一方、NetflixによるFalcorは、すべてのデータを取得するための追加の要求(通常は複数回)がありますが、単一の要求に改善しようとしていますが... Falcorはクエリに対してより制限されており、範囲などの事前定義されたクエリヘルパーはありません...

しかし、より明確にするために、それらのそれぞれがどのように自己紹介するかを見てみましょう:

GraphQL、APIのクエリ言語

GraphQLは、APIのクエリ言語であり、既存のデータでこれらのクエリを実行するためのランタイムです。 GraphQLは、API内のデータの完全で理解可能な説明を提供し、クライアントが必要なものだけを要求する能力を提供し、APIを徐々に進化させ、強力な開発者ツールを有効にします。

GraphQLクエリをAPIに送信して、必要なものだけを取得します。 GraphQLクエリは常に予測可能な結果を​​返します。 GraphQLを使用するアプリは、サーバーではなく取得するデータを制御するため、高速で安定しています。

GraphQLクエリは、1つのリソースのプロパティだけでなく、それらの間の参照にもスムーズにアクセスします。典型的なREST AP​​Iは複数のURLからロードする必要がありますが、GraphQL APIはアプリが必要とするすべてのデータを単一のリクエストで取得します。 GraphQLを使用するアプリは、低速のモバイルネットワーク接続でも高速に動作します。

GraphQL APIは、エンドポイントではなく、タイプとフィールドの観点から整理されています。単一のエンドポイントからデータのすべての機能にアクセスします。 GraphQLは型を使用して、アプリが可能なことのみを要求し、明確で役立つエラーを提供するようにします。アプリは型を使用して、手動の解析コードを記述することを回避できます。


Falcor、効率的なデータ取得のためのJavaScriptライブラリ

Falcorでは、仮想JSONグラフを介して、すべてのリモートデータソースを単一のドメインモデルとして表すことができます。データがどこにあっても、クライアントのメモリ内であろうとサーバー上のネットワーク上であろうと同じ方法でコーディングします。

JavaScriptに似たパス構文を使用すると、必要なときに必要なだけデータにアクセスできます。 get、set、callなどの使い慣れたJavaScript操作を使用してデータを取得します。データを知っていれば、APIを知っています。

Falcorはグラフ内の参照を自動的にトラバースし、必要に応じて要求を行います。 Falcorは、すべてのネットワーク通信を透過的に処理し、要求を日和見的にバッチ処理および重複排除します。

1
Alireza