SSEの方が簡単、では決められなかった。Cloudflare WorkersでWebSocketを選んだ理由

CRANK

リアルタイム更新を実装するとき、まずSSEを選びたくなります。サーバからクライアントへ通知するだけなら双方向通信は不要ですし、HTTPの延長で書けます。ブラウザ側もEventSourceを作るだけです。私も自分のプロジェクトをNestJSからHonoへ移したときは、この延長線でSSEを選びました。けれどCloudflare Workers上でしばらく運用してみると、「実装が簡単か」だけでは決められませんでした。最終的には、Durable ObjectsのWebSocket Hibernation APIへ移行しています。この記事ではWebSocketの実装方法ではなく、なぜSSEからWebSocketへ判断を変えたのかをまとめます。SSEから検討を始めたserverからclientへ一方向に通知するだけならSSE、という従来の判断から検討を始めました。先に結論通常のWorkerからSSEを返すだけなら、接続時間そのものにWorkersのDuration料金はかかりませんDurable Objectsを選んだのは、複数のWorker isolateに散る接続を、ユーザー単位で同じ場所へ集める必要があったためです問題になったのは、接続を束ねるDurable ObjectをSSEの間ずっと起こしておく構成ですWebSocketは実装項目が増えますが、Hibernation APIなら接続を維持したままDurable…