feat: Cache Cover Art Calls

[anshg1214]

This PR Implements a client-side caching system for cover art using IndexedDB (with LocalStorage fallback) to improve performance and reduce server load. The system includes automatic cache expiration and cleanup mechanisms.

[MonkeyDo]

I deployed to test.LB for in-situ testing, and it doesn't seem to be working for me.
I can see the stores in IndexedDB but it does not seem to store anything, the stores are empty, and going back and forth on two pages seems to call the CAA every time for all albums.

[anshg1214]

I can see the stores in IndexedDB but it does not seem to store anything, the stores are empty

I deployed the PR back to test, and I believe the PR is working fine. Did you try refreshing the DB again?

and going back and forth on two pages seems to call the CAA every time for all albums.

That's strange. I checked navigating through through the pages where release cards are being rendered, things are working fine. Can you share the network logs?

[MonkeyDo]

Yes I had refreshed the DB, but still nothing.

This time around testing, I do see two entries (for the same cover?) in there, but the other covers are still being loaded every time.
HAR logs I will send privately as they contain cookies.

The duplicate entry with true/false at the end that I have in IndexedDB, in case it is relevant:

[MonkeyDo]

OK, so I see that the issue might be between my chair and my keyboard :)

I was looking at my dashboard when testing, I didn't realize this was going to apply only to the release card.
Re-reading your comment made me realize that.

I tested again, and I'm still not sure it's working as expected.
The SVG at the top of the artist page that loads a cover art collage makes it hard to be sure, but it still seems to hit the CAA endpoints. I tested with https://test.listenbrainz.org/artist/f58384a4-2ad2-4f24-89c5-c7b74ae1cce7/ which has many albums:

• scrolled down and expanded to see live albums (won't be in the collage for sure)
• scroll horizontally to load all live albums covers
• refresh the page, wait for collage to load, purge network logs
• scroll down and expand until I am on the live sections again
• purge the network logs again
• scroll the live section > 144 requests to the CAA

For context, checking the indexedDB after all that, I see 13 entries only
I am assuming I should I be seeing no requests to the CAA and more entries in indexedDB.

[MonkeyDo]

rag? Release Art Group?

[anshg1214]

For context, checking the indexedDB after all that, I see 13 entries only

When we're displaying the release card, if the props contain caaID and caaReleaseMBID, then the calls are directly made to archive.org using this function. In this case, we don't require caching anything.

If we don't contain this information we're caching to reduce the 2 calls to coverartarchive.org, and saving the final image URL in the cache.

scroll the live section > 144 requests to the CAA

So, when you're testing on the artist page .These requests are to get the image from the URL. None of those requests are going to "fetch" the image URL from CAA.

I am assuming I should I be seeing no requests to the CAA and more entries in indexedDB.

If you want to further optimise the process, we'll need to cache the images themselves in the cache.

[MonkeyDo]

OK, now I'm on your page ! Thanks for the further explanations.
In that case I think this is working as intended 🤖