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
270
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
860
Other Decks in Technology
See All in Technology
JPOUG_10_20241018_OracleDB_AWS_v1.3.pdf
asahihidehiko
1
190
v-modelの歩みを振り返る
bengo4com
5
2.4k
ラブグラフ紹介資料 〜プロダクト解体新書〜 / Lovegraph Product Deck
lovegraph
0
14k
テストを楽に書きたい
tomorrowkey
2
270
Amazon Managed Grafana で AWS IoT TwinMaker によるデジタルツインアプリケーションを動かしてみた
wakatsuki
0
120
地域DXにおけるGrafana活用事例
wacky
0
390
AWS Step Functionsのタスク入出力に秩序を与えよう
y_kotani
0
110
Transforming Event Attendees into Lifelong Donors: Insights from Claire Axelrad
auctria
PRO
1
130
外部カンファレンスで登壇しよう! 〜「強い」エンジニアへの一歩を踏み出す〜
logica0419
4
140
とある事業会社にとっての Kaggler の魅力
hakubishin3
7
1.6k
Microsoft 365 でデータセキュリティを強化しよう
sophiakunii
2
480
人工衛星開発のための C2A フレームワークとその開発体験
sksat
0
110
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
13
1.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
130k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
106
48k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
We Have a Design System, Now What?
morganepeng
50
7.2k
A designer walks into a library…
pauljervisheath
202
24k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
How to Think Like a Performance Engineer
csswizardry
18
1k
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社の事例
以上です!ありがとうございました!