APIを1つずつ個別に呼び出すことも可能だ。だがそれでは時間がかかる。各APIには大小さまざまな違いがあるため、それらを呼び出すのはマイクロサービス環境だと難しくなる恐れがある。どのAPIを呼び出せばよいのか分からない。どのAPIが最新データを提供するのかも分からない。相手が倉庫管理システムなのかERPなのか、それともその他のシステムなのかも分からない。

全てのルールを決める1つのクエリ

　GraphQLでREST APIを利用する場合、必要な情報を記述したクエリを1つ発行するだけだ。そのクエリに伴う面倒な処理はGraphQLレイヤーが行い、その呼び出しを個別のAPIに直接送る。

　その結果、要求したデータを含む1つのJSONオブジェクトが返される。それ以上でもそれ以下でもない。「テーブル1からXを選び、テーブル2にそれを結合する」という要求をデータベースに行うSQLクエリのようなものだと考えればよい。

　GraphQLは開発者が抱える多くの悩みを解消する。Webページ、アプリケーション画面、その他のエクスペリエンスを最初のインスタンスで素早くレンダリングできるだけではない。データを過剰に取り込んだりデータの取り込みが不足したりすることもない。

データ取り込みの過不足

　取り込むデータの不足はREST APIではよく起きる問題だ。遅延が大きく帯域が狭いセルラーネットワークに接続された古いスマートフォンなど、処理能力に制限がある端末は特に影響を受ける。多数のHTTP要求を行えば、ページの読み込み速度が大幅に低下する。

　データの過剰取り込みもパフォーマンスに深刻な問題を引き起こす恐れがある。例えばスマートウォッチ向けに製品ページを構築しているとする。必要なのは製品名、画像、価格だけなのに、100件のフィールドが返されることがある。

　GraphQLは多くのメリットをもたらす。

　全てのAPIを呼び出すのはGraphQLレイヤーだ。開発者ではない。そのためメンテナンスが必要なコードは少ない。その上、GraphQLでは全ての要求がデータセンター内で行われる。データセンター内ならば遅延時間がほぼゼロで、事実上演算能力が制限されない。エンドユーザーにとってはアプリケーションの読み込みが高速になる。

　GraphQLはレイヤーなので、フロントエンドからバックエンドが切り離される。開発者は容易かつ迅速に変更を加えることができる。これは、新機能を継続的にテストしてリリースする必要に迫られるITチームにとって役に立つ。

その他のメリット

　開発者がGraphQLについて知っておくべきことは他に何があるだろう。

　GraphQLは製品でも実装でもない。GraphQLは仕様だ。使用するプログラミング言語による差異は生じない。開発者はこの仕様に従うコードを記述するだけだ。HTMLのようなものだと思えばよい。HTMLでは、Webページをレンダリングするコードは個々のブラウザが実装する。さらに、GraphQLはREST APIを補完するものであり、置き換えるものではない。

　多くの技術と同様、デメリットもある。GraphQLはメンテナンスを必要とするレイヤーだ。セキュリティに対して責任を持つのはユーザーだ。GraphQLの複数のエンドポイントやスキーマを組み合わせるのは難しくなる恐れがある。

　とはいえ、GraphQLのメリットはデメリットを補って余りある。

　ますます競争が激化する市場で商取引を行う企業は、ツールを利用してできる限り機敏になり、時間を節約して最高のカスタマーエクスペリエンスを提供する必要がある。

　商用アプリケーションを構築する場合、GraphQLが理想的なツールになる。

ケリー・ゴーチュ氏はcommercetoolsのCPO（最高製品責任者）で、『GraphQL for Modern Commerce』（O'Reilly、2020年）の著者でもある。