Rabbitのキャッシュ・バッチ化の仕組み

English version: https://speakerdeck.com/syusui/caching-and-batching-in-rabbit-1

nostrクライアント Rabbit には、通信量やリクエスト数を削減するためにキャッシュとバッチ化という機能が備わっています。この資料ではその仕組みと実装の詳細について説明します。

オリジナル版はこちら。理解の助けとなるアニメーションも含まれています。
https://docs.google.com/presentation/d/1NnQ0ZW2SMF83r1HIsoxsXoPlDB5LWZ4wo9wAUDc-auk/edit?usp=sharing

Rabbitのキャッシュ・バッチ化の仕組み © 2023 by Syusui Moyatani is licensed under CC BY-SA 4.0. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/

Transcript

1. Rabbit🐰の キャッシュ・バッチ化のしくみ @syusui_s Rabbitのキャッシュ・バッチ化の仕組み © 2023 by Syusui Moyatani is licensed under CC BY-SA 4.0
2. 自己紹介 しゅうすい @syusui_s Webエンジニアです。 • Scrapbox書いてます（仕様や使い方） • Nostrクライアントを作っています 0:10 +30
3. 🐰Rabbit TweetDeck風クライアント https://syusui-s.github.io/rabbit/ • 軽快な動作 • マルチカラム • ショートカット 0:40 +20
4. 投稿の表示が大変 外部 サーバの 画像 プロフィール (kind0) リポスト数 (kind 6) リアクション数 (kind 7) 色々な関連情報が必要になる 1:00 +20
5. 毎回取得すると遅い 表示のたびに取得するのは遅くて通信量も多い • プロフィール等の表示が遅くなる • スマホの通信量を消費してしまう • サーバの制限に引っかかる ◦ 一部リレーは購読数を制限している 1:20 +20
6. 通信量・回数を減らす仕組みが欲しい Rabbitでは以下の手法を取り入れています • キャッシュ ◦ データを保存し、しばらくの間再利用する • バッチ化 ◦ 複数のイベントに対する購読をまとめて行う 1:40 +10
7. キャッシュ 1:50 +5
8. キャッシュ データを保存し、しばらく再利用する仕組みのこと • プロフィール ◦ あまり変更されないので、使いまわしても問題が少ない ◦ 保存すればアイコンと名前がすぐに見られる ※他にもキャッシュできるものはあるが時間の都合で割愛 フォロー一覧、リポスト数、リポストされた投稿など 1:55 +15
9. TanStack Query 通信向けのキャッシュライブラリ 特徴 • SWR戦略に基づく • SolidJSに対応 1:15 +15
10. 単純なキャッシュの仕組み 保存したデータはいつかは古くなり、再取得が必要 保存期間を決めておき、時間が経ったら破棄 有効 （データは新しいはず） 破棄 破棄までの期限 保存 1:30 +30 破棄すると、読み込みでユーザを待たせてしまう
11. SWR戦略 (stale-while-revalidate) 期限が切れてもすぐに削除せず一旦持ってるデータを表示 その裏で新しいデータを取得し、画面に表示する 有効 （データは新しいはず） 期限切れ （古いはずだが持っておく） 破棄 有効期限 破棄期限 保存 読み込みでユーザを待たせない 2:00 +30
12. 通信の流れ クライアント リレー キャッシュ機構 Aさんのプロフィールがほしい Aさんのプロフィールです Aさんのプロフィールがほしい Aさんのプロフィールです 一旦今あるAさんのデータを返します Aさんのプロフィールがほしい Aさんのは保存してたのがあるよ Aさんのプロフィールがほしい stale Aさんのプロフィールがほしい 新しいAさんのプロフィールです 有効 期限切れ Aさんのプロフィールです 3:00 +60
13. TanStack Queryを使う上での課題 Promise前提 nostr-toolsのコールバックスタイルから変換が必要 4:00 +10
14. イベントのPromise化 まずは単純に一件だけのキャッシュに対応 プロフィール1件、リポストされたイベント1件 など ※nostr-toolsを使っています 4:10 +20
15. 複数イベントの場合 更新があるたびにキャッシュを更新 割とゴリ押しな実装… 4:30 +30
16. バッチ化 5:00
17. 単純に購読すると クライアント リレー Bさんのプロフィールがほしい Cさんのプロフィールがほしい Aさんのプロフィールがほしい Dさんのプロフィールがほしい Eさんのプロフィールがほしい そんなにリクエストしないで！ (イベントEの取得失敗） 5:00 +10
18. 動機 一部のリレーは購読数の制限がある (おそらく負荷軽減のため) 制限回避のために 購読数を少なく保ちたい 5:10 +10
19. バッチ化 複数の購読(REQ)を一つの購読にまとめる仕組み kinds: [0] authors: ["8234…e6a2"] kinds: [0] authors: ["3bf0…459d"] kinds: [0] authors: [ "8234…e6a2", "3bf0…459d" ] プロフィールの問い合わせを統合する例 5:20 +20
20. バッチ化 クライアント リレー バッチ化機構 Aさんのプロフィールがほしい Bさんのプロフィールがほしい Cさんのプロフィールがほしい まとめてA,B,Cのプロフィールがほしい Aさんのプロフィールです 3秒 Aさんのプロフィールです Bさんのプロフィールです Cさんのプロフィールです 3つのリクエストを1つにまとめられた Bさんのプロフィールです Cさんのプロフィールです レスポンスの振り分け 5:40 +60
21. レスポンスの振り分け kind: 0 pubkey: "8234…e6a2" content: {"name":"jack"} kind: 0 pubkey: "3bf0…459d" content: {"name":"fiatjaf"} 公開鍵 resolver "8234…e6a2" () => { … } "3bf0…459d" () => { … } Promise Promise ※new Promise((resolve) => …) の resolve関数をMapに保存しておく 公開鍵等のIDに基づいてPromiseをfullfillする 6:40 +60
22. 詳しく知りたい人は https://gist.github.com/syusui-s/745a2b507744 073f9009c94222ad78fc 7:40 +10
23. 最後に キャッシュとバッチ化で効率よく通信できる 今後の展望 - 楽観的mutation - プロフィール変更、リポスト、リアクションを即座にキャッシュに反映する - タイムラインの情報を拾ってキャッシュに乗せておく - 投機的キャッシュ - 投稿を投機的にキャッシュに乗せて、リポスト等の表示を効率化する - InfiniteQueryによるタイムライン自体のキャッシュ - いつかこの辺に対応したクライアントライブラリを作りたい…
24. おまけ: 発表で話せなかったところ
25. プロフィールのキャッシュ時間の工夫 staleTime: 5分 名前やアイコンがすこし 古くてもあまり問題ない cacheTime: 1日 よくTLに居る人を キャッシュするように 3:00 +30
26. プロフィールのキャッシュ時間の工夫 staleTime: 4時間 投稿は編集できないので 期限切れにしなくてOK cacheTime: 4時間 時間が経ったらリポストは されないので4時間程度で ▪▪さんがリポスト ••さんがリポスト