@aric Hey this is cool. I was just having some problems because I'm not checking both images for artwork. Some feeds have only one or the other. This would solve it 😄.
Seems a tad slow though. For example this:
Takes few seconds to load. Is there any caching?
I was thinking about doing something like this with Cloudinary. My idea was a user requests an image of a particular size. If the image file exists, then it serves it from the Cloudinary CDN. If it doesn't exist, then a function creates the file and uploads it to Cloudinary so it's now on the CDN while sending the created file to the user in the response.
@StevenB I had a similar concept, but storing and/or dynamically generating a million different variations... x3 million feeds. the math became problematic.
@aric Yeah, that's why I decided against it. It seems like it would be pretty expensive. Maybe there's some way to store the most recently requested images in memory for faster serving of frequently requested images, and caching should definitely speed things up after the initial download.
I would also consider using WebP as one of the formats returned.
Overall, a much needed service. Any developer using it should include you as a value recipient for streaming sats.
@aric It might be a good idea to return status 400 if the caller requests an image size that is not available 🤔
@aric Hmm I got some 503 reposnses from the image server. Did I pound it too hard? 😅
If I do a search that returns 60 results, my app will try to download them all at once. Is that too much?
I tried to set the lazy loading on, but I guess it didn't work 😬
Intended for all stake holders of podcasting who are interested in improving the eco system