画像サーバとsocket.io

Question

私は私のアーキテクチャで、次の問題の解決策を探しています

：私は豊富なフロントエンドアプリケーションが持つ

（反応して、RxJS、socket.ioなど）とnetty-socketioの上に書かれたWebサービス層。Nettyアプリと同じように動作します。アイデアは、サーバーがsocket.ioプロトコルを実装するクライアントが消費する可能性のあるAPI層として機能し、フロントエンドアプリケーションがその1つであることです。私はどこでも本当に、おそらくCDNをホストすることができます。

私が遭遇した問題は、ファイル、より具体的には画像処理です。古典的なユースケースは、ユーザーのアバターをアップロードすることです。私の平野socket.ioプロトコルは、それをサポートしていないので、私は理論的なソリューションのカップルを作ってみた：サーバのファイルシステム上のsocket.io APIを介してバイナリとして

1. アップロード画像、店舗画像バイナリとしてもアクセスできます。この問題の私の問題は、私がしなければならないシリアライゼーション/デシリアライゼーションであり、異なるファイル拡張子などでエラーが発生するようです。

2. this exampleのようにNettyにHTTPパーサーを実装し、別のポートの同じインスタンスで実行します。私はこれを試して、それは動作しますが、それは本当に低レベルであり、私はNettyの専門家ではありません。

3. サーブレットを使用して別のHTTPファイルサーバーを作成し、それを使用してイメージを保存および参照し、フロントエンドに直接アップロードして、socket.io APIへの参照を送信してDBに保存します。私がよく分からないことは、APIが基本的にUIsが独自のイメージストレージを扱い、単に参照を報告することをAPIが期待しているということです。それは安全でなく制御不能なようです。

4. （3）で説明した動作の代わりにCDNを使用してください。これは素晴らしいプロダクション対応ソリューションですが、私の非プロダクションシステムでは過度の作業になるかもしれません。

注意、場合によっては（3）と（4）私は今、私はそのためのローカルNode.jsのHTTPサーバを使用しています、同じ場所でフロントエンドをホストする可能性があります。

私は考慮しなかったアドバイス、意見、解決策はありますか？

Answer 1

知識共有の目的で私は私の質問に答えます。私はアプリケーションの残りの部分からイメージ格納ロジックを分離したくないので、私はオプション2に行きました。イメージのアップロードは2段階のプロセスになりました。ユーザーは、イメージ本体を別のポートの同じIPにHTTP POSTリクエストを開始します。 Nettyハンドラはメッセージをキャッチし、参照されている例と同様にHTTP POSTを解析します。その後、イメージはバイトバッファとしてメモリに格納され（限られた時間）、HTTP応答に一意のUUIDが返されます。その後、関連するテキストデータをとに送信すると、アップロードされたデータへの参照として前述のUUIDが含まれます。ソケットハンドラはこの要求を検証し、一時ストアからのハッシュに基づいてバイトバッファを読み取り、ディスクに書き込みます。これに関する良い点は、一時バッファです。そのため、ディスクに書き込む前にリクエストを適切に検証することができます。