Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
RESTからGraphQL APIへの移行で学んだこと
Search
inoway46
June 22, 2023
Technology
1
260
RESTからGraphQL APIへの移行で学んだこと
めぐろLT会#4にて発表しました。
https://meguro-lt.connpass.com/event/286892/presentation/
inoway46
June 22, 2023
Tweet
Share
More Decks by inoway46
See All by inoway46
フロントエンドでもテストを書きたいのでJestに入門してみた
inoway46
1
770
Other Decks in Technology
See All in Technology
Azure AI ことはじめ
tsubakimoto_s
0
130
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 / AI Test Lab vol.1
shift_evolve
0
190
Docker互換のセキュアなコンテナ実行環境「Podman」超入門
devops_vtj
6
3.2k
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
ソフトウェアエンジニアリングの知見を活かして データ基盤をいい感じにする on Snowflake [MIERUNE BBQ #10]
mtpooh
2
150
累計ダウンロード数1億8000万を超えるアプリケーションプラットフォームのレガシーシステム脱却とモダン化への道
kmitsuhashi
0
120
推薦システムを本番導入する上で一番優先すべきだったこと~NewsPicks記事推薦機能の改善事例を元に~
morinota
0
130
ギークの理想が7つ集まるエムスリーで夢を叶えよう - エムスリー株式会社
m3_engineering
1
260
AOAI Dev Day - Opening Session
yoshidashingo
2
470
Github Actions 로 Android 팀의 효율성 극대화
hadonghyun
0
160
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
kakehashi
10
3k
dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation
lmi
2
260
Featured
See All Featured
Designing for Performance
lara
604
67k
A better future with KSS
kneath
231
17k
Adopting Sorbet at Scale
ufuk
71
8.8k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.9k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.6k
Embracing the Ebb and Flow
colly
81
4.3k
Being A Developer After 40
akosma
72
580k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
Statistics for Hackers
jakevdp
792
220k
Agile that works and the tools we love
rasmusluckow
325
20k
The Art of Programming - Codeland 2020
erikaheidi
48
13k
Transcript
RESTからGraphQL API への移行で学んだこと @inoway46
自己紹介 ・GMOペパボにて主にRailsでECアプリの開発をしてます Twitter: @inoway46 ・Web広告の営業から1年半前にWebエンジニアになりました ・最近は英会話をがんばってます ・麻雀が特技です
技術スタック(簡易版) サーバーサイド ・Rails 7.0、Ruby 3.1、graphql-ruby クライアントサイド ・Web -> Next.js(一部はRailsのview) ・Android
・iOS
なぜGraphQLに移行したのか iOS、Android、Next.jsで使用するAPIを共通化し、開発 効率を高めたい
GraphQLの利点 ・オーバーフェッチ、アンダーフェッチを防げる ・1回のリクエストで必要なデータを取ってこれる ・リクエスト数が少なくなるので、アプリのパフォーマンスがよくなる GraphQLの開発秘話:https://youtu.be/783ccP__No8
GraphQLのキャッチアップ - はじめてのGraphQLを読む - zennのチュートリアルなどで書いてみる - 他社事例を学ぶ - メルカリ社、ZOZO社 -
既存コードを読む - graphiqlで既存のクエリを叩いてみる - 後は開発する中で理解していく https://www.oreilly.co.jp/books/9784873118932/
学びになったこと 1. 型の定義が重要 2. セキュリティの観点 3. クライアントサイドとの調整
1. 型の定義が重要 - 命名を間違えると後々面倒なことになる - もし間違えていたら、@deprecatedディレクティブを生やし た上で、新規追加する
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のものでなければ認可エラーを返す
3. クライアントサイドとの調整 - 現状のUIと整合性のある形でmutationを定義しないと、自然な形でリク エストが送れない - ex. 親リソースと子リソースを同じ編集画面で操作する場合、子リソー スの削除mutationだけ分離すると、違和感のある動きになってしまうこと があった
その他、実装で難しかった点 ・ページネーションの書き方が独特 ・既存のAPI仕様を理解した上で、壊さないようにしないといけない ・graphiqlの扱いに最初慣れなかった ・RSpec(テスト)でテストデータを準備するやり方 ・例外処理 参照: ZOZO社の事例
以上です!ありがとうございました!