ChromeでPushを実装してみた反省会場はこちらです
ChromeでPushが実装できるというのが広まってからしばらく経ちますが、
僕が開発に関わっているサービスでもプッシュを使いたいという温度感（特にビジネスサイドの）が高まってきたので、とうとう実装してしまいました（リリース済みです）。
どう実装するかなんて記事はありふれてるので、実際に開発してみての経験からの反省点を幾つか後世に残しておきたいと思います。
※注意: 技術的なことは特に書かいてません
反省1 - GCM -> FCMの流れを汲めなかった
いざ実装開始
↓
ん？
chrome appの場合はfirebase使ったほうがお得。なるほど
Firebase Cloud Messaging provides messaging services for Chrome in two ways:
Websites in Chrome can implement push messaging through service workers and web app manifests following the Webpush standard. Chrome apps and extensions can access the FCM service directly through chrome.gcm API.
あ、でもまだブラウザ（Chrome apps と extensions以外）はGCM(Google Cloud Messaging)なのね、じゃあGCMでいこう...
この判断自体は間違っていなかった（現行仕様でできることをやるという意味では）と思う。
だがしかし、公式でFCMへの流れがある中でもうすこし立ち止まって考えることはできたかなと反省。（特に実装途中で仕様の更新があってまた「あ」って思うことが増えるがそれは反省２にて）
反省2 - 時期尚早だった。Chrome 52以降で使うべきだった
上で判断したような当時の一般的仕様で実装していたら、52からVAPIDなど標準化作業※の流れがあるというupdateが...
※標準化についてはこちらにわかりやすい説明が → GCMの登録が不要になったChromeのWeb Pushを試してみる
「配信設計がすでに終わっててリリースも近い、現行バージョンも49(当時)だしリリースまでに間に合わないから、あとから設計できるように変更しよう...！」（現状の仕様でもpushとfetchを駆使して登録者が増えるごとにサーバーリソースが圧迫されてつらたん）
結果未来への悩みが増えた
(ホントは１年待ってリリースしたかったな)
ただ、他の大手webサイト（某SNSのFとか）を見てみると流石にまだメッセージをpayloadに載せた未来対応はしていなかったから、今の最善ではあるのかなという結論に至った。
反省3 - WebPushの仕様に沿った実装から若干はずれた
本来は push - message は１対１の関係（あたりまえだけど）でなくてはならない
表示制限とかあったり、その他諸々なメソッドが絡まり 1pushに多message配信にしてしまった
なにがだめだったのか
- 調査不足 - pushの仕様でコレはできるだろうと思っていたことができなかった (通知を出さないpushイベントとか)
- ギリギリまで調べていて新しい発見が多かった
- デバッグ方法がChromeDevTools内で完結していた - pushをデバッグするときはgcmから都度送るべきだった
後から思うと調査不足というよりも、調査結果の検証が足りていなかったかなと思った。
特にまだ技術的にも新しいせいで仕様がどこかにきっちりと書いていない分、実際に動かしてみて検証を繰り返したりする（それなりのコストを割いてやる）必要があったのかなと反省。
（結果トライアンドエラーには変わりないが、早く見えていない仕様にたどり着くという意味でも）
その他反省
いろいろあったけど
いろいろ書きましたが、反省はしつつ後悔はしてない。
あまり前例がない手探りな中でそれなりにベターな開発はできたのかなと思う。
あとそれなりにServiceWorker開発とPush開発のノウハウが蓄積できたので、後にでてくるサービスが開発しやすいようにこれまたブログかgithubに公開しようかなと。
これから
VAPID対応等、Push仕様の標準化に向けてタイミングを見計らいつつブラッシュアップしていきます。というよりせっかくServiceWorker使ってるからCacheAPIとかもろもろ使ってサービス改善していきたいな。
