知り合いにおすすめされたHow To GraphQLを読みながらまとめる。
GraphQLは、 大雑把に言うとRESTオルタナティブな技術です。How To GraphQL(長いから次からHTG)はGraphQLとRESTの比較から始まる。その比較からおっていきましょう。
RESTの仕組み
HTGからひっぱてきたRESTの仕組みについての画像。
エンドポイントを用途ごとに設けて、欲しい情報に合わせてそれぞれのURLにリクエストを投げるおなじみのスタイル。
おなじみではあるが、実はこのやり方にはいくつか欠点がある。最大の２つは「無駄なデータのやり取り」と「連続でリクエスト」だ。
つまり、上に載せた画像だと、ユーザ名（User.name）だけ欲しいのにUser全部を持ってきちゃう。User.name以外は必要ないのに。このエコの時代にありえない。
ユーザ名の取得が一人ならまだ大した無駄なデータ量じゃないけど、これが数百、数千のユーザの情報を取得するとなると全然エコじゃない。
また、RESTだと複数回連続でリクエストする場面がよくある。これはAPI設計をいかにうまいことしてるかとかも関係してくると思うけど。RESTが特定のデータのために固有のエンドポイントを設ける仕組みなんだから、そうなるのは避けられない運命。
上に載せた画像の場合、User情報、Posts情報、Follower情報と連続でリクエストを投げてる。似たような状況を僕も見たことがある。これらの問題を改善したい！そこでGraphQLの登場です。
GraphQLの仕組み
GraphQLはエンドポイントが一個。エンドポイント使い回し。リサイクル。超エコ。
すでにエコの観点で見てもGraphQLが最高です。割り箸とマイ箸くらい意識の差を感じる。
エンドポイントが一個なのでGraphQLはエンドポイントではなくクエリを発行することによりリクエストするデータを指定します。
「Userのnameとposts。あ、postsのtitleも一緒にお願い！」というふうに、必要なものだけをリクエスト。しかも、「あ、ついでにあれと、あれも」という具合に、RESTじゃできなかった自由さでデータをリクエストできるんです。エコなうえに便利だ。
どうしてそんな阿吽の呼吸が働くかというと、The Schema Definition Language(SDL)という定義が存在しているからです。クライアントとサーバ間でのルールを取り決めるものです。
では、実際のSDLとクエリを実例を交えて見てみましょう。
SDLとクエリ
SDL
これはPersonを定義したSDL。
みたまま、Personにnameとageというフィールドを定義している。それぞれの型を指定し、「!」をつければ必須項目として定義できる。
これはPostのSDLで、注目すべきなのはauthorのフィールドだ。先程定義したPersonが指定されている。このようにして、要素同士を関係付けることができる。
Post要素の追加に伴って、Personの方はpostsフィールドを追加する。括弧がついているのは、Postが配列で挿入されるため。
クエリ
今度はクエリを見てみよう。
こんな感じでクエリを発行する。お察しの通り、これでAPI側からすべてのPersonのnameが返ってくる。
ちなみに、ほかの全ての情報を従えてる親の要素、ここでいうallPersonはルートフィールドという特別な肩書を持っているので、頭の隅に入れておこう。いわずもがな、nameに続けてidを書けば、nameと仲良く並んでidも返ってくる。うん。いい感じ。
クエリは引数を付帯することができる。たとえば、先程のallPersonの例を活用してみよう。
こう書いた場合、引数の「last:2」によって最新の二つだけをレスポンスとしてよこしてくる。便利な引数を覚えて使っちゃお！
ミューテーション
ここで新らしく重要なコンセプトを紹介します。ミューテーション、それはクエリの一種で、これを発行するとデータを作成・更新・リアルタイム通信が可能になる。な、なんだってーーー。
もはやRESTと比べる意味がわからないほどのスーパー働き者のGraphQL。
新たなPersonを作るミューテーション。 はじめにmutationでくくり、必須項目を埋めるために引数に名前、年齢を加えている。その下のname, ageは普通のクエリの発行と何も変わりない。Personを作成後に追加した要素のname, ageが返ってくる。
続いて、リアルタイム更新について。
リアルタイム更新にはsubscriptionを使うよ。Personが更新された場合、更新された要素のname, ageがAPIからプッシュされてくる。めっちゃ便利ね。
スキーマの定義
今度はこれまで使ってきたmutationとかsubscriptionとかの定義について。
こんな感じにQuery, Mutation, Subscriptionでそれぞれまとめてくくっちゃう。
最後にスキーマの例を記載して〆にします。これでGraphQLの基礎はおｋ！だと思います。また後日、GraphQLのクライアントとサーバ周辺についての記事書きます。
