Client vs server image process and shown

Question

Client vs server imagen process.

We got a big system which runs on JSF(primefaces) EJB3 and sometimes JavaScript logic (like for using firebase and stuff).

So we run onto this problem, we have a servlet to serve some images. Backend take a query, then extract some blob img from DB, make that BLOB into array of bytes, send it to browser session memory and servlet take it to serve it in ulr-OurSite/image/idImage . Front end calls it by <img>(url/image/id)</img> and works fine so far.

Then we are using a new direct way to show img, we send BLOB/RAW data to frontend and there we just convert them into Base64.imageReturn. and pass it to html.

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

Both work, for almost all cases.

Note: We didn't try this before because we couldn't pass the RAW data through our layers of serialized objects and RMI. Now we can of course.

So now there are two ways.

Either we send data to servlet and put it on some url, which means the backend does all the job and frontend just calls url

or we send data to frontend which is going to make some magic and transform it to img.

This brings 2 questions.

1. If we send to frontend RawObject or make them call URL to show his image content, final user download the same amount of data? This is important because we have some remote branch offices with poor internet connection

2. Is worth pass the hard work to frontend (convert data) or backend (convert and publish)?

---

EDIT:

My questions is not about BLOB ( the one i call RAW data ) being bigger than base64

It is; passing the data as object and transform it to a readable picture is more heavy to internet bandwidth than passing a url from our servlet with the actual IMG and load it on html ?

Answer 1

I did choose to close this answer because we did some test and it was the same bandwidth usage on front end.

Anyway we make use of both solutions

If we dont want to charge frontend making a lot of encode we set a servlet for that images (that comes with more code and more server load). We look for the best optimization on specific cases.