RESTからGraphQL APIへの移行で学んだこと

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

Transcript

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 2. 型定義を循環させる（再帰的に解決できるスキーマが存在する）と意図的にネストを深くしたクエリをリクエス トされDos攻撃されるリスクがある https://github.com/WebAppPentestGuidelines/graphQLGuideLine/blob/master/docs/specific/dos.md 3. viewerパターンを採用し、個人情報の不正取得を防ぐ current_userを起点に各情報を取ってくるようにする。 self.authorized?で対象オブジェクトがcurrent_userのものでなければ認可エラーを返す
10. 3. クライアントサイドとの調整 - 現状のUIと整合性のある形でmutationを定義しないと、自然な形でリク エストが送れない - ex. 親リソースと子リソースを同じ編集画面で操作する場合、子リソー スの削除mutationだけ分離すると、違和感のある動きになってしまうこと があった
11. その他、実装で難しかった点 ・ページネーションの書き方が独特 ・既存のAPI仕様を理解した上で、壊さないようにしないといけない ・graphiqlの扱いに最初慣れなかった ・RSpec（テスト）でテストデータを準備するやり方 ・例外処理 参照: ZOZO社の事例
12. 以上です！ありがとうございました！