Blazity / next-image-proxy

🖼️ Image proxy for Next.js. Makes it possible to use dynamic domains in next/image component.
https://next-image-proxy.vercel.app/
78 stars 7 forks source link

Is it possible to add support for Edge Runtime? #5

Closed maxeth closed 1 year ago

maxeth commented 1 year ago

Hello,

I was wondering whether it's possible or whether someone has found a way to proxy images successfully with Vercel's Edge Functions, as that would reduce the duration of initial, non-cached image requests by a lot.

I think that would make a great feature, but I couldn't find a way to proxy the requests successfully with the API of Vercel's Edge Runtime so far.

bmstefanski commented 1 year ago

Hi,

Have you tried adding this snippet to the API route file? https://nextjs.org/docs/api-routes/edge-api-routes

also if you're using new version of Next.js then they recently added a feature than replaces this library https://nextjs.org/docs/api-reference/next/image#remote-patterns

export const config = {
  runtime: 'edge',
}
maxeth commented 1 year ago

@bmstefanski The thing is, edge functions use a different (limited) API so many changes would have to be made.

I've seen the new remote-patterns options but there are still some use cases for this library and proxying images in general, because many (myself included) use an external service for image optimization (cloudinary, imgx etc.) that's better and cheaper than Vercel, but if you do <Image unoptimized /> to let your own service handle optimization, next doesn't fetch/cache the image locally and just passes through the original src to the <img/> tag, which is a privacy problem in many cases (pretty sure it's illegal without user consent according to GDPR for example).

So for my use-case, I proxy images with unoptimized={true}, which results in the images not being cached, and fetches with "normal" API routes are really slow (with a cold start it takes a few seconds to load the image, wheres edge routes would only take like 300-400ms).

I added Cache-Control headers to my proxy-API route which somehow fixes this for now. 🙂