発行日：2023年12月8日
寄稿者：クリスタル・R・チャイナ、マイケル・グッドウィン
GraphQLは、クライアントがアプリケーション・プログラミング・インターフェイス（API）と対話する方法を指定するオープンソースのクエリ言語およびサーバー側のランタイムです。
GraphQLテクノロジーは、ユーザーが（多数のパラメーターを持つ複雑なエンドポイントにアクセスする代わりに）1行または数行でAPIリクエストを作成できる直感的な構文を使用しているため、APIクエリの生成と応答が容易です。GraphQLは、従来のRESTful アーキテクチャからのアップグレードです。
2010年代初頭、Facebookは大幅な成長と変革を経験しました。しかし、ユーザーベースの拡大とモバイル・アプリ環境が複雑になるに伴い、必要なクエリデータをすべて取得するために異なるエンドポイントへの複数回のラウンドトリップが必要となる既存のRESTful Approachは継続不可能になりました。
Representational State Transfer（REST）およびRESTful APIは、複雑なデータ駆動型のユーザー・インターフェイスを処理するのに十分な設備が整っておらず、特に限られたデータ・プランや高価なデータ・プランを使用するモバイル・ユーザーにとっては、遅延やデータの非効率などの問題が頻繁に発生していました。
これらの課題に対応して、Facebookのエンジニアは（シングルページ・アプリケーション・プラットフォームReactとともに）GraphQLを開発し、2015年にオープンソース・ソリューションとしてリリースしました。最終的に、Facebookは2018年にこのサービスを、AWS、Gatsby、Intuit、IBMなどのメンバー企業で構成される GraphQL Foundationに移転しました。
応答性の高いGraphQL APIを使用することで、少ないコードでデータのサイロ化を解消する方法を学びましょう。
IBM API Connectが最優秀賞を受賞
GraphQLアーキテクチャの宣言型データフェッチ機能は、いくつかの主要なコンポーネントとプロセスを中心に展開し、それぞれがデータの処理と処理において独自の役割を果たします。
そのコストには以下が含まれます。
GraphQLは、すべてのデータ型がGraphQLスキーマ定義言語（SDL）で記録される強力な型システムを基盤としています。型付きスキーマは、APIでクエリできるデータの型、並びにユーザーが使用できる型と操作の関係を決定します。言い換えれば、APIの機能とクライアントが対話できるデータの形式を定義するということです。
スキーマ内の各フィールドは、データを設定し、一連のフィールドに対する応答を決定するリゾルバーによってサポートされています。データベースやクラウド・サービス、または事実上あらゆるソースからデータを取得できるリゾルバーは、GraphQLオペレーション（クエリ、ミューテーション、サブスクリプションなど）をデータに変換するための指示を提供します。
クエリ・フィールドが実行されると、システムは対応するリゾルバーへの呼び出しを行い、次の値を生成します。フィールドがスカラー値（文字列や数値など）を生成すると、実行は完了します。フィールドがオブジェクト値を生成すると、クエリにはそのオブジェクトに関連するさらに多くのフィールドが含まれます。このプロセスは、スカラー・フィールドだけが残るまで続けられます。
リゾルバーは、データのフォーマットも容易にし、システムがさまざまなデータソースからの情報をつなぎ合わせるのにも役立ちます。
データ・クエリは、クライアントによってGraphQLサーバーに対して行われるリクエストです。クライアントが取得したいデータを指定します。クエリが受信されると、GraphQLはそのクエリをスキーマ定義に照合して検証し、クエリが有効であると仮定してこれを実行します。通常、クエリの構造は応答データの構造を反映しているため、データ要件が明示的かつ予測可能になります。
ミューテーションは、サーバー上のデータを作成・更新または削除するGraphQLのオペレーションです。これらは、RESTful APIのPOST、PUT、PATCH、およびDELETEのオペレーションに類似しています。
クエリの動作と同様に、GraphQLのミューテーションはスキーマとその定義に照合して検証されます。ミューテーションが検証後実行されると、サーバーはJSON応答を返します。
GraphQL APIはより効率的で柔軟な代替手段として登場しましたが、RESTとRESTfulは長らくAPIアーキテクチャの標準でした。REST APIは、ネットワーク化されたハイパーメディア・アプリケーション用の構造化されたアーキテクチャ・スタイルであり、キャッシュ可能でステートレスなクライアント・サーバー通信プロトコル（通常は HTTP）を使用するように設計されています。
GraphQLとRESTはどちらもクライアントがサーバーと通信し、データを要求できるようにしますが、GraphQLシステムの普及を説明する決定的な違いがあります。
REST APIはリソース（クライアントがアクセスできるあらゆる型のオブジェクト、データ、サービスなど）を中心に設計されており、リソースごとに異なるエンドポイント（URL）を持つことで機能します。これらは固定データ構造を使用して、クライアントに提供するリソースの形状とサイズを決定します。
クライアントがリソースを要求すると、サーバーはそのリソースに関連付けられたすべてのデータを送信します。クライアントがデータのサブセットしか必要としない場合でも、すべてのデータを受信します（オーバーフェッチ）。クライアントが複数のリソースにまたがるデータを必要とする場合、最初のリクエストからのデータ取得が不十分なため（アンダーフェッチ）、多くの場合、APIコールを複数回行うことになります。
一方、GraphQLは、データの完全でわかりやすい説明を提供する単一のエンドポイントを使用します。GraphQL クエリはリソース・プロパティにアクセスし、リソース間の参照を追跡できるため、クライアントは GraphQLサーバーへ1回リクエストすることで必要なデータをすべて取得し、オーバーフェッチやアンダーフェッチの問題を回避できます。
RESTアーキテクチャでは、データの構造を変更すると、システムエラーやエンドユーザーへのサービスの中断を防ぐために、多くの場合チームが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に集約します。これは、基盤となるすべてのバックエンド・データへのエントリー・ポイントとして機能し、単一リクエストのデータ取得を容易にします。ただし、残念ながら、フェデレーションの実装は唯一のベンダーに限定されています。
これに対応するため、IBMは民主化フェデレーションを提唱しています。これにより、GraphQL専用の集約ではなく、GraphQL APIと非GraphQL APIの両方からのデータ集約が容易になります。 2
IBM API Connectは、直感的な使い勝手により、APIの作成、管理、セキュリティーの確保、ソーシャル化、収益化までライフサイクル全体を一貫して支援し、オンプレミスおよびクラウド全体におけるデジタル・トランスフォーメーションを強力に後押しするAPI管理ソリューションです。
IBM API Connectを使用すると、実稼働レベルのGraphQL APIを数分で簡単に構築し、導入できます。データ・ソースの接続の詳細を指定するだけで、最適化された安全なGraphQL APIが即時に生成されます。
これらのフレームワークがAPIを構築するために採用する2つの異なるアプローチと、それぞれの長所と短所について学びましょう。
2023年版API管理に関するガートナー・マジック・クワドラントをお読みになり、IBMがAPI管理のリーダーとして認められ続ける理由をご確認ください。
IBM API Connectツールキットの詳細はこちら
包括的なAPI管理ソリューションでAPIの価値を最大化し、デジタル・ビジネスを推進します。
IBM、2023年ガートナー・レポート：API Managementにおける重要な機能でリーダーに選出
このチュートリアルでは、開発者がプロジェクトでテクノロジーを使用する方法を学ぶのに役立つ実践的な手順を紹介しています。
脚注
1 「 IBMがGraphQLスタートアップStepZenを買収、 API Managementでの取り組みを強化」（ibm.com外部へのリンク）TechCrunch、2023年2月8日
2 「GraphQLにオープン・フェデレーション・アプローチが必要な理由」（ibm.com外部へのリンク）The New Stack、2023年11月16日