PortalExtのアーキテクチャ
https://scrapbox.io/files/652fd64878fbe9001c5121db.png
1. ユーザーがPortalExtのページにアクセス。
2. ページは、Chrome Extensionを利用したAPIに対しアクセスを行う。
APIをどのように実装できるかが重要かもしれないt6o_o6t.icon
3. APIは、ポータルのページをfetchしてDOMを生成。
4. APIは、ページに適切なレスポンスを返却。
5. ページは、APIのレスポンスを利用して画面を描画する。
APIの要件
この参照はローカルで行われてほしい
Chrome Extensionを使う
ページとはローカルに通信を行う
これは、
localhost → Chrome Extensionは可能？
localhostにサーバーを立てて
フロントエンドをどのように実装するのかで変わると思います.
Next.jsの場合
localhostからアクセスしたい
Next.jsを選択するということは、サーバーを立てるということ
Next.jsを選択するのは辞める
APIを置かなくてもよいのではないか
https://scrapbox.io/files/652fd9e7af0e45001bcfe43a.png
PortalExtPageは、localhostでなくても良い
ほとんど空ページで良い
ページの内容は、すべてContent Scriptsとして動的に注入する（★）
Content Scriptsは、Portalへのfetchも、描画もすべて実施する
PortalExtPageからは、Messaging APIでPortalExtのBackground Pageにアクセスしたい
複数の方法が考えられる
Service Workerでfetchする
方法
Service Workerがポータルをfetchし、storageに保存
Content Scriptsはbrowser.storageから読み書き
メリット
Background Scriptでfetchする
fetchにはCookieが必要のため、Content Scriptsでは機能が不足
方法
Content ScriptsはBackground ScriptsにMessaging APIでリクエスト
background Scriptsはポータルをfetch
Content ScriptsはonMessageで受け取って、描画
問題点
Messagingを介すため、fetch処理が複雑化
fetchを読み込みごとに行いたい場合は、この方法が適切
各掲示の内容読み込みなど
Service Workerならもっと上手くできそう？
Service WorkerとBackground Scriptsを共用するキャッシュ戦略
Service Worker
バックグラウンドでサイトの更新を検知する
新規掲示
掲示の更新
メンテナンスの検知
新規課題の検知
検知した更新情報は、通知などに使える
更新された内容がstorageにキャッシュされる
Background Scripts
オンデマンドにサイトのキャッシュを更新する
掲示の内容
PortalExtPageで特定のリソースを参照する毎にキャッシュを実行するということ
ユーザーの読み込み時にはキャッシュしてもほとんど損がないから
Service Worker
戦略
1時間に1回実行
storageのキャッシュと比較
同じIDの掲示がなかった場合
fetchした内容をキャッシュに追加
同じIDで更新日時に変化があった場合
fetchし、キャッシュを更新
storageのキャッシュと比較
同じコードの授業がなかった場合
fetchした内容をキャッシュに追加
同じコードで、
4時間に1回実行
1. 各授業のページにリクエスト
内容をstorageのキャッシュに保存
最悪ケースで26回リクエストを送信することになる
5分に1回、130分かけてキャッシュを更新したい
現在どこまでキャッシュしたかをメモする必要がある
1. キャッシュ対象の配列をstorageに保存
2. alarmハンドラ
配列から要素をpop
popした要素の授業をキャッシュ
storageにpop済配列を保存
Storageを使うことで、Offline対応ができるのではないか？
ポータルがメンテナンス時でも、キャッシュを参照できる