2012年2月、Facebookの開発者たちは、ネイティブのiOSツールを使用して、モバイルフレンドリーなFacebook iPhoneアプリの設計に着手しました。既存のAPIの問題に不満を感じていた開発者たちは、iPhoneアプリにデータを要求して配信するための、より優れた効率的な方法を必要としていました。こうしてGraphQLを作成することになり、2012年8月に新しいFacebook iPhoneアプリの出荷とともに最初の本番稼働を開始しました。このAPI向けのオープンソースのデータクエリ言語は、2015年に一般公開されました。  

GraphQLは主に、REST APIを介した複雑なデータへのアクセスにおける課題を克服するために作成されました。通常、REST APIは複数のURLから読み込む必要があります。GraphQL APIを使用すると、単一のエンドポイントですべて動作する、複数のタイプのデータを要求できます。同様のオブジェクトのデータを要求するために、複数のRESTコールを処理する必要はありません。GraphQLを使用すると、単一のクエリを作成して同じ情報にアクセスできます。 

 

効率的な型システム

GraphQLは、クエリ可能なデータを記述するために型システムを使用し、クエリの検証に使用されます。GraphQLは特定のデータベースやストレージエンジンに紐付けられていないため、クライアントは必要なデータをクエリの形式で指定します。 サーバーは、要求されたデータのみを含め、まったく同じ形で応答を返します。  

GraphQLクエリリクエストはJSON形式に近い構文を使用します: 

img

 

GraphQLクエリの応答には、リクエストしたデータのみが同じ形式で含まれます:

img

 

多くのアプリケーションには、GraphQLのような形式化されたクライアントサーバー「コントラクト」がありません。プロダクト開発者は、複数のエンドポイントを介してサーバー機能にアクセスし、必要なデータを取得するためのカスタムコードを記述します。サーバーはプロシージャを定義し、データを返します。このアプローチはシンプルですが、アプリケーションの複雑さが増したり、システムが古くなったり、あるいはその両方の場合に、効率がどんどん低下します。

たとえば、REST APIでは、特定のエンドポイントからの情報が必要な場合、REST APIが返すフィールドを制限するようにリクエストを記述することはできません。応答は完全なデータセットを提供します。すなわち、データの過剰な取得が発生します。対照的に、オープンソースのGraphQLデータクエリ言語は、複数のオブジェクトについて、各エンティティ内の特定のフィールドから必要な情報のみを返すようにリクエストを調整できる構文を使用します。

GraphQLは許可されたクエリと取得できるデータの種類を記述する、事前に定義されたスキーマを使用します。このアプローチにより、フィールドの型について想定する必要なく、アプリケーションを簡単に開発できます。GraphQLのその他の利点:

  • 以前は数週間かかっていたプロジェクトが数時間で完了できる。

  • クエリは予測可能な結果を返す。

  • サーバーがデータを制御していないため、アプリは高速で安定化する。

  • データの過剰な取得と過小な取得がなくなる。

  • ネットワークとメモリの使用量が減少する。自動化により、この節約効果は確実に増強される。

  • プロダクト開発者は、自分の考え方や働き方にとってより自然な、宣言的かつ階層的な方法で、必要なデータを正確にクエリすることができる。

 

Rubrikで採用するGraphQL

2017年3月、当社の開発チームは初のGraphQLサービスであるRubrikクラウドデータマネジメント(CDM)UIを作成しました。CDM UIの初期コンセプトを徹底的に検証した後、当社はSaaSプラットフォームであるPolarisの主要なAPIアーキテクチャとしてGraphQLを選択しました。これにより、ユーザーは効率性、パフォーマンス、俊敏性において大きなメリットを得られます。

GraphQLはREST APIの強力な代替手段となり得ますが、全面的に置き換わるものではありません。場合によっては、依然としてREST APIの方が望ましい場合もあります。

オープンソースのGraphQLデータクエリ言語の詳細については、当社のGraphQLとRubrikの紹介をご覧ください。