めぐろLT会#4にて発表させていただきました。 https://meguro-lt.connpass.com/event/286892/

1. RESTからGraphQL API
への移行で学んだこと
@inoway46

2. 自己紹介
・GMOペパボにて主にRailsでECアプリの開発をしてます Twitter: @inoway46
・Web広告の営業から1年半前にWebエンジニアになりました
・最近は英会話をがんばってます
・麻雀が特技です

3. 技術スタック（簡易版）
サーバーサイド
・Rails 7.0、Ruby 3.1、graphql-ruby
クライアントサイド
・Web -> Next.js（一部はRailsのview）
・Android
・iOS

4. なぜGraphQLに移行したのか
iOS、Android、Next.jsで使用するAPIを共通化し、
開発効率を高めたい

5. GraphQLの利点
・オーバーフェッチ、アンダーフェッチを防げる
・1回のリクエストで必要なデータを取ってこれる
・リクエスト数が少なくなるので、アプリのパフォーマンスがよくなる
GraphQLの開発秘話：https://youtu.be/783ccP__No8

6. GraphQLのキャッチアップ
- はじめてのGraphQLを読む
- zennのチュートリアルなどで書いてみる
- 他社事例を学ぶ
- メルカリ社、ZOZO社
- 既存コードを読む
- graphiqlで既存のクエリを叩いてみる
- 後は開発する中で理解していく
https://www.oreilly.co.jp/books/9784873118932/

7. 学びになったこと
1. 型の定義が重要
2. セキュリティの観点
3. クライアントサイドとの調整

8. 1. 型の定義が重要
- 命名を間違えると後々面倒なことになる
- もし間違えていたら、@deprecatedディレクティブを
生やした上で、新規追加する

9. 2. セキュリティの観点
1. 直接型を参照されてしまわないように、self.authorized?を設定する
https://graphql-ruby.org/authorization/authorization
1. 型定義を循環させる（再帰的に解決できるスキーマが存在する）と意図的にネストを深くしたクエリ
をリクエストされDos攻撃されるリスクがある
https://github.com/WebAppPentestGuidelines/graphQLGuideLine/blob/master/docs/specific/dos.md
1. viewerパターンを採用し、個人情報の不正取得を防ぐ
current_userを起点に各情報を取ってくるようにする。
self.authorized?で対象オブジェクトがcurrent_userのものでなければ認可エラーを返す

10. 3. クライアントサイドとの調整
- 現状のUIと整合性のある形でmutationを定義しないと、自然な形で
リクエストが送れない
- ex. 親リソースと子リソースを同じ編集画面で操作する場合、子
リソースの削除mutationだけ分離すると、違和感のある動きになっ
てしまうことがあった

11. その他、実装で難しかった点
・ページネーションの書き方が独特
・既存のAPI仕様を理解した上で、壊さないようにしないといけない
・graphiqlの扱いに最初慣れなかった
・RSpec（テスト）でテストデータを準備するやり方
・例外処理
参照: ZOZO社の事例

12. 以上です！ありがとうございました！