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

Disable swr behavior by default for cached functions #1950

Open
pi0 opened this issue Nov 23, 2023 · 5 comments
Open

Disable swr behavior by default for cached functions #1950

pi0 opened this issue Nov 23, 2023 · 5 comments

Comments

@pi0
Copy link
Member

pi0 commented Nov 23, 2023

Having SWR implicitly by default can have unexpected results especially since it will be also enabled for definedCachedFunction.

One example of when it can go unexpected is that when both a route (via routeRules) and the internal utils it is depending on are using cache, it doubles the cache invalidation time (it happened for ungh few days ago too for example although was explicit flag bug it is an easy trap!)

On the other hand, having SWR for page level caching i belive is something essential for best rendering performances (non API routes). But i guess for this, we have swr: true route rule shortcut so it should not be something to worry.

It is a breaking behavior change still, therefore I am thinking of considering either via a minor version with good enough merits/docs or consider for Nitro v3. Ideas welcome 👍🏼

@MickL
Copy link
Contributor

MickL commented Nov 23, 2023

I would highly suggest swr default set to false as swr creates unexpected behavior: The cache is invalid but still returned. This might be valid for some edge cases, but most of the times devs/users probably dont want to receive an invalid cache response.

Use case example:

  • User presses update-button
  • Cache is invalid but still returned
  • Users still sees same cached result as before
  • User needs to press button a second time
  • Now users sees updated result

@pi0
Copy link
Member Author

pi0 commented Nov 23, 2023

Thanks for the feedback dear @MickL indeed most of the unwanted scenarios are for API/Function calls for action which probably makes no sense with the SWR caching strategy to be enabled by default (but probably also not any caching strategy. it mainly needs to avoid running multiple times in parallel using a semaphore lock/variable).

@passionate-bram
Copy link
Contributor

As a user of cachedEventHandler, I'd expect the function to cache the result and provide appropriate headers. This mimics the behavior of how a cachedFunction would behave; it returns the cached value immediately or re-runs the function. The stale-while-revalidate pattern is more advanced in this case, imagine if cachedFunction kicks off a promise to update the cache.

The twin-like similarity of cachedEventHandler and cachedFunction is probably the main reason for SWR to be opt-in, it defies the default understanding of how a cache would be implemented.

@platform-kit
Copy link

@pi0 is there any way to disable the default SWR behavior? I've just adopted Nuxt3 and am baffled as to why my API calls are being cached, and have no clear path to getting around this issue.

@passionate-bram
Copy link
Contributor

@pi0 is there any way to disable the default SWR behavior? I've just adopted Nuxt3 and am baffled as to why my API calls are being cached, and have no clear path to getting around this issue.

You can find what you need in the options for cachedEventHandler.
Basically, set swr field of the options object to false.

@pi0 pi0 mentioned this issue Jun 13, 2024
16 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants