【ITニュース解説】WebSockets are Overkill: Build Real-Time Dashboards with Server-Sent Events (SSE) 🚀

システムエンジニアを目指す初心者の皆さん、ウェブサイトやアプリケーションがリアルタイムで情報を更新する仕組みについて疑問に思ったことはないだろうか。例えば、株価が刻々と変動したり、スポーツの試合結果がリアルタイムで表示されたりする裏側には、サーバーとクライアント（あなたのブラウザなど）が常に通信し合う特別な技術が使われている。このような「リアルタイム通信」を実現するための代表的な技術として、「WebSockets（ウェブソケット）」がよく知られている。多くの開発者はリアルタイム機能が必要だと聞くと、まずWebSocketsを思い浮かべる傾向がある。

しかし、今回のニュース記事が伝えたい重要なメッセージは、WebSocketsが常に最善の選択肢とは限らない、ということだ。WebSocketsは確かに強力な技術だが、用途によっては「Server-Sent Events（SSE：サーバー送信イベント）」という別の技術の方が、よりシンプルで効率的な場合があるのだ。

WebSocketsは、クライアントとサーバーが双方向に、つまりお互いに自由にデータを送り合う必要がある場面で非常に優れている。例えば、チャットアプリケーションでは、あなたがメッセージを送るとサーバーに届き、サーバーからの他のユーザーのメッセージをあなたが受け取る。オンラインのマルチプレイヤーゲームでも、プレイヤーの操作情報がサーバーに送られ、サーバーからゲームの状態が全プレイヤーに送り返されるといった、活発な双方向のやり取りが常に発生する。このような状況では、WebSocketsがまさに理想的なソリューションとなる。

一方で、SSEが真価を発揮するのは、サーバーからクライアントへ一方的にデータを送り続ける必要がある場面だ。今回の記事では、ライブでシステムの状態を表示するダッシュボード、株価のリアルタイム表示、ニュースフィードのように、サーバーが常に最新情報を生成し、それをクライアントに「プッシュ」し続けるようなケースが例として挙げられている。これらの用途では、クライアントがサーバーに何かを積極的に送り返す必要はほとんどない。ひたすらサーバーからの情報を受け取りたいだけなのだ。このような「単方向のデータストリーム」においては、SSEがWebSocketsよりも優れた選択肢となる。

なぜSSEが単方向のデータストリームで優れているのだろうか。いくつかの大きな理由がある。まず一つ目は、「ネイティブHTTPで動作する」という点だ。WebSocketsはHTTPとは異なる独自のプロトコルを使用するため、時にファイアウォールやプロキシサーバーの設定が複雑になることがある。しかしSSEは、私たちが普段ウェブサイトを見るときに使っている標準のHTTPやHTTPSという通信方式の上でそのまま動作する。これにより、特別な設定や複雑なネットワーク構成が不要で、既存のウェブインフラと非常に相性が良い。

二つ目は、「自動再接続機能」が標準で備わっていることだ。インターネットの接続は不安定になることもあり、一時的にサーバーとの接続が切れてしまう可能性は常にある。WebSocketsの場合、接続が切れたら開発者が自分で再接続のロジックを実装する必要があることが多い。しかしSSEでは、ブラウザのネイティブなAPI（Application Programming Interface）が、もし接続が途切れても自動的に再接続を試みてくれる。これは開発者にとって非常に大きなメリットであり、安定したリアルタイム通信を簡単に実現できる。

三つ目は、「リソース効率が良い」という点だ。SSEは、サーバーとクライアント間で単一の、途切れないHTTP接続を長時間維持する。これは、大量のクライアントに対してサーバーから一方的にデータを配信する場合に、サーバー側のリソース（CPUやメモリなど）の消費を抑えるのに役立つ。WebSocketsと比較して、プロトコルのオーバーヘッドが少ないため、より軽量に動作する傾向がある。

今回の記事では、このSSEを使った具体的な実装例が紹介されている。バックエンド、つまりサーバー側は、Node.jsというJavaScriptの実行環境と、Expressというウェブフレームワークを使って構築されている。サーバーがSSEを提供するために最も重要なのは、クライアントに送るデータの形式を「text/event-stream」という特別なMIMEタイプ（データの種類を示す情報）として指定することだ。これによって、ブラウザはこれがSSEのストリームであることを認識する。

コード例を見ると、Expressサーバーが/eventsというURLへのリクエストに対して、以下の特別なHTTPヘッダーを設定していることがわかる。

• Content-Type: text/event-stream: これがSSEであることをブラウザに伝える最も重要なヘッダーだ。
• Cache-Control: no-cache: クライアントがこのレスポンスをキャッシュしないように指示する。リアルタイムデータは常に最新であるべきだからだ。
• Connection: keep-alive: 接続を長時間維持するようブラウザに伝える。

これらのヘッダーを設定した後、サーバーはsetIntervalという関数を使って、例えば3秒ごとに新しいデータを生成し、それをクライアントに送り続けている。送るデータはJavaScriptのオブジェクトをJSON形式に変換したものだが、SSEのルールとして、各データはdata: というプレフィックスの後に続き、そして必ず「2つの改行」で区切る必要がある。このdata: ...\n\nという形式が非常に重要だ。また、クライアントがブラウザを閉じたりして接続が切れた場合には、サーバー側でreq.on('close', ...)という処理を使って、データを送り続けるためのタイマー（setInterval）を停止し、不要なリソース消費を防ぐ仕組みも含まれている。

一方、フロントエンド、つまりクライアント側の実装は非常にシンプルだ。ブラウザに標準で備わっているEventSourceというAPIを使うだけで、外部のライブラリは一切不要だ。 まず、const eventSource = new EventSource('http://localhost:3000/events');のように、サーバーのSSEエンドポイント（今回の場合は/events）を指定してEventSourceオブジェクトを生成する。これでサーバーとの接続が確立される。 次に、eventSource.onmessageというイベントハンドラを設定する。サーバーから新しいデータが送られてくると、このonmessage関数が呼び出される。送られてきたデータはevent.dataプロパティに含まれており、これをJSON.parse()でJavaScriptのオブジェクトに戻すことで、サーバーから送られたメッセージやCPU負荷などの情報にアクセスできる。そして、これらの情報を使ってウェブページの表示を動的に更新する処理をここに記述していくことになる。 また、eventSource.onerrorというイベントハンドラも設定できる。これは接続エラーが発生した場合に呼び出されるが、前述の通り、SSEはブラウザが自動で再接続を試みるため、ここでの主な役割はエラーのログ記録などが考えられる。

結論として、WebSocketsがリアルタイムの双方向通信において非常に強力なツールであることは間違いない。しかし、サーバーからクライアントへ一方的にデータを配信する多くのリアルタイムアプリケーションでは、Server-Sent Events（SSE）がよりシンプルで、効率的で、実装も容易な優れた選択肢となる。システムエンジニアを目指す上では、このように特定の要件に対して最適な技術を選択できる知識と判断力が非常に重要だ。リアルタイム通信の要件を正確に理解し、WebSocketsとSSEのそれぞれの特性を把握して、適切なツールを使いこなすことが、これからの開発において成功への鍵となるだろう。