# GraphQL 輪読会
## 一章
### 2021-07-29

- 七五三
- 「プログラマーでナイトの称号を授与された」
- どんな世界観だ
- 1.1
- 「クエリを実行するたびに型システムに基づいてバリデーションされます」
- 「GraphQLのサービスは必ずGraphQLスキーマにのっとって型が定義されています」
- このへんが開発時に便利そう
- 型が無い言語はどうなるんだろう…
- 1.1.2
- 階層構造
- クエリはレスポンスと同じ構造を取ります
- よさそう
- プロダクト中心
- 文の意味があまりわからん…
- 言語やプラットフォームを選ばないという意味？
- 強い型付け
- 現状よくわからん…
- サーバー側の実装もGraphQLのgemを入れればいい感じにバリデーションされて意図しない値を返さないようにしてくれるのか？
- 自己参照
- よくわからん
- 1.2
- 言語仕様を作るのはプレビュー版でも4年もかかるのか…
- PJ大変そう…
- 1.4.1
- 過剰な取得
- わかる
- 通信量増えるとかもわかる
- 高速にレスポンスをうけとれる**見込み**
- サーバーが何も考えずに返すより計算量が増えるということかな？
- 1.4.2
- このセクションの内容はRESTをDisりすぎているように感じる(1.4.3のことを言いたいのだとは思うが)
- こういう場合はpeopleのエンドポイントにfilmsも含めるべきな気がする(1スクリーン1API)
- APIの改修に手間がかかるというのはわかる
- (現時点では)GraphQLのほうが便利そうというのもわかる
- 1.4.3
- それ用のエンドポイントが増える
- わかる
- 多くの組織ではGraphQLとRESTを併用している
- そうなのかい…
- 現状よくわからん…
- 「GraphQLサーバーからRESTのエンドポイントへリクエストする」
- この表現もよくわからん…
- 1.5.1
- Apolloでてきた

- 金澤
- GraphQLとは
- 必要なデータだけをクライアントサーバ間で取得できる仕組み
- 問い合わせ言語としてのGraphQLもあり、ランタイムとしてのGraphQLもある？（サーバーと言う意味で）。ここらへん微妙な理解
- 不要なデータを受け取ることがないので、noteがやらかしたような情報漏えいが起きる可能性は低いのかも？

- メリット
- レスポンスのデータを受け取ってさらにリクエストを送るといったことをしなくていい
- REST APIを練習以外で実装したことがないのであまりイメージがつかない
- GraphQLでも型システムがあって、フロントではTSで型システムがあるから、開発体験としては良くなるのかな？
- REST API開発時のつらみがよくわかってない。エンドポイントが増えることでどんなことがつらいの？
- と思ったら、「過剰な取得」を見てつらみがチョットわかった
- エンドポイントが1つなので、開発時にエンドポイントをほぼ意識することがなくなる
- `/graphql`にPOSTリクエストを投げる形
- > 「`/graphql`に対してリクエストボディにGraphQLのクエリ言語を記述し、POSTリクエストをする」 ソフトウェアデザイン2021年8月号
- クライアントが必要なデータを自分でクエリする
- デメリット
- メリット書きまくるならデメリット（というか注意点？）も書いてほしかった著者さん
- GraphQLだとどんなリクエストでも`/graphql`にPOSTリクエストをする仕様なので、Redashとかでログを漁りづらいのは感じた
- GETやDELETEの内容なのにPOSTしてたりややこしかった記憶
- 慣れている先輩から言わせると開発体験はとても良いらしい

- 感想
- REST APIの開発に慣れている人なら、GraphQLとの違いをかなり実感できそう
- 「過剰な取得」「過小な取得」は実際にけっこう起きるの？RESTゴリゴリ開発してる人に聞きたい
- 社内だと別チームがエンドポイントが増えすぎてつらいというのは言っていた
- RelayとApolloの違い、1章だけではよくわからんけど弊社ではApolloを使ってる

- otegami(児玉)
- プログラマーは一貫して同じ課題に取り組み続けています。世界のどこかにあるデータを可能な限り素早く読み込むという課題です。

- 1.1 GraphQLとは
- APIのための問い合わせ言語
- GraphQLは通信プロトコルを指定していません
- 一般的にはHTTPプロトコルが使用されています
- HTTP 以外のプロトコルで利用されているの？
- GraphQLのクエリでは、必要なデータだけを指定する
- レスポンスは JSON 型
- 1回のHTTPリクエストで2つの異なる種類のデータを受け取ることができる
- リソースを指定しない
- 構造が見えて来づらくない？
- GraphQLのサービスは必ずGraphQLスキーマにのっとって型が定義される
- APIリクエストを組み立てるための設計図として型定義を利用する
- これって感覚的にわかりづらくない？
- RESTful だとリソースの予測ができる

- 1.1.1 GraphQLの言語仕様
- GraphQLはクライアント/サーバー通信のための言語仕様
- GraphQLの言語仕様はクエリを書くための言語と文法を規定している

- 1.1.2 GraphQLの設計原則
- 階層構造
- プロダクト中心
- データを必要とするクライアントの言語やランタイムに従って実装される
- 強い型付け
- クライアントごとのクエリ
- 自己参照
- GraphQL言語はGraphQLサーバー自身の型システムを問い合わせられるようにできています。
- どういうこと？

- 1.2 GraphQLの誕生
- 特になし

- 1.3 データ通信の歴史
- 1.3.1 RPC
- 1.3.2 SOAP
- 1.3.3 REST > RESTful
- リソースのネットワークは仮想的な状態機械であり、アクション（GET、PUT、POST、DELETE）は状態機械の状態を変更する操作
- リソース指向アーキテクチャ

- 1.4 RESTの課題
- RESTが適合しない状況が生まれ始めた
- どんな状況下を考えてみるのが良さそう？
- 次で説明が出ていた

- 1.4.2 過剰な取得
- `https://swapi.co/api/people/1/`
- 過剰な値を取得してしまっている
- `https://swapi.co/api/people/1/profile`
- みたいに生やしちゃダメなの？
- 変更ごとに増やすと一気に増えてしまう

- 1.4.2 過小な取得
- 映画のタイトルだけが欲しい場合
- https://swapi.co/api/people/1/
- 対応するユーザーの映画情報を全て取って来る必要がある？
- Rails でいうと pluck とかで上手いことやれてる？（Rails <-> DB ）
- https://swapi.co/api/people/1/movies/
- https://swapi.co/api/people/1/movies_details/
- REST API の切り方を少し勉強する必要がありそう？

- 1.4.3 RESTのエンドポイント管理
- REST APIの課題は自由度の低さ
- 表現はできるけど、柔軟にクライアント側の要求に対応できない
- GraphQLには基本的に単一のエンドポイントしか存在しない
- クライアント側のみで、操作が完結するの？
- バックエンド側もデータ構造の変更の際は対応する必要性がありそう？
- GraphQLサーバーからRESTのエンドポイントへリクエストする
- 間違ってはいない？では、最適な方法は何なのかな？

- 1.5 GraphQLの実情
- 必要なデータを正確に指定して受け取れるという利点は、RESTから切り替えるに値するほど大きい
- 取得するデータ量が少なくなると、双方向通信などでも活躍できそう
- ニューヨーク・タイムズ、IBM、Twitter、Yelp が GraphQLの恩恵をたびたび布教している
- どんな発表内容なのか調べてみると具体的な有用性がわかりそう
- 共通しているのは、大きな企業になるな（開発スピードが上がりそうな印象を受けたが、スタートアップ系はどうなのだろう？）
- 型の制約の問題？

- 1.5.1 GraphQLのクライアント
- GraphQLは小さな仕様群にすぎず、それ以上のアーキテクチャの決定権は開発者にある
- ここでのアーキテクチャとは、何を指すのか？
- 仕様群に過ぎない、他にはこの言葉でどのようなものを指すのだろう？
- ネットワークのリクエスト
- データのキャッシュ
- ユーザーインターフェースへのデータの注入

## 二章
### 2021-08-05

- 要約
- わからないポイント
- はなしたいポイント

- 七五三
- 要約
- グラフ
- 相互に接続されたオブジェクトの集合を形式的に表現するために使用する
- オブジェクトとコネクションから構成される
- オイラー路
- ちょうど2つのノードの次数が奇数 or すべてのノードの次数が偶数
- 一筆書きできるかの判定できる
- わからないポイント
- はなしたいポイント

- 金澤
- 要約
- 数学のコンテキストにおいて、グラフとは概念同士の関係性を表現する
- エクセル等の「グラフ」がどうしても先に脳裏によぎるが別物だと捉えたほうがいい
- 相互に関係性のあるオブジェクトの集合で表現する
- node or vertex（各オブジェクト）, edge（各オブジェクトのコネクション）
- DOMツリーは「木のグラフ」
- フェイスブックはお互いが友達になるので無向グラフ
- Twitterは相手をフォローしてもフォローバックされない可能性があるので有向グラフ
- わからないポイント
- G = (V, E) ←わからなくてもいいと思うので優先度低め
- はなしたいポイント
- やっぱりそんなに深堀りしなくてもいい章だったかも？

- 児玉
- 要約
- グラフとは、(物や人、アイデア、データといった)概念同士の関係性を図示するための考え方
- グラフは、データを含むオブジェクトとそれらのコネクションから構成される
- G = (V: 頂点(node), E: エッジ(edge))
- グラフの種類
- 無向グラフ: 順序がない、ノード間の移動は自由、非線型である
- 有向グラフ: 順序があり、ノード間に流れ（向き）がある
- 木: 階層的なグラフになっている
- わからないポイント
- なし
- はなしたいポイント
- オイラー路 => GraphQL の API で利用しそう?()
- 階層構造を持つものは、グラフの考え方を取り入れられそう
- HTML が例として挙げられているが、コンポーネントなどにも応用できそう
- 新しいプロジェクトのソースコードを読むのに応用できそう

## 三章
### 2021-08-12

金澤
- 要約
- SQLとGraphQLは似ている
- どちらもデータがある場所への問い合わせ言語
- クエリを書く点が同じ
- SQLとGraphQLの違い
- SQLはDBへクエリを発行する
- GraphQLはWeb上にデータがある場所へクエリを発行する
- DB、ファイルシステム、REST API、別のGraphQL APIなど
- GraphQLのレスポンス
- dataフィールド：クエリの実行に成功したらデータが格納される
- errorsフィールド：エラーハンドリング時にエラー内容が含まれる
- クエリ引数
- 結果をフィルタリングしたいときの機能
- GraphQLの型
- スカラ型：プリミティブ型みたいなもん
- Integer, Float, String, Boolean, ID
- オブジェクト型：一つ以上のスキーマで定義されているフィールドの集合
- ユニオン型：TypeScriptのユニオン型みたいなもん？
- インターフェース：TypeScriptのインターフェースみたいなもん？
- クエリの種類
- query: 取得
- mutation： 作成、更新、削除
- subscription： 通知
- WebSocketを通じて通知を受け取る
- わからないポイント
- フラグメント
- イントロスペクション
- はなしたいポイント
- P42以降のクエリを試してみたい（時間あれば）

児玉
- 要約
- SQL はデータベースのための問い合わせ言語
- GraphQL はインターネットのための問い合わせ言語
- GraphQL のクエリ
- スカラー型（グラフの末端で利用される）
- オブジェクト型をグラフ理論でいう2つ以上のエッジを持つノード？
- フラグメント
- 同様のエッジとノードを持つものをまとめる(インターフェース&ユニオン型)
- イントロスペクション: APIスキーマの詳細を取得できる機能
- 興味あるポイント
- 抽象構文木: 処理を追ってみたい
- クエリを字句解析し独立したトークンに分解される
- トークンから抽象構文木を組み立てる
- はなしたいポイント
- イントロスペクションは、OpenAPI の代替となりうる

七五三
- 要約
- GraphQLはインターネットのための問い合わせ言語
- IDE(GraphiQL, GraphQL Playground)
- ホスティング可能
- 便利
- クエリ
- データの読み込み
- ルート型
- 選択セット(必要なフィールドを波括弧で囲んで指定)
- レスポンスを任意のものに書き換えられる
- 後方互換を気にせず開発できる？
- 管理が大変になる気もする
- 型
- スカラー型
- オブジェクト型
- オブジェクトをまとめる
- ユニオン型
- 使いみちがわからない
- インターフェースにしたほうがいいのでは？
- インターフェース
- ミューテーション
- データの書き込みとか
- サブスクリプション
- Websocketを通じて状態の変化を受け取ることができる
- イントロスペクション
- スキーマ詳細を取得できる
- 便利そう
- クライアント - サーバー間の無駄なコミュニケーションなくせる
- わからないポイント
- はなしたいポイント

## 四章
### 2021-08-12

- 要約
- わからないポイント
- はなしたいポイント

金澤

- 要約
- 「どんなデータを扱うか」をGraphQLが用意するSDLで書く
- 型をいろいろ書く
- 書いたものを「スキーマ」
- バリデーションする（ActiveRecord的なバリデーションとはまた違うが）
- スルー型： 中間テーブル的な？
- 取得するデータの量や順番を指定することもできる
- mutaionに持たせる引数が多くなりすぎたら、入力型を使って切り離すことができる
- スキーマのドキュメントを残す文化がある？そういえばうちにもスキーマドキュメントがあった
- わからないポイント
- 多対多の接続
- はなしたいポイント
- 理論だけだとあんまりわからんのでやっぱり書いてみないことには始まらないかも？

児玉
- 要約
- スキーマのデータ型を共通言語にして開発にまつわるコミュニュケーションを取ることができる
- 型 = 共通の言語（概念）: プロジェクト内で利用される特有のワード
- 型は固有のオブジェクトで、アプリケーションの特性を反映する
- 多対多 を中間テーブルなどを必要とせずに表現することができる
- スルー型: 関連に状態を持たせたいときに利用する
- ユニオン型とインタフェースの利用分け: 一つのノードして意味をなすか（？）
- ミューテーション: アプリケーションで使われる動詞と対応づけられる（リソースベースではなく、動作ベース）
- 興味あるポイント
- スキーマのドキュメント化はかなり便利そうだけど、実際のドキュメントを見てみたい

七五三
- 要約(感想メモ)
- 型
- nullableかどうかひと目でわかるのは良さそう
- カスタムスカラー
- どういうふうに定義できるかが説明されていないと意味がわからなかった…
- https://www.apollographql.com/docs/apollo-server/schema/custom-scalars/
- ミューテション
- strong parameterっぽい一面もあるという認識
- わからないポイント
- はなしたいポイント

## 五章
### 2021-08-19

児玉
- 要約
- わからないポイント(暫定メモ)
- resolver 内の parent の理解がまだ怪しい <= 読み直す
- はなしたいポイント

金澤

- わからない
- resolverのparent
- DateTimeのカスタムスカラー型を作るところ： `parseValue`, `serialize`, `parseLiteral`の3つの関数はGraphQLが独自で用意しているもの？ 「新しいスカラー型を作成する場合、3つの関数〜を追加する必要があります」とは？

しめ
- 感想
- 写経したらなんとなく動いたーにはなった
- エラーわかりにくい
- typoに15分くらい費やした
- 型定義typeDefs 文字列なの厳しいいい感じにsyntax highlightしてくれる拡張とかありそうだが…
- ORマッパーないと厳しい
- ActiveRecordさんいつもありがとう
- parent

## 六章
### 2021-09-09

児玉
- 要約(勉強になったポイント)
- キャッシュに関する REST の利点
- リクエストのレスポンスデータをそのリクエストにアクセスするための URL に対応づけてキャッシュに保存できる
- Apollo Client のポーリング実装のしやすさ
- わからないポイント
- はなしたいポイント

七五三
- 要約
- わからないポイント
- はなしたいポイント
-