ScrapBubbleのcache戦略
level 1 一定時間cacheを維持
その後一定時間が過ぎるまではcacheを返す
ネットワークエラーもcacheする
一定時間後にリソース要求があったらfetchし直す
external linksのprojectなどもまとめて確認する
2. 更新日時が前回確認した時と同じなら、そのprojectのページはcacheから読み込む
4. 更新されたページのうち、cacheにあるページのみfetchする
2-4で、更新に乏しいprojectのページデータを何度も取得せずに済むようになる
cacheに無いページはfetch一択しかない
level2 簡易リアルタイム更新
初回は普通にfetchする
更新があれば一定時間後にフラグをたてて、次回のリソース要求時にfetchし直す
更新がなければ、一定時間経過してもcacheを更新しない
level3 完全リアルタイム更新
裏でstreamの更新を常時うけとり、Cache (DOM)に格納している各pageのresponseを更新する web workerで処理する
この更新を元に、以下の描画をリアルタイムで更新する
dom更新が重くならないよう、描画は適当に間引く
流石にやり過ぎか
0.9.2でどの戦略を使っているか忘れた
別案
描画までに読み込みが間に合えばそれを使う
その後fetchが終わり次第再描画する
有効期限を用意しない
projectの更新日時に反映されない可能性があるため
稀にしか起こらないだろうから考慮しなくていい
scrapbox本体も、リンクを踏むたびにnetwork-firstでfetchしているし、大した負荷ではないだろう
実装が大変
scrapbox.ioへの負担が増える可能性がある
常時接続なため、REST APIより負担が重いはず