WebSocketsの代わりにServer-Sent Eventsを使う

• リアルタイムWebアプリケーションを作るとき、普通はWebSocketを思い浮かべるが、SSEもシンプルな代替になり得る

• WebSocketの問題点: HTTPベースではないため、HTTPの恩恵を受けられない

→ 圧縮不可、HTTP/2マルチプレキシングのサポート不足、プロキシが対応しない、ハイジャックされる可能性がある

• Server-Sent Events(SSE)

→ サーバーがクライアントにLow-Latencyのプッシュイベントを送れる機能

→ HTML標準であり、すべてのブラウザが対応している(IEを除く)

→ WebSocketと違って、SSEはサーバーからクライアントへの一方向の流れ (双方向通信が必要なゲームには向かない)

→ HTTP上で動作し、別個のプロトコルは不要

[minhoryang]

Load BalancerやProxy環境では、SSEのサポートが不十分な場合が多いです。(+Enterprise Firewall)

CloudflareやAWS CLBなどの環境を考慮しているなら、SSEを導入する前にもう一度確認しておく必要があります。

[cometkim]

GraphQL Subscription のためのトランスポートとして、WebSocket の代わりに使われることもあります。

• GraphQL SSE ハンドラーの実装: https://github.com/enisdenjo/graphql-sse

• SSE を Subscription トランスポートとして活用する例: https://www.graphql-yoga.com/docs/features/subscriptions

[wan2land]

Deno DeployやLambdaのような特殊な環境でWebSocketを実装しにくいとき、代替手段になり得ます。 :-)

私も最近、Deno Deployでチャットのサンプルを見ていて、SSEを初めて知りました。

https://github.com/lucacasonato/deploy_chat

[nicewook]

こういうものがあるんですね。勉強になりました

[xguru]

この記事のコメントと HN のコメントもあわせて参照してください。

SSE を使っている人たちの意見や、WebSocket から移行した事例、SSE に移ったあとで再び WebSocket に戻った事例など、さまざまな意見がありますね。

https://news.ycombinator.com/item?id=30312897

実際、記事では SSE の利点が多く語られていますが、役に立つのは特殊なシナリオに限られます。

最近は WebSocket 側もライブラリが多く出ていて、実装がより簡単になってきていますしね。

• Web ソフトウェアの未来は HTML-over-WebSocket だ https://ja.news.hada.io/topic?id=3818

このような主張もあります。