小規模でGraphQLを使う良さ

KC3 2024登壇資料

Transcript

1. by lCyou ＠KC3 2024　9/9/2024 小規模でGraphQL を使う良さ
2. 自己紹介 山川 加織 所属：無所属 普段は認証系の研究や開発をしてます。 趣味：自作キーボード・コーヒーなど 最近ハマってること：ランニング
3. 筆者はGraphQLを触り始めて浅いです。 GraphQLのツールチェインにある機能にも言及しています。 筆者が思う良さを語ります。 （ポエム的なところが含まれます） 　何か間違い等あれば教えろください（っ'-')╮ =͟͟͞͞ 🔪ﾌﾞｫﾝ 注意事項
4. まずGraphQLって どんなの？
5. GraphQL は API のクエリ言語 Facebookが開発元 データに定義した型システムを使用するサーバー側ランタイム ランタイムを指して言われていることも聞く 特定のデータベースやストレージ エンジンに関連なし GraphQLって？
6. 特定のデータのみ取得 アンダーフェッチ・オーバーフ ェッチがない APIの破壊的変更が起きにくい クエリが複雑になることも 学習コストが高い HTTP キ ャ ッ シ ュ が で き な い （しにくい） 主な特徴 メリット デメリット
7. アンダーフェッチ RESTの場合 ① ② ③ ④ 各リソースごとにリクエストが 必要になってくる （RESTはリソース一つに対し てエンドポイントを生やす）
8. アンダーフェッチ GraphQLの場合 ① ① ① ① 関連するデータを必要な分だけ 持ってくることができる！ アンダーフェッチしない リクエスト回数が少ないと嬉しい モバイル回線の使用の際 単純にパフォーマンス
9. 主な特徴 client GraphQL server query JSON
10. 本編
11. 自分が触ってみて良かったと 思えたところ データ型がしっか りしている スキーマ駆動 単に POSTリクエスト
12. 前提 スキーマってやつ 1. クエリ・ミューテーション 2. でも読みやすい 3.
13. スキーマって？ どんなAPIがあるか書かれている GraphQL型システムを使用 SDLで記述される 今回の主役
14. クエリって？ REST APIでもあるアレ データの型や値等を指定して欲し い情報がレスポンスで帰ってくる ようにするもの 図のように引数をとったり，ディ レクティブなどで動的なクエリを 作成できる
15. ミューテーションって？ 前項クエリと大差はない RESTでデータを書き換えるとき メソッドを使い分けるように言い 換えてる ということで変異を起こすという 意味でmutationならしい
16. いいところ① データ型しっかりしてる
17. データ型がしっかりしている 前提でも言及したとおりSDLはデータ型を使用している スキーマはクライアントでもサーバーでも同一のものを使用 することでやり取りすることができる クライアントもサーバーも同じ型の知識を持ったファイルが 存在するのはかなりのメリット
18. データ型がしっかりしている スキーマの可読性 スキーマはAPIの定義を教えてくれる どう言ったデータをやりとりしているか がわかりやすい 特にクエリやミューテーションに「どこ のページからのリクエストなのか」や 「どう言った情報が欲しいのか」がわか るようにかける ロジックの集約
19. client server query JSON データ型がしっかりしている GraphQL GraphQL 実際は通信の前後で処理を挟んでいる
20. データ型がしっかりしている スキーマからある程度の型定義ファイルやクライアン トコードを生成できる（TypeScript） 型定義されているからできること 自分で書かなくてもいいのは工数的にもバグ回避 にも嬉しい 逆にコードからスキーマを生成することも可能 1人でも楽してコードが書けちゃう コードベースで変更に追随できているかは人力…
21. いいところ② スキーマ駆動
22. スキーマ駆動 こんな経験ありませんか
23. みんな技術スタックは？ 役割分担するか〜 スキーマ駆動 〜キックオフ時〜 じゃあフロント担当で！
24. あれ，APIってどうなってる んだっけ？ いや，まだっスね… スキーマ駆動 〜開発時〜 これ機能追加できない？ 好き放題言いやがって…
25. スキーマ駆動 スキーマ駆動開発 単一のインターフェイスを元にプロダクトを構成するサービスを開発す る手法 https://hitokuse.com/blog/?p=3135
26. スキーマ駆動 スキーマはコミュニケーションツールでもある チームで仕様書を元に開発を進めることができる 領域関係なく話ができて共通知識を持つことができる 実装がスムーズに 仕様が先に固まるので開発に入る時に楽 他の人（新しいメンバーやプレゼン相手）にも伝わりやすい
27. スキーマ駆動 （余談）実装が固まってからの変更 GraphQLの特徴としてAPIの変更への柔軟性 共通のスキーマを使う前提
28. いいところ③ 単にPOSTリクエスト
29. 単なるPOSTリクエスト まずはこれを叩いてみてください https://anilist.gitbook.io/anilist-apiv2-docs
30. 単なるPOSTリクエスト 左のようなレスポンスが返ってくる GraphQLは基本HTTPを使うときは POSTリクエストになる。 （queryタイプはGETでも可能だが mutationなどはPOSTである）
31. 単なるPOSTリクエスト 学習コストが高いなんてウソ （筆者は一切の責任を負いません） RESTとの違いは エンドポイントが一つ HTTPメソッドはPOST 処理分岐はリクエストボディ（クエリ）で変更
32. 単なるPOSTリクエスト 学習コストが高いなんてウソ （筆者は一切の責任を負いません） RESTとの違いは エンドポイントが一つ HTTPメソッドはPOST 処理分岐はリクエストボディ（クエリ）で変更
33. 最後に 1人でもチームでも快適にGraphQLをつかってみて！
34. THANK YOU 参考文献 https://graphql.org/ https://kinsta.com/jp/blog/graphql-vs-rest/ https://www.redhat.com/ja/topics/api/what-is-graphql https://zenn.dev/urotea/books/ece9493100b5be/viewer/8769d8