bump 😄

i don't think use cache can be used to save cache on redis

for cacheComponents and "use cache" you need cacheHandlers not cacheHandler
I wrote this one https://gist.github.com/Haaxor1689/55e9afd3409030211315fc80db6db462
but it's not fully working

https://github.com/vercel/next.js/discussions/86901
I've made a discussion post on github about it

I recently saw this implementation
https://github.com/mrjasonroy/cache-components-cache-handler

Havent used it myself yet, but it looks pretty good just based on code alone. Supports several different backends too

huh this part makes no sense

it tees the readable stream, assigns the new stream to entry.value and the then immediately replaces it with the return stream in the return statement

so the tee is completely useless right?

I thinkkkk its just defensive programming to ensure the returned objects value always contains a valid readablestream while ensuring the internal entry does too. Otherwise if u return entry directly, the caller consumes the stream immediately, thus invalidating the internal reference. So youll temporarily have corrupted state until the caller releases the lock and the entry is gc'd. In this case i think it doesnt matter bc nothing is done with the internal entry after returning it. But its a generic defensive programming pattern to make sure the DataCacheEntry contract is being upheld (entry.value must contain a valid readablestream)

I just spent like 20 mins researching this so if im wrong pls tell me cuz its the first time ive encountered this as well and its pretty interesting

I'm asking because the readable stream is created few lines above by reading a base64 string to a new instance of readable stream so it isn't used anywhere else

I'll go try this solution and see if it produces the same issues as mine was having and if not I'll pull it apart to see what's different

I don't do tag stale/expired times, split the cache entries into multiple redis keys (meta, tags and buffer) and also do buffer streaming instead of sending and reading the hole buffer all at once

would love to find someone more familiar with Redis to tell me if my approach of splitting keys is better or not

i was looking at the nextjs source for the default cache handler and they use tee as well
https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/cache-handlers/default.ts#L104

though not sure ab this. probably better to ask in a different server

yeah but they use tee because they hold the readable stream in memory

where?

also wanna dm? we're spamming this poor guys post

can do