GraphQL は、1 回の API 呼び出しで複数のソースからデータを取得できる API 用のオープンソース クエリ言語です。 また、既存のデータを使用してクエリを実行するサーバー側ランタイムとしても機能します。 GraphQL は、完全な API データ記述を提供しながら、要求されたデータのみをクライアントに提供することを優先し、API の拡張と進化を容易にします。
GraphQL は柔軟性、スピード、開発者を念頭に置いて設計されました。 GraphQL を使用すると、開発者は適切と思われる方法で API を構築し、GraphQL 仕様を使用して API がクライアントに対して機能することを確認できます。
GraphQL クエリの主な概念の 1 つは、返されるデータが予測可能であることです。 余分なコードの文字列ではなく、要求されたものが正確に返されます。 この宣言的なデータ取得は、帯域幅が制限されているモバイル デバイスで特に役立ちます。 GraphQL を使用するアプリは、サーバーではなく要求および受信されるデータを制御するため、安定性と高速性も備えています。 また、1 回のリクエストで複数のアイテムを一度に返すことができるため、ネットワーク接続が遅い場合でも高速です。
GraphQL のデータ簡素化に基づいて、API はエンドポイントではなくタイプとフィールドによって編成されます。 つまり、すべてのデータに単一のエンドポイントからアクセスできるため、アプリは必要なものだけを要求できるようになります。 GraphQL は、運用の複雑さを軽減することで、合理化されたAPI 接続ソリューションのワークフローに適合します。
2012 年、Meta (当時は Facebook) は、Facebook モバイル アプリケーションに十分な機能を備えたデータ取得 API を必要としていました。 Facebook は、Lee Byron 氏の指揮の下、特に製品設計者と開発者の観点から、データ取得を簡素化する手段として GraphQL を開発しました。 GraphQL は最初に Facebook 社内で使用され、その後 2015 年に一般公開され、オープンソース化されました。 他の多くのオープンソース プロジェクトに倣い、2019 年に GraphQL プロジェクトはLinux Foundationがホストする独自のGraphQL Foundationに移行しました。
GraphQL は、 RESTアーキテクチャの代替として設計されました。 標準の REST API では、個別の HTTP GET リクエストを介して複数の URL から情報を読み込む必要があります。 GraphQL API を使用すると、すべてのデータが単一の POST リクエストを介して取得されます。 REST と GraphQL はどちらも JSON 形式の応答を返しますが、GraphQL はデータの合理化と統合に重点を置いています。
GraphQL はきめ細かいデータ要求をサポートし、送信される情報をクライアントがより細かく制御できるようにします。 クライアントは POST リクエストの形式で GraphQL クエリを送信し、サーバーは JSON 形式の応答を返します。 GraphQL は特定のアプリケーション アーキテクチャを必要とせず、複数の環境 (統合開発環境 [IDE] を含む) にデプロイ可能で、既存のAPI 管理ツールや既存の REST API 上で使用できます。
GraphQL 内の重要な用語には次のようなものがあります。
GraphQL のユニークな機能の 1 つは、応答がクエリの構造 (それ自体がスキーマによって定義されます) を反映することです。 これにより、サーバーの応答の形式が完全に予測可能になるため、クライアントの解析が簡素化されます。
GraphQL の階層的な性質はオブジェクト間の関係に従い、階層的なユーザー インターフェイスでうまく機能します。 また、厳密に型指定されているため、各クエリ レベルは型と一致します。 これらの型は一連のフィールドを定義します。 これは、クエリを完了する前に説明的なエラー メッセージが表示される SQL に似ています。
リゾルバは、GraphQL フィールド、エッジ、ミューテーション、クエリ、サブスクリプションをデータ ソース (およびマイクロサービス) に接続する重要なアーキテクチャ モジュールです。
このGraphQL チュートリアルでは、AWS データソースのリゾルバーを構築する方法を学習できます。
GraphQL クエリをユニークにする 1 つの要素は、ミラー化された応答です。 クエリから返されるデータは、API リクエストの形状と一致することがわかっているため、予測可能になります。 返されるデータの形状がクライアントのクエリに従うと、サーバーが簡素化されます。
GraphQL の大きな利点の 1 つは、REST では利用できない機能を提供する拡張機能を利用できることです。 GraphQL のその他の利点は次のとおりです。
GraphQL スキーマは、GraphQL アプリケーションに単一の真実のソースを設定し、すべてのデータが記述される主要な場所を提供します。 GraphQL スキーマは通常サーバーで定義されますが、クライアントはスキーマに基づいてデータをクエリしたり書き込んだりすることができます。
REST アーキテクチャでは、オーバーフェッチがすぐに問題になる可能性があります。アプリケーション (バックエンド) は、各リソースで使用可能なデータを定義し、クライアント (フロントエンド) に必要な要素が 1 つだけであっても、そのすべてを応答で返します。 GraphQL 呼び出しは 1 回の呼び出しで実行され、過剰なフェッチなしでクライアントに要求されたデータを提供します。
データ型が厳密に定義されているため、GraphQL では REST よりもクライアントとサーバー間の通信が明確になります。 この基礎構造により、GraphQL サーバーを呼び出すために複雑なクライアントは必要なくなります。 さらに詳しく知り、コードの動作を確認するには、 GraphQL の公式ページでクライアントとサーバーについて読んでください。
一連の設計原則とツールである API フェデレーションにより、境界付けられたコンテキスト内のサービスをユーザー向けの一貫した API として公開できるようになり、同時にそのコンテキスト内のサービスが制限なく進化できるようになります。 GraphQL は、API 全体を統合し、以前のクエリを壊すことなく進化させる方法を提供し、スケーラブルです。このスケーラビリティは、GraphQL が多くの企業で使用されている理由の 1 つです。
GraphQL のイントロスペクティブな性質により、GraphQL API から GraphQL スキーマを取得できます。クライアントは利用可能なデータ型のリストを要求することもできます。これは、ドキュメントを自動的に生成したり、複数のマイクロサービスからスキーマをテストまたは取得したりするのに最適です。
GraphQL を採用する理由はたくさんありますが、注意すべき欠点もいくつかあります。 たとえば、すべてがすぐに使えるわけではなく、他の人の API を使用するには特別なライブラリが必要です。また、全体的に、GraphQL では REST よりも多くのツール サポートが必要です。
REST と比較した GraphQL の欠点は次のとおりです。
REST API に慣れている開発者にとって、GraphQL の学習曲線はより急峻です。 ワークフローも変更される可能性があります。GraphQL を使用する API チームは、保守可能な GraphQL スキーマも記述する必要があります。 とはいえ、新しく始める場合、リクエストとレスポンスの構造が同じであるため、GraphQL は簡単に学習して使用できます。
GraphQL では新しい API 管理戦略が必要になる可能性がありますが、REST API は既存の API 管理モデルに適合する傾向があります。 新しい API 管理戦略を追加すると全体的な費用が増加する可能性があるため、この点を考慮することが重要です。
GraphQL でのキャッシュは、リクエストで通常 HTTP メソッド (GET、POST、PUT、または DELETE) が使用される REST の場合ほど簡単ではありません。 標準の GraphQL リクエストは POST であり、HTTP レベルではキャッシュできません。 GraphQL では、単一のエンドポイントを持つということは、エンドポイントの URL が複数のさまざまなキャッシュ不可能な応答を生成することを意味するため、キャッシュも複雑になる可能性があります (データの取得には適していますが、キャッシュには適していません)。 サーバー開発者は、それぞれが同じオブジェクト内で操作しているにもかかわらず、異なるクエリを実行することになります。 そうは言っても、多くの GraphQL ライブラリはすぐに使えるキャッシュ メカニズムを提供しています。