客戶端與服務器映像過程並顯示

Question

客戶端與服務器映像過程。

我們得到了一個大型系統，該系統可以在JSF（primefaces）EJB3上運行，有時還可以在JavaScript邏輯上運行（例如使用Firebase和東西）。

因此，我們遇到了這個問題，我們有一個servlet來提供一些圖像。 后端進行查詢，然后從數據庫中提取一些blob img，將BLOB制成字節數組，將其發送到瀏覽器會話內存，然后servlet將其接收到ulr-OurSite / image / idImage中進行服務 。 前端通過<img>(url/image/id)</img>調用，到目前為止效果還不錯。

然后，我們使用一種新的直接方式來顯示img，將BLOB / RAW數據發送到前端， 然后將它們轉換為Base64.imageReturn。 並將其傳遞給html。

 Base64 codec = new Base64();
                String encoded = codec.encodeBase64String(listEvidenciaDev.get(i).getImgReturns());

對於幾乎所有情況，這兩種方法都有效。

注意：我們之前沒有嘗試過此操作，因為我們無法將RAW數據通過序列化對象和RMI的層傳遞。 現在我們可以了。

所以現在有兩種方法。

我們要么將數據發送到servlet並將其放在某個url上，這意味着后端完成所有工作，而前端僅調用url

或者我們將數據發送到前端，這將使魔術變得神奇，並將其轉換為img。

這帶來了兩個問題。

1. 如果我們發送到前端RawObject或讓他們調用URL以顯示其圖像內容，最終用戶將下載相同數量的數據嗎？ 這很重要，因為我們有些遠程分支機構的互聯網連接較差

2. 值得將艱苦的工作傳遞給前端（轉換數據）或后端（轉換和發布）嗎？

---

編輯：

我的問題不是BLOB（ 我稱為RAW數據 ）大於base64的問題。

它是; 將數據作為對象傳遞並將其轉換為可讀圖片比使用實際IMG從我們的servlet中傳遞url並將其加載到html上要重得多。

Answer 1

我確實選擇了關閉該答案，因為我們進行了一些測試，並且前端使用了相同的帶寬。

無論如何，我們同時使用兩種解決方案

如果我們不希望前端進行大量編碼，我們會為該圖像設置一個servlet（帶有更多代碼和更多服務器負載）。 我們尋求針對特定情況的最佳優化。