[解決済み] ライブオーディオストリーミング用Webアプリのアーキテクチャ

質問

ライブオーディオストリーミングアプリのアーキテクチャについてご意見をお聞かせください。

現在、ローカルネットワーク上でテストしており、すべてがうまくいっているように見えますが、本番でどの程度うまくいくのか疑問があります。

私のアーキテクチャ

                         1               2 
Broadcaster HTTP client ---> App Server ---> Listening clients (React.js App)

1 - HTTPで通信する。 2 - HTTPとWebSocketによる通信

やりたいこと

1. ユーザーが私のReactアプリを開き、Broadcasterがまだストリーミングされていない場合、Reactは"OFFLINE"のようなものを表示する必要があります。
2. 次に、BroadcasterがApp Serverへのストリーミングを開始すると、React Appは"The stream is started"と表示し、自動的に再生を開始する必要があります。
3. 最後に、Broadcasterがストリーミングを停止すると、React Appは再び"OFFLINE"を表示する必要があります。

現在私が行っている方法 私のアプリサーバーは、2つのプロトコルを使用しています。HTTP（オーディオストリーミングなど）とWebSocket（サーバーで発生したことのJSONステータスメッセージを送信するためだけ）です。

1. The BroadcasterがApp Serverへのストリーミングを開始すると（HTTP経由）、App ServerはReact AppにWebSocketメッセージを送信します。 http://my-domain/stream つまり、アプリサーバは通常のHTTPでReactに音声をストリーミングしているのです。
2. Reactアプリはこのメッセージを見て、HTMLをレンダリングします。 <audio> 要素で指定され、音声の再生が開始されます。
3. Broadcasterがストリーミングを停止すると、App ServerはReact AppにWebSocketメッセージを送信し、quot;the stream is finished" Reactはプレーヤーを非表示にして、quot;OFFLINE"を表示する。

そこで、すべてのストリーミング（BroadcasterからApp Server、App ServerからReactクライアントの両方）をHTTPで行い、WebSocketを使ってストリームの状態更新をリアルタイムに通信しています。

このアーキテクチャはどのように良いのでしょうか？

解決方法は？

このアーキテクチャはどのように良いのでしょうか？

良い悪いの問題ではなく、ユースケースに適しているかどうかの問題です。 SHOUTcastやIcecastのようなインターネットラジオサーバーが20年以上にわたって機能してきた方法と基本的に同じですから、それほど悪いものではないはずです :-)