【初めてのGraphQL】解決できる課題とそのユースケースについて
0
はじめに
様々な企業で導入の進みよく耳にするようになったFacebook製の技術GraphQL。
結局どんな課題をどの様に解決するものか気になりませんか？
ここではGraphQLに最初に触れる際に読む記事として、理論的背景からその効果、適するユースケースを紹介します。
GraphQLはグラフ理論を応用した技術
世の中の事象の多くはグラフを用いてモデリングできます。
グラフとはなんぞやというとノードとエッジで構成されるものです。
すなわち点と線で構成される図のことなのです。
このような構造で説明できるものは世の中にたくさんあります。
例えばSNSのユーザとユーザ同士がつながっている構造です。
各ユーザがノード、ユーザ感の繋がりをエッジとすれば見事にグラフになります。
またSNS投稿と、それに対してのいいねの関係もグラフに落とし込めます。
投稿といいねをノードとして、その間をエッジで繋げばグラフが一つ完成です。
グラフ理論はこの様に現実の問題を数学の世界に持ち込むことで役に立つ性質を導出しようとする学問です。
ここで詳しく紹介しませんがグラフ理論の有名な活用例として大数学者オイラー考案のケーニヒスベルクの橋問題があります。
皆さんも一度は耳にしたことがあるのではないでしょうか。
https://ja.wikipedia.org/wiki/%E4%B8%80%E7%AD%86%E6%9B%B8%E3%81%8D
GraphQLもこの理論のもとに確立されています。
では一体GraphQLが解決する課題は何でしょうか？
RESTのシンプルさがもたらす光と闇
RESTはシンプルで現在世界で最も使用されているプロトコルの一つだと言っても過言ではないでしょう。
しかしそのシンプルさはときに以下の問題を引き起こします。
データの過剰/過小な取得
RESTは各エンドポイント毎にある程度返却するデータの形が決まっています。
その結果ユースケースに対して過剰なフィールドの取得につながる事がしばしばあります。
例えばユーザの名前さえあればいいのにemailまでついてきたり。
逆に一つのエンドポイントが返すデータだけではクライアントが必要とするデータとしては不十分な場合があります。
その結果複数のリクエストを飛ばす結果になります。
エンドポイント管理の煩雑さ
またRESTにおいて一つのエンドポイントと複数のユースケースという対応はあまりマッチしていません。
その結果、クライアントのユースケースが増えるたびにエンドポイントも増える傾向にあります。
全く異なるユースケースのためなら仕方ないです。
しかしユーザと投稿をまとめて取得するといった微妙な、しかも増えがちなケースのためにエンドポイントを増やすのは面倒です。
これらのRESTの課題を解決しようと編み出された技術がGraphQLです。
GraphQLが実現する柔軟なAPI
GraphQLは一つのエンドポイントにSQLを簡易化したようなクエリを送ることでRESTの課題を解決します。
クエリで返却値を指定できるので必要十分なデータのやり取りが可能です。
さらに必要なエンドポイントは一つであり、管理の煩わしさからも開放されます。
GraphQLのクエリの形式
GraphQLのクエリ形式はまさにグラフです。
返却したいデータのエンティティをノードとしてjsonに似た形で定義します。
例えばユーザ、投稿などはそれぞれノードになりえます。
更にエンティティ間の繋がりをエッジとして各クエリフィールドで定義します。
例えばユーザとそのユーザの投稿の関係性などです。
こう見ればGraphQLは従来のRESTプロトコルの課題を解決した魔法のようなプロトコルに思えます。
しかし一つの技術があらゆるケースへの銀の弾丸とはなりえないのが世の常です。
であるならばGraphQLはどのような状況で使用すべきなのでしょうか？
多様なユースケースのためにこそ生まれたGraphQL
GraphQLがフィットするケースは簡単です。
前述のRESTの課題たち、言い換えるならば大小含めて多様なユースケースが存在しうるケースです。
例えばGitHubやFacebookなどAPIを公開したならば世界中のディベロッパーが様々に使用する場合が当てはまります。
一方ですべてのプロダクトがGraphQLを採用すべきでない理由も単純です。
それはRESTに比べて必要な技術・ナレッジ・人材がまだ不足しているからです。
もちろんGraphQLはツール志向が強く、加えてRESTと併用する漸進的導入を全面に押し出していますからそれ自体の導入は簡単です。
しかしRESTのシンプルさで十分な場合においてGraphQLのメリットを存分に享受することは難しいでしょう。
特に各技術同士の結合は疎であることが理想だとはいえ、現実問題としてそれが密であることがほとんどですし、そのほうがメリットがある場合もまた多く存在します。(例えばRESTとwebフレームワークの密結合など)
そのため結局全体としては導入コストが馬鹿にならないという結果になるでしょう。
GraphQLはその特性が活かしきれる多様なユースケースが存在する場合において使用すべきなのです。(少なくとも現在は)
まとめ
GraphQLはRESTの抱えていた課題を解決しようと考案されたクエリ志向の仕様です。
しかしどの技術でもそうであるようにその技術が適する場合を見極めて使用することが望ましいと考えられます。
