GraphQL：データクエリ言語

Facebookのモバイルアプリケーションを構築した際、Facebook全体を記述できるほど強力でありながら、製品開発者が迅速に開発に集中できるようにシンプルで学習しやすいデータ取得APIが必要でした。このニーズを満たすために3年前にGraphQLを開発しました。現在、1日あたり数千億件のAPIコールを処理しています。今年は、仕様書のドラフト作成、参照実装のリリース、graphql.org でのコミュニティ形成を通じて、GraphQLのオープンソース化のプロセスを開始しました。

GraphQLを選ぶ理由#

2012年、Facebookのネイティブモバイルアプリケーションの再構築に着手しました。

当時、私たちのiOSとAndroidアプリは、モバイルウェブサイトのビューをラップした薄いラッパーでした。「一度書けばどこでも実行できる」モバイルアプリケーションのプラトニックな理想に近づきましたが、実際にはモバイルウェブビューアプリを限界以上に押し上げました。Facebookのモバイルアプリが複雑になるにつれて、パフォーマンスが悪化し、頻繁にクラッシュするようになりました。

ネイティブに実装されたモデルとビューに移行する際に、初めてニュースフィードのAPIデータバージョンが必要になりました。それまではHTMLとしてのみ配信されていました。RESTfulサーバーリソースやFQLテーブル（FacebookのSQLのようなAPI）など、ニュースフィードデータをモバイルアプリに配信するためのオプションを評価しました。アプリで使用したいデータと、必要なサーバークエリとの違いに不満を感じていました。私たちは、データをリソースURL、セカンダリキー、または結合テーブルという観点から考えていません。オブジェクトのグラフと、最終的にアプリで使用されるモデル（NSObjectsやJSONなど）という観点から考えています。

サーバー側でデータを準備するためのコードと、クライアント側でデータを解析するためのコードを大量に記述する必要もありました。この不満から、最終的にGraphQLとなったプロジェクトを開始するきっかけとなりました。GraphQLは、製品デザイナーと開発者の視点からモバイルアプリのデータ取得を再考する機会でした。開発の焦点を、デザイナーと開発者が時間と注意を払っているクライアントアプリに移しました。

GraphQLとは？#

GraphQLクエリは、解釈と実行のためにサーバーに送信される文字列であり、サーバーはクライアントにJSONを返します。

データシェイプの定義：最初に気付くことは、GraphQLクエリがそのレスポンスを反映していることです。これにより、クエリから返されるデータの形状を予測しやすくなり、アプリに必要なデータが分かっていればクエリを書きやすくなります。さらに重要なのは、これによりGraphQLが非常に簡単に学習して使用できることです。GraphQLは、製品とそれを構築するデザイナーや開発者のデータ要件によって率直に推進されています。

階層構造：GraphQLのもう1つの重要な側面は、その階層構造です。GraphQLはオブジェクト間の関係を自然に追跡しますが、RESTfulサービスでは複数回の往復（モバイルネットワークではリソース集約的）やSQLでの複雑な結合ステートメントが必要になる場合があります。このデータ階層は、グラフ構造のデータストアと、最終的にはそれが使用される階層型ユーザーインターフェースとよく合致します。

厳格な型付け：GraphQLクエリの各レベルは特定の型に対応し、各型は使用可能なフィールドのセットを記述します。SQLと同様に、これによりGraphQLはクエリを実行する前に記述的なエラーメッセージを提供できます。また、Obj-CやJavaの厳格な型付けされたネイティブ環境ともよく適合します。

プロトコル、ストレージではない：サーバー上の各GraphQLフィールドは関数によってバックアップされています。これは、アプリケーションレイヤーにリンクするコードです。ニュースフィードをサポートするためにGraphQLを構築していましたが、すでに洗練されたフィードランキングとストレージモデル、既存のデータベース、ビジネスロジックがありました。GraphQLは、既存の作業を活用して役立つものでなければならず、ストレージレイヤーではなくアプリケーションレイヤーを公開することによって、既存のコードを活用します。

イントロスペクティブ：GraphQLサーバーは、サポートされている型をクエリできます。これにより、静的に型付けされた言語でのコード生成、Relayなどのアプリケーションフレームワーク、GraphiQL（下記参照）などのIDEなど、この情報の上にツールやクライアントソフトウェアを構築するための強力なプラットフォームが作成されます。GraphiQLは、開発者がコードベースをgrepしたり、cURLを操作したりすることなく、APIを迅速に学習して探索するのに役立ちます。

バージョンフリー：返されるデータの形状はクライアントのクエリによって完全に決定されるため、サーバーはシンプルで汎化しやすくなります。新しい製品機能を追加する場合は、サーバーに追加フィールドを追加でき、既存のクライアントには影響しません。古い機能を廃止する場合は、対応するサーバーフィールドを非推奨にできますが、引き続き機能します。この段階的な後方互換性のあるプロセスにより、インクリメントされるバージョン番号の必要性がなくなります。私たちは、GraphQL APIの単一バージョンで3年間リリースされたFacebookアプリケーションをまだサポートしています。

GraphQLを使用することで、2012年にiOSでフル機能のネイティブニュースフィードを構築し、その後まもなくAndroidでも構築できました。それ以来、GraphQLはモバイルアプリとそのアプリを支えるサーバーを構築する主要な方法になっています。3年以上経った現在、GraphQLはモバイルアプリケーションにおけるほぼすべてのデータ取得を処理しており、約1,000のリリース済みアプリケーションバージョンから毎秒数百万件のリクエストを処理しています。

2012年にGraphQLを構築したとき、それがFacebookでの開発方法にとってどれほど重要になるか、Facebook以外での価値を予測することはできませんでした。しかし、今年初めに、GraphQL上に構築されたWebおよびReact Native用のアプリケーションフレームワークであるRelayを発表しました。Relayに対するコミュニティの興奮から、GraphQLを再検討し、すべての詳細を評価し、改善を行い、矛盾を修正し、GraphQLとその動作を記述する仕様を記述することにしました。

2ヶ月前、進捗状況を公開 し、GraphQL仕様書 の作業ドラフトと参照実装であるGraphQL.js をリリースしました。それ以来、GraphQLを中心としたコミュニティが形成され始め、GraphQLランタイムのバージョンが多くの言語で構築 されています。これには、Go、Ruby、Scala、Java、.Net、Pythonなどがあります。また、ブラウザベースのIDE、ドキュメントブラウザ、クエリランナーであるGraphiQLなどの内部で使用しているツールの一部も共有し始めました。GraphQLはFacebook以外でも、コンサルティング会社Red BadgerによるFinancial Times のプロジェクトで本番環境で使用されています。

「GraphQLはデータ取得のオーケストレーションを非常にシンプルにし、フロントエンドとバックエンド間の完璧な分離ポイントとして機能します。」— Red Badgerのソフトウェアエンジニア、Viktor Charypar

GraphQLはFacebookでの製品開発において確立されたものですが、Facebook以外での使用はまだ始まったばかりです。GraphiQL を試して、仕様書 についてフィードバックを提供してください。GraphQLは、どちらの環境で使用している言語に関係なく、クライアント側の製品開発者とサーバー側のエンジニアの両方のデータニーズを大幅に簡素化できると考えており、GraphQLの改善、それを中心としたコミュニティの育成、そして私たちが一緒に構築できるものを楽しみにしています。