Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching fails when returning a Buffer (PNG image) #1894

Open
jschroeter opened this issue Nov 8, 2023 · 8 comments
Open

Caching fails when returning a Buffer (PNG image) #1894

jschroeter opened this issue Nov 8, 2023 · 8 comments
Labels

Comments

@jschroeter
Copy link

Environment

Node: 18.18
Nitro: latest

Reproduction

  1. open Stackblitz
  2. open dev tools and disable cache in network tab
  3. click the reload button in the preview multiple times

Expected: 2 logos should be visible

Actual result: the second logo using the cached route breaks when reloading in between 5s (since the cache max age is set to 5s)

Describe the bug

Use case

I do want to return a dynamically generated PNG image in a Nitro route. This works fine in general.

Issue

I also would like to add caching using cachedEventHandler. But all requests that should return a cached response, return the serialised JSON instead of the binary data, e.g. {"type": "Buffer", "data": [137,80,78,71,13,10,26,10,0,...

Additional context

I guess it's related to unjs/unstorage#142 and the Nitro Cache should use setItemRaw()/getItemRaw() for the case of a Buffer?

Logs

No response

@bernhardberger
Copy link

I can confirm this issue. It breaks SWR when using sharp on a node server. Interestingly though this issue isn't present when using ISR (which supposedly as per docs is the same as SWR with just some cache headers added for Netlify and Vercel?!)

@jryd
Copy link

jryd commented Feb 27, 2024

We're experiencing this now also after swapping defineEventHandler for defineCachedEventHandler.

We run an API endpoint in Nuxt that proxies image requests to a protected/private source. We want to cache the response, but after using this we sporadically see the serialised JSON returned instead.

@alexMugen

This comment was marked as off-topic.

@alexMugen

This comment was marked as duplicate.

@f-lawe
Copy link

f-lawe commented Apr 11, 2024

Experiencing the same issue here too. Is there a way to wrap up the response of defineCachedEventHandler so we can eventually process the serialized JSON into binary data when it occurs? The overall response won't be fully cached, but at least the proxied image will be.

@f-lawe
Copy link

f-lawe commented Apr 19, 2024

So, we implemented the workaround I mentioned earlier: we have a regular defineEventHandler endpoint that calls our image cached using defineCachedEventHandler and converts the serialized JSON back to a buffer. The overall response is not cached by the browser, however we reduced our response time and made it flat (we used to have huge variations, depending on server load),

That's not ideal, but that's an improvement, and it works!

@bernhardberger
Copy link

bernhardberger commented Jul 18, 2024

So, we implemented the workaround I mentioned earlier: we have a regular defineEventHandler endpoint that calls our image cached using defineCachedEventHandler and converts the serialized JSON back to a buffer. The overall response is not cached by the browser, however we reduced our response time and made it flat (we used to have huge variations, depending on server load),

That's not ideal, but that's an improvement, and it works!

Is there any chance you could post a working implementation? I think this could help a lot of people since this issue isn't getting much attention..

@Barbapapazes
Copy link
Member

Hey,

Here the code for the workaround

const buffer = defineCachedFunction(async () => {
  return Buffer.from("Hello, World!");
});

export default defineEventHandler(async (event) => {
  return Buffer.from(await buffer());
});

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants