スキップしてメイン コンテンツに移動

Reading: 初めてのGraphQL - 落ち穂拾い

MutationやSubscribeでできること、サーバーサイド・クライアントサイドの実装などについてざっくりと辿ったので残りは落ち穂拾い。

クエリとミューテーションはまだHTTPを使用しています。これらのオペレーションのいずれかをGraphQLサービスに送信する場合は、リクエストの引数reqがcontextハンドラに送信されます。しかしオペレーションがサブスクリプションの場合はHTTPリクエストがないため、req引数はnullになります。その代わりに、クライアントがWebSocketに接続したときにサブスクリプションの情報が渡されます。この場合、WebSocketのconnection引数がコンテキスト関数に渡されます。サブスクリプションを受け取った場合、HTTPリクエストヘッダーではなく、そのコネクションのcontextを使用して認可情報の詳細を受け取らなければいけません。

出典: 初めてのGraphQL 7章 GraphQL実戦投入にあたって

なんとなくHTTPを使用したコミュニケーションなんだなと思っていたけれど、Subscriptionを使ったリアルタイムの更新を実現する方法のイメージがついていなかった。言われてみれば当然なんだけど、WebSocketを使うらしい。
このとき、contexeに渡されるのがreqではなくてconnectionになるので、どちらのケースも対応できるような場合分けの書き方が必要と言うことで例示もあってよかった。

その他実際に使う場合には今後重要になりそうと思った点:
* リゾルバーでクエリの件数や深さを制限できる
* npmのパッケージで複雑度に係数をかけることもできる
* 導入にあたっては、既存のRESTと一気に切り替えない、併存させる、新しいエンドポイントはgraphqlに足す、などの対応が考えられる
* GraphQLでもスキーマ駆動には対応してる

それから、RelayというReact x GraphQLでフロントエンドの開発をするためのライブラリでいくつか追加実装があるみたいだけれど、この追加仕様を踏襲しているケースは多いらしく、一例としてGitHubのAPIの例が上がっていた。

Relayが要求するサーバ側(スキーマ)の追加仕様の狙いは次のとおりです。
オブジェクトの再取得を可能にするため
Connectionを通じたページングを実装するため
Mutationの結果を予測可能にするため

出典: 初めてのGraphQL 付録A Relay各仕様解説

少し読み切るのに時間がかかったけどようやく読みきった。
これだけではGraphQLを実践するのは厳しい感じがしたけど、少なくともこの内容を押さえていれば個別論点の話を見ても多少の想像が効くようになるんだと思う。