GraphQLリゾルバーの仕組み ― クエリがデータになるまで

そこで活躍するのが「リゾルバー」だよ。GraphQLのスキーマにはデータの型を定義するんだけど、各フィールドに対して「このフィールドのデータはこうやって取ってきてね」という関数を紐づけるんだ。それがリゾルバーだね。

実際にはすべてのフィールドに書く必要はないよ。親オブジェクトのプロパティ名とフィールド名が一致していれば、デフォルトリゾルバーが自動で値を返してくれるんだ。明示的に書くのは、データベースに問い合わせたり外部APIを呼んだりする必要があるフィールドだけだよ。

まずGraphQLのスキーマ定義言語（SDL）で型を書いて、それに合わせてリゾルバーを実装するアプローチだよ。「設計図を先に描いて、それから配管工事をする」イメージだね。逆にコードファーストは、TypeScriptなどのコードからスキーマを自動生成する方法で、型安全性が高いメリットがあるよ。

GraphQLのクエリはツリー構造だよね。たとえば「ユーザー → その投稿一覧 → 各投稿のコメント」みたいに。親フィールドのリゾルバーが返した結果が、子フィールドのリゾルバーに渡されて、さらにその子へ…と連鎖していく。これがリゾルバーチェーンだよ。

そのとおり！ Queryは読み取り、Mutationは書き込み、Subscriptionはリアルタイム通知の入り口だよ。すべてのリクエストはまずこのルートリゾルバーから始まって、そこからツリーをたどっていくんだ。

大ありだよ！ たとえばユーザー10人を取得して、各ユーザーの所属チームをリゾルバーで取る場合、素朴に書くとチームの取得が10回走る。これがN+1問題だね。解決策がDataLoaderパターンで、同じイベントループ内のリクエストをまとめて1回のバッチクエリにしてくれるんだ。

GraphQLの面白いところは、エラーが起きてもレスポンス全体が失敗にならないことだよ。エラーが発生したフィールドだけnullになって、errorsフィールドにエラー情報が入る。正常に取れた他のフィールドはちゃんと返されるんだ。REST APIの「全部成功か全部失敗か」とは違うアプローチだね。

contextという仕組みがあるよ。リクエストごとに認証情報やDB接続プールなどを詰め込んだオブジェクトを作って、すべてのリゾルバーの第3引数として渡すんだ。これでどのリゾルバーからでも共通リソースにアクセスできるよ。

ここがディープなポイントだよ。Queryの同じ階層のフィールドは並列に実行できるんだ。でもMutationだけは例外で、スキーマに書かれた順番で直列実行される。データの整合性を保つためだね。だからMutationのフィールド順序は設計上とても重要なんだよ。

Federationでは複数のサブグラフ（マイクロサービス）がそれぞれ自分の担当する型のリゾルバーを持つんだ。ゲートウェイがクエリを分析して、どのサブグラフにどの部分を問い合わせるか計画を立てる。各サブグラフは__resolveReferenceという特殊リゾルバーで、他サービスから参照された型のデータを返すよ。分散システムでもリゾルバーの仕組みが一貫しているのが、GraphQLの強みだね。