2024年11月5日
GraphQLは、クライアントがアプリケーション・プログラミング・インターフェイス（API）と対話する方法を指定するオープンソースのクエリ言語およびサーバー側のランタイムです。
GraphQLは、Representational State Transfer（REST）およびRESTful APIに代わる効率的で柔軟な手段を提供し、RESTのいくつかの制限を解決します。例えば、単一のクエリーでリソースをより正確にターゲットする機能を提供します。
GraphQLは直感的な構文を使用するため、クライアントは単一のGraphQLクエリーをAPIに送信し、（多数のパラメーターを持つ複雑なエンドポイントにアクセスする代わりに）必要なデータだけを受け取ることができます。このより効率的なデータ取得方法により、システムの性能と開発者の使いやすさが向上します。
これにより、GraphQLは、フロントエンドの要件が急速に変化する複雑な環境でAPIを組み込む場合に特に役立ちます。REST APIもGraphQL APIも本質的に優れているわけではありません。これらは、さまざまなタスクに適したさまざまなツールです。
2010年代初頭、Facebookは大幅な成長と変革を経験しました。しかし、ユーザーベースの拡大とモバイル・アプリ環境が複雑になるに伴い、必要なクエリー・データをすべて取得するために異なるエンドポイントへの複数回のラウンドトリップが必要となる既存のRESTful Approachは継続不可能になりました。
REST APIは、複雑なデータ駆動型のユーザー・インターフェースを処理するのに十分な設備が整っておらず、特に限られたデータ・プランや高価なデータ・プランを使用するモバイル・ユーザーにとっては、レイテンシーやデータの非効率などの問題が頻繁に発生していました。
これらの課題に対応して、Facebookのエンジニアは（シングルページ・アプリケーション・プラットフォームReactとともに）GraphQLを開発し、2015年にオープンソース・ソリューションとしてリリースしました。最終的に、Facebookは2018年にこのサービスを、AWS社、Gatsby社、Intuit社、IBMなどのメンバー企業で構成されるGraphQL Foundationに移転しました。
GraphQLアーキテクチャの宣言型データフェッチ機能は、いくつかの主要なコンポーネントとプロセスを中心に展開し、それぞれがデータの処理と処理において独自の役割を果たします。例えば次のようなものがあります。
- スキーマ
- リゾルバー
- クエリ
- ミューテーション
スキーマ
GraphQLは、すべてのデータ型がGraphQLスキーマ定義言語（SDL）で記録される強力な型システムを基盤としています。型付きスキーマは、APIでクエリーできるデータの型、並びにユーザーが使用できる型と操作の関係を決定します。
言い換えれば、APIの機能とクライアントが対話できるデータの形式を定義するということです。このスキーマの構成によって、最終的にAPIの使用方法が決まります。クエリーが送られてくると、スキーマはリクエストの検証に使用され、GraphQL APIは検証されたクエリーのみを実行します。
リゾルバー
スキーマ内の各フィールドは、データを設定し、一連のフィールドに対する応答を決定するリゾルバーによってサポートされています。データベースやクラウド・サービス、または事実上あらゆるソースからデータを取得できるリゾルバーは、GraphQLオペレーション（クエリー、ミューテーション、サブスクリプションなど）をデータに変換するための指示を提供します。
クエリー・フィールドが開始されると、システムは対応するリゾルバーへの呼び出しを行い、次の値を生成します。フィールドがスカラー値（文字列や数値など）を生成すると、実行は完了します。フィールドがオブジェクト値を生成すると、クエリーにはそのオブジェクトに関連するさらに多くのフィールドが含まれます。このプロセスは、スカラー・フィールドだけが残るまで続けられます。
リゾルバーは、データのフォーマットも容易にし、システムがさまざまなデータソースからの情報をつなぎ合わせるのにも役立ちます。
クエリ
データ・クエリーは、クライアントによってGraphQLサーバーに対して行われるリクエストです。クライアントが取得したいデータを指定します。クエリーはクエリー・タイプで定義されます。これは、クライアントがサーバーに対して実行できるすべての要求の最上位エントリー・ポイントを定義するコード内の特別なオブジェクトです。各クエリー・タイプは、各エントリー・ポイントの名前とリターンのタイプも定義します。
クエリーが受信されると、GraphQLはそのクエリーをスキーマ定義に照合して検証し、クエリーが有効であると仮定してこれを実行します。通常、クエリーの構造は応答データの構造を反映しているため、データ要件が明示的かつ予測可能になります。
ミューテーション
ミューテーションは、サーバー上のデータを作成・更新または削除するGraphQLのオペレーションです。これらは、RESTful APIのPOST、PUT、PATCH、およびDELETEのオペレーションに類似しています。ユーザーは一部のクエリーには認証なしでアクセスできますが、ミューテーションには常に認証が必要です（例えば、APIトークンの使用など）。
クエリーの動作と同様に、GraphQLのミューテーションはスキーマとその定義に照合して検証されます。ミューテーションが検証後開始されると、サーバーはJSON応答を返します。
The DX Leaders
「The DX Leaders」は日本語でお届けするニュースレターです。AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。
GraphQL APIはより効率的で柔軟な代替手段として登場しましたが、RESTは長い間APIアーキテクチャーの標準となっています。RESTは、ネットワーク化されたハイパーメディア・アプリケーション用の構造化されたアーキテクチャー・スタイルであり、キャッシュ可能でステートレスなクライアント／サーバー通信プロトコル（通常はHTTP）を使用するように設計されています。
GraphQLとRESTのどちらを選択するかは、主に、眼前の作業に最適なツールは何かという観点で決定すべきです。GraphQLとRESTはどちらもクライアントがサーバーと通信し、データを要求できるようにしますが、GraphQLシステムの普及を説明する決定的な違いがあります。
REST APIはリソース（クライアントがアクセスできるあらゆる型のオブジェクト、データ、サービスなど）を中心に設計されており、リソースごとに異なるエンドポイント（URL）を持つことで機能します。これらは固定データ構造を使用して、クライアントに提供するリソースの形状とサイズを決定します。
クライアントがリソースを要求すると、サーバーはそのリソースに関連付けられたすべてのデータを含む完全なデータセットを返します。クライアントがデータのサブセットしか必要としない場合でも、すべてのデータを受信します（オーバーフェッチ）。クライアントが複数のリソースにまたがるデータを必要とする場合、最初のリクエストからのデータ取得が不十分なため（アンダーフェッチ）、多くの場合、APIコールを複数回行うことになります。
一方、GraphQLは、データの完全でわかりやすい説明を提供する単一のエンドポイントを使用します。GraphQLクエリーはリソースのプロパティーにアクセスし、リソース間の参照を追跡できるため、クライアントはGraphQLサーバーへ1回リクエストすることで必要なデータをすべて取得し、オーバーフェッチやアンダーフェッチの問題を回避できます。
RESTfulアーキテクチャでは、データの構造を変更すると、システムエラーやユーザーへのサービスの中断を防ぐために、多くの場合チームがAPIをバージョン管理することが必要になります。
つまり、開発者らは構造を変更するたびに新しいエンドポイントを作成する必要があり、その結果、APIバージョンが複数になり、保守プロセスが複雑になるのです。
GraphQLでは、クライアントがクエリーで要件を指定できるため、バージョン管理の必要がなくなります。新しいフィールドがサーバーに追加されても、それらのフィールドを必要としないクライアントはこの影響を受けません。逆に、フィールドが非推奨になっても、クライアントはクエリーを更新するまでフィールドを引き続きリクエストすることができます。
REST APIは、HTTPステータス・コードを使用してリクエストのステータスまたはその成功を示します。各ステータス・コードには特定の意味があります。リクエストが成功すると200ステータス・コードが返されますが、クライアント・エラーでは400ステータス・コードが返され、サーバー・エラーでは500ステータス・コードが返されることになります。
GraphQLは、エラーをさまざまな方法で処理します。すべてのリクエストは、エラーが発生したかどうかに関係なく、200 OKステータス・コードを返します。エラーの伝達にはHTTPステータス・コードは使用されません。むしろ、システムがデータとともに応答本文のエラーを伝達します。
このアプローチでは、クライアントが応答本文を解析してリクエストが成功したかどうかを判断する必要があるため、GraphQL APIのデバッグがやや困難になることがあります。
RESTにはリアルタイム更新のサポートが組み込まれていません。ウェブやモバイル・アプリケーションでREST APIを使ったリアルタイム機能が必要な場合、開発者は通常、ロング・ポーリング（クライアントが新しいデータを得るために繰り返しサーバーをポーリングすること）、サーバー送信イベント、WebSocketなどのテクニックを実装しなければならず、アプリケーションをさらに複雑にします。
これに対して、GraphQLには、サブスクリプションを使用したリアルタイム更新のサポートが組み込まれています。サブスクリプションはサーバーへの安定した接続を維持し、特定のイベントが発生するたびにサーバーがクライアントに更新をプッシュできるようになるため、クライアントが関連するAPIデータを常に把握できるようになります。
RESTエコシステムは、開発者が利用できる幅広いツール、ライブラリー、フレームワーク、チュートリアルを備えて確立されています。ただし、REST APIを使用するには、多くの場合、チームが複数のエンドポイントをナビゲートし、各API固有の規則やパターンを理解する必要があります。
GraphQLは比較的新しいものですが、GraphQLエコシステムはその導入以来大幅に成長し、フロントエンドとバックエンドの両方のサービス開発にさまざまなツールやライブラリーが利用できるようになりました。
GraphiQL、Apollo Studio、GraphQL Playgroundなどのツールは、GraphQL APIの探索とテストのための強力なブラウザ内統合開発環境（IDE）を提供しています。さらに、GraphQLはコード生成を強力にサポートしているため、クライアント側の開発が簡素化されます。
REST APIは、ETagや最終変更ヘッダーなどのHTTPキャッシング・メカニズムに依存しています。キャッシング戦略は効果的ではありますが、実装が複雑で、すべてのユースケースで一貫してパフォーマンスを最適化できるとは限りません。
GraphQL APIは、クエリーの動的な性質により、キャッシングがさらに困難になることがあります。ただし、永続化クエリや応答キャッシング、およびサーバー側キャッシングを使用すると、これらの課題が軽減されるため、GraphQLアーキテクチャに効率的なキャッシング戦略が得られます。
GraphQLがGraphQL Foundationに移行して以来、開発者はJavaScript、Python、Ruby、PHPなど、さまざまなプログラミング言語向けの実装を実現してきました。また、GraphQL APIは、Github社、Pinterest社、PayPal社、Shopify社、Airbnb社などの無数の企業で採用されており、より多くのクライアントがデータ仕様を合理化し、過剰または不適切なネットワークデータ送信を減らし、全体的なデータフェッチ機能の向上を図れるようになっています。1
さらに、企業や開発者は、GraphQLアーキテクチャのオープンなフェデレーションを推進しています。現在のイテレーションでは、GraphQLフェデレーションは個別のGraphQLサービスを取得し、それらを単一のGraphQL APIに集約します。これは、基盤となるすべてのバックエンド・データへのエントリー・ポイントとして機能し、単一リクエストのデータ取得を容易にします。ただし、フェデレーションの実装は唯一のベンダーに限定されています。
これに対応して、GraphQL支持者は、GraphQL限定の集約ではなく、GraphQL APIと非GraphQL APIの両方からのデータ集約を容易にする民主化されたフェデレーションを提唱しています。2
参考情報
IBM API Connectの無料評価版を試すか、IBMのエキスパートにご相談ください。API管理を最適化する準備ができている場合でも、詳細を検討中の場合でも、貴社のデジタル・トランスフォーメーションをサポートします。
AIを活用したソリューションで、統合プロセスの可能性を最大限に引き出します。まずは、IBMのエキスパートへの相談を予約するか、製品資料をご覧ください。
セキュアかつ高パフォーマンスなメッセージング・ソリューションであるIBM MQは、貴社のビジネスを強化します。無料評価版を試すか、IBMのエキスパートに相談して、IBM BQでどのように貴社の業務を変革できるかをご確認ください。
サイズや距離にかかわらず、高速でセキュアなファイル転送が行われます。IBM Asperaを今すぐお試しください。データ・ワークフローを合理化して高速で効率的なものにしましょう。
アプリとデータを簡単につなげることで、ビジネスを変革します。無料評価版を今すぐ試し、IBM App Connectでどのように統合への取り組みが合理化できるかをお確かめください。
IBM DataPower Gatewayがクラウドおよびオンプレミスのアプリケーションのセキュリティー、制御、パフォーマンスをどのように強化できるかを確認できます。今すぐ専門家への相談を予約し、コンテナの無料評価をお試しください。
ハイブリッド・マルチクラウド・プラットフォームであるIBM webMethodsを使用してアプリケーションを統合し、作業を自動化します。
IBMインテグレーション・ソリューションでビジネスの可能性を解き放つ、アプリケーションとシステムを接続してクリティカルなデータに迅速かつ安全にアクセスできます。
IBMのクラウド・コンサルティング・サービスで新しい機能にアクセスし、ビジネスの俊敏性を高めましょう。ハイブリッドクラウド戦略や専門家とのパートナーシップを通じて、ソリューションを共創し、デジタル・トランスフォーメーションを加速させ、パフォーマンスを最適化する方法をご覧ください。
脚注
1 「IBM acquires GraphQL startup StepZen to step up its game in API Management」、 TechCrunch社、2023年2月8日
2 「Why GraphQL Needs an Open Federation Approach」、 The New Stack、2023年11月16日