あるレベルでは、私はこの投稿と非常によく似たことをしています: how to serve dynamic content in playframework 2
つまり、クライアントがさまざまなパラメーターを指定できる Web アプリがあり、Play! サーバーは、カスタム イメージ ファイルを生成するプロセスを開始します。このファイルは、できれば Play によって、そのクライアントに返される必要があります。
予想されるイメージの寿命は、数秒から数分 (場合によっては数時間) です。その観点から、応答で画像データを直接送り返すことは実行可能なアプローチではないと信じる理由があります...代わりに、その動的画像への URL を送り返します。
また、さまざまな理由から、これらの動的画像を提供するために設定されている別の HTTP サーバーに依存しないことを強く望んでいます。開発者の作業環境と運用サーバーの両方でよりシンプルなアーキテクチャを維持するなど、多くの理由があると思います。私たちのユーザーベースは非常に小さく制限されており、同時ユーザーはほとんどいません (これらの画像を提供するのに非常に高いパフォーマンスが必要だとは思いません - Play! がこれらの動的な画像を提供できると仮定すると、シンプルさのトレードオフを考えると、パフォーマンスは完全に受け入れられません)。
私はそのプレイを読みました！public/ フォルダー内のアセットはビルド/コンパイル時に .jar ファイルにコンパイルされます。これは、動的イメージの生成とサービング バックのテストが期待どおりに機能しない理由を説明しているようです。返される結果は常に前のビルドからのものです。
別のサーバーに依存せずに動的アセットを提供する方法を提案できる人はいますか?