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
GraphQLにおけるクライアントキャッシュ戦略
Search
KazukiHayase
March 16, 2023
Technology
0
2.9k
GraphQLにおけるクライアントキャッシュ戦略
KazukiHayase
March 16, 2023
Tweet
Share
More Decks by KazukiHayase
See All by KazukiHayase
もし今からGraphQLを採用するなら
kazukihayase
10
4.7k
Goでテストをしやすくするためにやったこと
kazukihayase
1
770
GraphQLクライアントの技術選定 2023冬
kazukihayase
9
6.5k
Introduction and Insights of the Hasura-based Architecture
kazukihayase
0
870
自分だけが頑張るのをやめて、フルスタックなチームを作る
kazukihayase
2
2.8k
Goでテンプレートからファイルを自動生成するCLIを作る
kazukihayase
0
1.2k
生産性が上がり続けるチームを作るための第一歩
kazukihayase
4
3.7k
MUIをベースにしたデザインシステムの構築
kazukihayase
0
520
Hasuraを活用するためのTips集
kazukihayase
0
33k
Other Decks in Technology
See All in Technology
Goで作って学ぶWebSocket
ryuichi1208
0
160
データマネジメントのトレードオフに立ち向かう
ikkimiyazaki
6
960
エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 / product discovery accelerated by engineers
rince
4
320
偶然 × 行動で人生の可能性を広げよう / Serendipity × Action: Discover Your Possibilities
ar_tama
1
1.1k
Platform Engineeringは自由のめまい
nwiizo
4
2.1k
開発スピードは上がっている…品質はどうする? スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality
nihonbuson
2
2.9k
地方拠点で エンジニアリングマネージャーってできるの? 〜地方という制約を楽しむオーナーシップとコミュニティ作り〜
1coin
1
230
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
8
1.5k
スタートアップ1人目QAエンジニアが QAチームを立ち上げ、“個”からチーム、 そして“組織”に成長するまで / How to set up QA team at reiwatravel
mii3king
2
1.5k
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
2
380
Building Products in the LLM Era
ymatsuwitter
10
5.4k
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Statistics for Hackers
jakevdp
797
220k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
Gamification - CAS2011
davidbonilla
80
5.1k
Bash Introduction
62gerente
611
210k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
The Cult of Friendly URLs
andyhume
78
6.2k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
9
440
Transcript
GraphQLにおけるクライアントキャッシュ戦略 2023.03.15リクルート × BASE × バイセル 【第1回フロントエンド勉強会】React & GraphQL 2023.03.15
自己紹介 名前:早瀬和輝 出身:愛知県名古屋市 経歴:BuySell Technologiesに2021年に新卒入社 趣味:開発、マンガ、アニメ、ベース、バスケ Twitter:@KazukiHayase
はじめに • 今回話すのはクライアント側のキャッシュについて • CDNなどのキャッシュについては触れないです
アジェンダ キャッシュの仕組み 01 キャッシュにおける課題 02 課題解決へのアプローチ 03 まとめ 04
アジェンダ キャッシュの仕組み 01 キャッシュにおける課題 02 課題解決へのアプローチ 03 まとめ 04
キャッシュの仕組み • いくつかのGraphQL Clientにはキャッシュ機構が備わっている ◦ Apollo Client, Relay, urql •
キャッシュを活用することで無駄なリクエストが減る • そのためにはキャッシュ機構の正しい理解が必要
キャッシュ機構において重要な要素 データの正規化 01 キャッシュの 利用条件 02
データの正規化 • レスポンスデータは正規化されてキャッシュに保存される • 正規化することで ◦ キャッシュへのアクセスが早くなる ◦ データサイズを小さくすることができる
正規化の流れ 1. Queryの結果を個別のオブジェクトに分割 2. 分割したオブジェクトに一意な識別子を割り当て 3. フラットなデータ構造に格納
正規化の流れの例 右図のような SchemaとQueryを考える ※ Apollo Clientを例に解説しますが、 他のClientでも大枠の流れは同じです
正規化の流れの例 Queryの実行結果として 右図のようなレスポンスを受け取る
正規化の流れの例 1. Queryの結果を個別の オブジェクトに分割 2. 分割したオブジェクトに一意 な識別子を割り当て 3. フラットなデータ構造に格納
正規化の流れの例 1. Queryの結果を個別の オブジェクトに分割 2. 分割したオブジェクトに一意 な識別子を割り当て 3. フラットなデータ構造に格納 Task:1
Task:2 Task:3
正規化の流れの例 1. Queryの結果を個別の オブジェクトに分割 2. 分割したオブジェクトに一意 な識別子を割り当て 3. フラットなデータ構造に格納
キャッシュの利用条件 • データが全てキャッシュにある場合はキャッシュを利用 • 一部でもデータがキャッシュにない場合はリクエストを実行
キャッシュの利用条件 • FetchTasks→FetchTasks2 ◦ キャッシュが利用できない ◦ リクエストは2回 • FetchTasks2→FetchTasks ◦
キャッシュが利用できる ◦ リクエストは1回
アジェンダ キャッシュの仕組み 01 キャッシュにおける課題 02 課題解決へのアプローチ 03 まとめ 04
キャッシュにおける課題 一部でもデータがキャッシュにない場合はリクエストが実行される Queryの定義によっては全くキャッシュが利用されない
キャッシュにおける課題 逆に常にキャッシュが利用されるようにしようとすると 考慮するべきことが多い
キャッシュにおける課題 仮に常にキャッシュが利用されるようにしようとすると • Queryの実行順序を工夫する • オブジェクト単位でQueryをまとめる • アプリケーション全体でQueryを使い回す
できなくはないが、、
個人的にはデメリットの方が大きいと判断
キャッシュにおける課題 • Queryの実行順序を工夫する ◦ →実行順序まで考慮するのは現実的ではない • オブジェクト単位でQueryをまとめる ◦ →オーバーフェッチにつながる、RESTとほぼ変わらない •
アプリケーション全体でQueryを使い回す ◦ →Query変更時の影響範囲が広い
アジェンダ キャッシュの仕組み 01 キャッシュにおける課題 02 課題解決へのアプローチ 03 まとめ 04
課題解決へのアプローチ ページ単位での キャッシュ最適 化 01 データを 3種類に分類 02
ページ単位でのキャッシュ最適化 • ページ単位でキャッシュ最適化を考える • アプリケーション全体でのキャッシュの利用は考慮しない ◦ Queryによってはキャッシュが利用される場合もある
ページ単位でのキャッシュ最適化 ページを跨いだキャッシュの利用を考慮しないことで • ページで使用するデータを宣言的に定義できる ◦ GraphQLの良さを最大限活かす • ページ同士が疎結合になる ◦ Queryの変更の影響範囲が閉じる
データを3種類に分類 データを3種類に分類して、分類ごとにQueryを定義 することでキャッシュを利用しやすくする
データを3種類に分類 コンテンツデータ マスタデータ 汎用マスタデータ 01 02 03
コンテンツデータ • コンテンツ表示用のデータ • アクションに応じてQueryを定義する ◦ e.g. 初回表示、検索、モーダル ◦ 1ページに複数のQueryが定義されていることもある
• 同じアクションであればキャッシュが利用される
マスタデータ • マスタデータやメタデータなどのシステム的に必要なデータ • 最初のレンダリング時のみリクエストが必要 • 2回目以降はキャッシュを利用する
汎用マスタデータ • 基本的には使用しない ◦ コンテンツデータ・マスタデータのみの運用をまずは考える • アプリケーション全体で利用するかつサイズの大きいデータ • どうしてもアプリケーション全体でキャッシュしたい際に使用 •
オーバーフェッチを許容
データ分類フロー ユーザーのアクションによって取得データが変わるか? コンテンツデータ マスタデータ 汎用マスタデータ Yes ページごとで重複して取得する事に パフォーマンス上の懸念があるか? No Yes
No
全体像 PageComponentA PageComponentA ContentQuery PageComponentA MasterQuery GeneralMasterQuery PageComponentB PageComponentB ContentQuery
PageComponentB MasterQuery ページコンポーネントごとに コンテンツ・マスタデータのQueryを定義 汎用マスタデータのQueryは コンポーネントの外で定義
データ分類の例 タスク検索画面
コンテンツデータ • タスクの検索結果のデータ • 検索の度に表示内容が変わる • 同じ検索条件ならキャッシュ を利用
マスタデータ • 検索で利用する選択肢データ • 検索結果に関係なくデータは 同じ • 初回以降はキャッシュを利用
汎用マスタデータ • 検索で利用する選択肢データ • 数千規模のデータかつ 他の画面でも使うと仮定 • この画面のみの利用であれば マスタデータに含める
アジェンダ キャッシュの仕組み 01 キャッシュにおける課題 02 課題解決へのアプローチ 03 まとめ 04
まとめ • キャッシュの仕組みを踏まえた上での戦略 ◦ ページ単位でのキャッシュ最適化 ◦ データを3種類に分類 • GraphQLの良さを生かしつつ、キャッシュも活用できる •
ただし懸念はある ◦ 汎用データが増えすぎると今回紹介した課題が再度浮上する
THANK YOU