0

I have the following problem.

One of the endpoints for my spring-boot controller has to return a POJO with a couple of big BLOBs plus some metadata information about those BLOBs.

We need to be able to send first the metadata information (so that UI can display it without any delay), and then send the BLOBs, all part of the same RESTful request. If we send the metadata + BLOBs all in the same response, it would impact the performance and UI will seem sluggish.

I've been exploring the Future, DeferredResult etc, but I couldn't find how a JavaScript client can benefit from them.

Ideally, the response would contain the metadata plus some uniquely generated endpoints to fetch the BLOBs that controller would keep cached for the time-being, till they are requested.

I wonder what approach I can take here?

Andrei
  • 175
  • 1
  • 9

1 Answers1

0

Add @JsonIgnore annotation on blob getter inside your entity class, to avoid serialization of this field to the response json. Then add separate controller method which will retrieve the same entity, but return back the contents of the blob only.

Maxim Markov
  • 101
  • 1
  • 8
  • Maxim, thanks for suggestion. We already have a separate endpoint to return blobs separately. The problem with this approach is that in order to get the blobs, we need to download and parse another binary. During parsing we come up with the metadata and the blobs. Essentially, we discard blobs from the first request and just send the metadata. At the second endpoint, we do the same parsing, discard the metadata and send back one of the blobs. I was wondering if it's possible to somehow cache the blobs from the first request and send them later on. – Andrei May 17 '17 at 14:12
  • 1
    Captain obvious says that you need to use cache to store the results from your download results. Depending on the size of your responses, you can use either choose in memory cache (for example guava LoadingCache, where you can set ttl for your case) or persistent cache. In the latest case I would just serialize responses on the disk and create some kind of job which clean all the files where creation time is before now() - ttl – Maxim Markov May 17 '17 at 14:30
  • Thanks, Maxim. I was hoping there was some magic bullet, something that connects Java futures with JavaScript futures. Sure, if the performance gets really bad, we'll have to implement some caching, like you suggested. – Andrei May 17 '17 at 19:00