これまで対応ブラウザが少なかったものの、開発版も含めれば大半の主要ブラウザで対応が始まったServiceWorkerを利用したWeb Pushを当サイトでも実装してみました。

その時の様子を全3回でまとめます。
(1)概要
(2)主にclientの話
(3)主にserverでの話

数多のプラグインが存在するWordPressとはいえ、最新のWeb Push APIに対応したプラグインはまだ存在しない様子。
もちろん、外部サービスを用いるタイプのプラグインならいくつか存在するのですが、その場合には多少の弊害もあります。(ex. どのメールアドレスでアカウントをとるのか、誰が管理するのか、引継ぎが発生したらどうするのか、ものによっては有料サービスだし・・・) 

そもそも、まだまだ新しい道具ではあるので最低限は仕組みも把握したうえで使いたいもの。ちょうど何らかの更新通知機能が望まれていたタイミングでもあり、いい機会なのでWeb Pushについて学びつつ、WordPress内の投稿時のhookからWeb Pushの送信を呼び出すような実装を試してみました。

今回の実装は

  • DB内に専用テーブルの構築
  • wp-admin/ajax.phpの利用
  • 予約投稿へのアプローチ(wp-cronの取り扱い)

といった、扱いに注意が必要な部分が多い上に、Web Pushはドメイン単位でのものなためサブディレクトリ型のマルチサイトである当サイトとは相性がやや悪いといった要素もありなかなか大変でした。
が、苦労の甲斐あって全体の設計や動作は気に入っています。

主な参考資料はこちら。
FRESH! における Web プッシュ通知機能 〜実装編〜
[改訂版] Web Pushでブラウザにプッシュ通知を送ってみる
MDN web docs*日本語訳がやや古いようなので英語版とあわせて参照することを強くお勧めします。

まずは全体の方針として

  1. 通知許可要求はある程度ページを読んでくれた人に出す
  2. 急にブラウザの通知要求が出ると怖いからワンクッション置く
  3. 通知を受け取るカテゴリを選べるようにする
  4. ログインの必要ない通知サービスにする

といった方針で進めます。

一方、Web Push(with VAPID Key)の送信に必要なものは

  1. endpoint, auth, p256dh(許可してくれたユーザのブラウザごとに発生)
  2. VAPID Key Pair(server保管のものとclientのjs内にあるもの)
  3. payload(通知に出したいデータ)

となり、上記の 1 を何らかの形でブラウザから受け取り、保管しておく必要が出てきます。

そこで、endpointを…

ログインして続きを読む