[Question] - Can I use this solution for Nextjs monorepo multiple different apps sharing basically the same cache

[omerman]

Its more of a question.

I have a monorepo that has multiple nextjs apps that sometimes need to notify each other about cache revalidations.
Currently I handle it by REST api's, meaning the different apps send Rest's to each other notifying about tags that needs to revalidate.

All the Apps use the same fetch queries, therefore technically their caches are redundant.

So first of all I was wondering if your cache handler solution work on my apps, making the cache shared between the different apps.

Secondly Im not sure if I understand exactly what happens once you revalidate, if an app still looks at it's LRU for something that was just revalidated, it will be out of sync for until the resource that was revalidated is out of the LRU cache? or am I missing something.

[better-salmon]

Hi @omerman! You definitely can make one storage for different apps. But there are a lot of things to consider. You are using the App Router, aren't you?

[omerman]

Im using the app router yes,
and Im using unstable_cache. And I already checked and for same requests I have the same cached results.
I also played with an implementation myself, I extended nextjs implementation and modified the place where the cache is saved to a shared place between my apps. It worked in the sense that the cache was unified, but when i revelidated the cache in one app, the other's wouldnt revalidate until the resource was not in nextjs memory cache, and I didn't want to give up the memory cache feature.. so I gave up on my hack and this repo caught my eye.

[better-salmon]

When using @neshca/cache-handler, you can choose whether or not to use the memory cache. However, it functions differently from the native Next.js solution. Our CacheHandler provides an array of handlers in the configuration. When your Next.js application retrieves data from the cache store, it first calls the get method of the first handler in the array. It only passes the operation to the next handler if there is an error.
On the other hand, the set method works concurrently for all Handlers from the array.

It's essential to note that the memory cache in this setup serves as a fallback if your primary cache store is unavailable. Moreover, memory caches on the app level are not synchronized with each other.

This setup ensures that your app retrieves data from the shared cache store if available and only uses the memory cache as a fallback if necessary. As a result, revalidation works between the apps.

There is a guide available for creating custom Handlers if you wish to make your own.

[omerman]

So to clarify, If I want to stay up to date at all times I would have to let go of the Next.js default in-memory-cache and also Im not getting an in memory cache, the in memory given here is only a fallback incase Redis is unreachable?

Isn't it better, performance wize, to have an in-memory-cache for the redis implementation as well which will not function as a fallback, but rather as a warm fast cache before an older key is being searched uppon?