hachimaki37/20240427-graphql

LT発表の資料です。新しくプロジェクト制度たるものができたので、起案して進めていきました（私を含めた2名体制）。なんとなくGraphQLのイメージがつき資料にまとめることができたので、社内で共有した内容をせっかくなので公開します。

Transcript

1. 昨今話題のGraphQLについて 色々調査してみた 2024-4-27
2. GraphQLとは - Web APIを開発するためのクエリ言語である。 - REST APIの問題を解決するために、Facebook(Meta)によって開発された。 - Web APIの開発において、REST APIと比較して柔軟かつ効率的なアプロー チを提供できる。 - GraphQLではクライアントが必要なデータの構造を定義することができ、 サーバから定義したものと同じ構造のデータが返される。 https://zenn.dev/nameless_sn/articles/graphql_tutorial
3. GraphQLの構成要素 Schema、Resolver、Queryの3つの要素で構成される - Schema：データ型(type)を定義 - Resolver：問い合わせを実行するメソッド - Query：GraphQLサーバへの問い合わせ内容 - Query　：Read - Mutaion ：Create、Update、Delete
4. リクエストからレスポンスまでの流れ - Query/Mutaionを使って、クライアントからGraphQLサーバへリクエストする - Resolverに定義したメソッドが呼び出され、実行結果をクライアントにレスポ ンスする
5. ソースコード Rails × GraphQL でTodoアプリを作ってみた - routes：開発環境は、GraphiQLを使って検証した（GraphQL APIを叩いた り、スキーマを確認できる便利ツール） - schema：tasks table, labels tableの2つ（1:nのリレーション）
7. 実行結果（Query） task 一覧を取得する
9. 実行結果 task, label 一覧を取得する
10. ※n+1が発生しているので改修します
11. 実行結果 task.id ごとに取得する
13. 実行結果 task.id に紐づくlabelsを取得する
15. 実行結果（Mutation） task を新規で作成する
17. 実行結果（Mutation） task を更新する
19. 実行結果（Mutation） task を削除する
21. イメージはつきましたか？
22. 調査テーマ
23. データの過剰取得をGraphQLを使って解消し、 恩恵を受けられるかを研究したい
24. REST APIの課題 課題1：固有のエンドポイントが必要 課題2：オーバーフェッチ(過剰取得)、アンダーフェッチ(過剰不足) 課題3：過剰なデータ取得によるレイテンシへの影響
25. REST APIの課題 課題1：固有のエンドポイントが必要 課題2：オーバーフェッチ(過剰取得)、アンダーフェッチ(過剰不足) 課題3：過剰なデータ取得によるレイテンシへの影響
26. 課題1: 固有のエンドポイントが必要 REST API： データシェイプごとに固有のエンドポイントを用意するため、エンドポイントを複数 用意・管理する必要がある。
27. 課題1: 固有のエンドポイントが必要 GraphQL： Query, MutationによってCRUD操作することが可能。GraphQLサーバのエンド ポイントを単一で用意・管理すれば良い。
28. REST APIの課題 課題1：固有のエンドポイントが必要 課題2：オーバーフェッチ(過剰取得)、アンダーフェッチ(過剰不足) 課題3：過剰なデータ取得によるレイテンシへの影響
29. 課題2 : 過剰取得、過剰不足の問題 GraphQLは、要求されたデータのみをレスポンスする。 そのため、REST APIにおけるオーバーフェッチとアンダーフェッチの問題を解決し てくれる
30. 例： Webとモバイルで表示する情報が異なる場合 REST APIの場合： Webとモバイルの2つのエンドポイントを用意する or マキシムでデータを取得して 必要な情報のみ表示する（オーバーフェッチ） Graphqlの場合： 取得したい情報をクライアントからQuery, Mutationを用いてGraphQLサーバにリ クエストすれば良い
31. REST APIの課題 課題1：固有のエンドポイントが必要 課題2：オーバーフェッチ(過剰取得)、アンダーフェッチ(過剰不足) 課題3：過剰なデータ取得によるレイテンシへの影響
32. 課題3 : 過剰なデータ取得によるレイテンシへの影 響 REST APIは、オーバフェッチが発生しやすい。過剰なデータ取得があると応答速 度に遅延が発生する場合がある。 前述の通りGraphQLでは、要求されたデータのみをレスポンスするため、原則 オーバフェッチが発生せず、REST APIに比べてレイテンシが低くなる傾向にある。
33. REST APIの課題 課題1：固有のエンドポイントが必要 -> 恩恵を受けられそう🎉 課題2：オーバーフェッチ(過剰取得)、アンダーフェッチ(過剰不足) -> 恩恵を受けられそう🎉 課題3：過剰なデータ取得によるレイテンシへの影響 -> 恩恵を受けられそう🎉
34. GraphQLのデメリット
35. https://kinsta.com/jp/blog/graphql-vs-rest/
36. PJ導入を考えた 下記の点でメリットを得られると考える - エンドポイントを減らせる - オーバフェッチ、アンダーフェッチを解消できる - ↑により、レイテンシを低くできる可能性がある 前述のデメリットを考慮し、PJチームで「解決したい課題」を考え決めることが最優 先。その解決手段がGraphQLであれば使ってみるのはアリかなぁと考えます。（そ りゃそうか..）
37. P.S. 検証して気づいた点 チーム間のコミュニケーション（フロントエンドとバックエンドで開発チームが分かれ ていた場合） REST APIの場合： フロントエンドチームとバックエンドチームとで、エンドポイントの使用について合意 を取る必要がある GraphQLの場合： クライアント側でQuery, Mutationを用いてリクエストするだけでOKなため、チーム 間のコミュニケーションは削減できそう
38. 参考資料 ・https://zenn.dev/igaiga/books/rails-practice-note/viewer/rails_graphql_wor kshop ・https://zenn.dev/yoshii0110/articles/f5ca51e023fc45 ・https://zenn.dev/nameless_sn/articles/graphql_tutorial
39. ご清聴ありがとうございました