はじめに
今回は PWA の文脈で必ず出てくる ServiceWorker について記事を書いていきます！
自分は普段はバックエンドの開発を主にやっているのですが、今後必須となっていくだろう PWA についても開発で触れる機会があったので、まとめていきます！
いまは簡単な感想で終わらせますが、ServiceWorker の開発をするにあたって、
「どうやって確認するの？」だったり、
「いまどういう状況で、なにをもってどう変化していくの？」といった感じで、少し毛色の違う開発だったなといった感じです。。。要するに
なんとなく理屈は分かったけど、めんどそうだな～～～。
めんどくさいと感じるのは、力のなさの証明だにゃん。
泣かしたろか。。。
といった具合でしたが、詳細に調べてくうちに、「そういうことか！」となったので、誰かの理解の一助になればなと思います！
また、本記事では具体的な実装方法は紹介しませんのでご了承ください。
※別記事で紹介いたします。
ServiceWorker ってなに？
さっそくですが、「ServiceWorkerとは」 といった記事は数多く存在しますが、よく以下のように説明されています。
ブラウザとは独立して動くプロキシサーバーのようなもの。
図で示すと↓
なんのこっちゃ～～～～～～
ブラウザとは独立して動いているんだな～とか、
サーバー側の処理で ServiceWorker を登録するんだな～
ってな感じで大丈夫！
実際にどういった活躍をするかを見れば、ServiceWorker の偉大さがわかるよ！
ServiceWorker のすごい機能！（２つ）
直観的に理解しやすく、代表的な機能 2つ を選抜しました。ほかにも ServiceWorker を用いてできること（ 例: background sync ）があるので、興味のある方はぜひ調べてみてください！
すばり、
- ネットワーク接続のないオフラインでのコンテンツ閲覧が可能！
- push通知！
1. オフライン時にコンテンツの閲覧が可能！
ブラウザの機能として、Cache API を使えば、リソース( ファイルや画像など )を
ブラウザのキャッシュストレージに保存でき、Windows の場合 Chrome だと大体↓ディレクトリに入っている。
C:\Users\${name}\AppData\Local\Google\Chrome\User Data\Default\Cache\Cache_Dataこの仕組みを使って、よく以下のようなキャッシュ戦略が使われます採用されます！
例
ブラウザから index.html へのリクエストがあった。(http://localhost/)
※index.html には画像ファイルがいくつもあるとする。
ServiceWorker を登録
ServiceWorker を登録したときに発火される installイベント で、
Cache API を使ってリソースをキャッシュストレージに格納する。
※キャッシュストレージにも容量制限があります。
（デフォルトの設定では数十メガバイトから数百メガバイトの範囲）
ここまでの流れは特別 ServiceWorker だから出来るといった話ではないにゃ。。。
すごいね、クロたん！その通り！
でも、ServiceWorker はこれから説明することができるからすごいんだよ！
ネットワークリクエストの横取り！！！
例の続き…
もう一度ブラウザがindex.html へリクエストをしたとする
ServiceWorker は fetchイベント で「ネットワークリクエストが走る前に、どこに対してリクエストしようとしているのか」を横取りする。
もし、「どこに対してリクエストしようとしているのか」の部分が、
さっきのキャッシュストレージの中にあれば、 ServiceWorker は
「いやいや、わざわざネットワークに出ていかんでもここにあるやんけ！」という具合で
ServiceWorker がレスポンスを返してくれる。
以上のような機能があるため、ネットワークがオフラインの時もコンテンツが表示できるということが実現できるよ！
※もちろん、キャッシュに含まれていないリソースへのリクエストはネットワークを介してサーバーからレスポンスをもらわないといけない。
オフラインでのコンテンツ表示も強みの一つですが、オフライン時でなくても結局はキャッシュからレスポンスが返ってくるので、2回目以降の表示速度も速くなりユーザービリティも向上します。
2. push通知
PC画面右下に出てくるあれですね。
この通知は巷では、「うっとおしい」や「なんの通知？」といった感じで拒否されがちです。
自分もトップページで急に「通知を許可しますか？」と聞かれたら、問答不要で拒否ですね。
しかし、ユーザーの興味関心のある通知の場合は、許可される割合が高くなるのではないでしょうか？
そして、それはユーザーのアクティブ時間が増えることにつながります。
push通知 なら別に ServiceWorker はどこで活躍するの？といった感じになります。そう、全然想像がつかない。自分もそうで以下のような感想を持っていました。
push通知 を送るくらいなら js でサクッとできるでしょう？
どこで活躍するかの結論からまずいうと、
ユーザーがページを開いていないときに通知を送ることが可能となります。1
つまり、クライアントからの操作( ページのリロードやボタンを押すなど )をトリガーとして通知を送るのではないということ！
むむむ。ちょっと慎重に理解していかないとついてけなくなりそうだにゃ。。。
push通知 を送る仕組みは、ブラウザ と ServiceWorker が互いに独立して動いているという、
ブラウザに内包されていない性質を持っているからこそ実現できる仕組みです。
詳細な手順は別記事にしようと思いますが、ざっくりいうと以下のような流れになっています。
ServiceWorker 登録時に pushイベント をセットする。
ユーザーに「通知許可ダイアログ」を表示して通知を許可してもらう。
pushサーバー(新しい登場人物) に購読処理をリクエストして、
push通知に必要な情報をもらう。
アプリケーションサーバー側(新しい登場人物)で、上で取得した情報を用いて、
push通知をするようpushサーバーにリクエスト。
pushサーバー は通知を送る。
Service Worker の pushイベント が発火してデスクトップ通知を送る。
といった流れです！
新しい登場人物が出てきて、多少混乱したかと思いますが、
「HTMLを置くサーバー」と「push通知を送るサーバー」が必要なんだな、といった理解ができていれば ok です！
まとめ
いかがでしたでしょうか？ServiceWorker の魅力伝わったでしょうか？
次回では、Service Worker の登録手順をソースコードベースで解説していくのと同時に、
開発には欠かせないデバック方法なども一緒に見ていきたいと思います！
またね～～～。次回が楽しみだにゃ～～。
- ※ブラウザは起動していることが前提ではありますが、たいがいのケースにおいてブラウザの閉じるボタンを押すだけでは起動終了にはならず、「タスクマネージャー」上にはブラウザのプロセスは存在します。タスクマネージャーなどで「プロセス終了」させるといった操作がとられない限り、起動しているといっても過言ではないです。
また、上記のような操作で起動が完全に終了していた場合でも、次回起動時に通知が表示されるので必ず通知は届けることができます。 ↩︎
コメント