ブラウザpush通知にWebSocketやServer-sent_eventsを使うか否か
WebSocket、りろんはしってた
つい最近、Server-sent eventsというものを知った
どちらの技術も、あるブラウザ挙動を実装する際、まどろっこしい感じになるところをイケてる実装にできるようだ
その挙動というのは、サーバーサイドの処理が終わったらクライアントに表示しているページの更新...
要は処理が終わったらブラウザへpush通知みたいに結果を送りつけたいとき
この挙動を実装する場合、サーバーサイドで処理を投げておいて、クライアントサイドではajaxにてポーリング(一定時間毎にリクエスト)するのが一般的(???)っぽい
まぁこれしか思いつかなかったわけですが
それが、WebSocketやServer-sent_eventsを使うとどうやらイケてる感じになるらしい
見たand役立った
WebSocketについて調べてみた。 - Qiita
WebSocketに関して、うまく噛み砕いて説明してくれている
ただし、参考資料を読み飛ばすと辛いかも
こんな風にうまく説明できる人間になりたい...
The WebSocket API (WebSockets) | MDN
ブラウザ対応できるか見た
Server Sent Events(SSE)の使いどころと使い方 | GREE Engineers' Blog
Server-sent_eventsをWebSocketと対比して説明してくれている
Server-Sent Events の利用 | MDN
ブラウザ対応できるか見た
更新が滞ってますねぇ...
HTTPと比較
どちらもオーバーヘッド(無駄な通信・データ送信)が少なくなる
WebSocket
HTTPとは別プロトコル(これは良い面・悪い面あり)
laravel公式ドキュメントをちらとみると別ドライバ(Pusher or Redis + Socket.IO)が必要
Server-sent_events
ブラウザのjavascriptAPIが対応していない場合、Polyfillが必要
結論
ajaxポーリングがいいな
即時性や通信量削減が求められる場合は導入すべき
ただし、技術に(ajaxほどの)汎用性がないように見えるので、学習にかける時間や保守時のコスト高を考えると積極的採用は...うーん、といった印象
メモ
WebSocket、ごっちゃになってる声でかい人がいるけど
TCPのコネクションを作る際にHTTPが使われるだけで、HTTPと同一レイヤー完全別プロトコルだと認識している
HTTPのレスポンスが101だし
