Changed content doesn't updated when cached

[makadiwa]

Hi Rishi,

Thanks for the quick fixed you did that really helped to understand and run the project perfectly.

I'm implementing nuxtjs with ISR now to call the API to get the CMS content, everything work as expected, my page (/content/id) is cached and served, however when I go to CMS and update the content still my site show the cached content instead of new updated content, I assume staleWhileRevalidateSeconds : 1 should revalidate and show the updated content automatically, but it never happen.

Any clue why this happen and any fix for that?

Thanks in Advance!

[rishi-raj-jain]

Glad to know it worked perfectly!

So before you go ahead with ISR, please refer to this diagram that explains it very well.

As the diagram shows the SWR would kick in after max-age is passed, that is when the response is stale. At the time of you raising the issue, the maxAge was set to an year in this project, hence no updates to the pages/data were being made.

I've committed a improvement that will:

• Look to refresh both API and page after 60 seconds,
• Show you the timestamp of the response generated in the front-end when you visit the /blog/:username page.

This nature can also be verified locally with Layer0, by just running: npm run 0:build && npm run 0:prod

Hope this helps!

[makadiwa]

Perfect, thank for the explanation.

[rishi-raj-jain]

Updated the code to:

• Not cache the API, so that after 60 seconds you reload the blogs page to test the updated page,
• Update the page configuration to serve caches for 60 seconds when fresh response is recevied, and swr to 60 seconds (can now validate both cached and invalidated pages)
• A button to refresh page in a minute so that data changes on ISR can be demoed better.

[rishi-raj-jain]

Filed an issue with the team to ensure smooth experience while setting this all up with serveStatic approach, but for now, you can do renderWithApp with caching to ensure that you get the benefits!

[makadiwa]

Hi Rishi,

I saw your latest commit, however I don't see ISR in action with your approach, its more about the cache mechanism where updated content to all public user will be available after the maxAge expired. However in ISR the new user will get the latest content immediately as he/she hit the site and current user will get the cache content which will get updated when the cache expired.

Any best way that will serve ISR in terms of updated content immediately available for new user instead of waiting for cache time to expire?

[rishi-raj-jain]

@makadiwa

Hey!

Nope, maybe you are referring to some old commit. The latest commit at your time of writing where I had both maxAge and SWR seconds.

Again with ISR, please refer to this diagram that explains it very well.

In the deployed example:

• Open the page /blogs/rishi-raj-jain
• Wait for 3 + some seconds and hit a reload
• If the API generated a succesfull response in the backend, you'd a see a new timestamp, which you should in this case,
• Otherwise you the old page
• Open the same page in incognito as soon you get a new page and you'd see a cached version served to you
• Take another medium username, open /blogs/that-username in incognito and that'd show some version, reload the page to see that the cached version is served
• Now close that, and after 3 + some seconds go to that page again and you'd see a new response.

In both the cases, the platform is able to regenerate page as soon as SWR kicks in (as explained in the diagram) or serve stale if it's within the caching age of the new response obtained. Hope this is now clear?

If you want to have always the latest info, just set maxAge to 1 seconds and there's it!

[makadiwa]

Hi Rishi,

Thanks for the reply!

Here is my understanding with your approach.

If maxAge is set to 1 second it doesn't make any sense at each time after 1 second it will hit the server and fetch the data(from api/content.json)and I think that is not the use of dynamic routing with cache.

Here what happing with your approach is page is cached (say for 60 second) till this will get expired it will serve the page to all the users (Old + new) the cached version, once the I wait for 60 seconds and reload it will get the updated content.

Here how I have tested your latest commit:

• Set maxAgeSeconds to 60 second
• Open the page /blogs/rishi-raj-jain
• If again I reload the same page it will serve content from cache (OK)
• Now, if I go to fresh browser(say IE or Incognito ) with no cache and hit the same URL
• It give the content from the cache, instead as its the new user it should give the updated content.

Here actually I don't see ISR in action, because we are using CMS to call the API and get the data and display to user, now everything is cached for 60 second and the content will serve from cached till it get expired for both old + new user and once the maxAge is expired it will give me new updated content, instead that should not be case. I assume with ISR it should serve the updated content to the new user and for the same old user it will be from cache and once maxAge is expired the content will get updated.

Sorry if the above scenario confuse you.

[rishi-raj-jain]

@makadiwa

Loving this back and forth!
I'm excited to learn, captured that message clearly in my head. It doesn't confuses me 👍🏼

Now what is ISR according to Next.js:

• "Any requests to the page after the initial request and before the 60 seconds window will show the cached (hit) page." is inline with "It give the content from the cache for any request after initial and before 60 seconds"
• "After the 60 second window, the next request will still show the cached (stale) page. Next.js triggers a regeneration of the page in the background." is inline with "once the maxAge is expired it will give me new updated content"

But here, note that cache timings that is maxAge and SWR seconds are absolute in nature, it's not relative to any request that comes in after the initial request. So say after you've deployed this:

• First request that comes to /blog/rishi-raj-jain, will be SSR and would be cached for future (say t= Xs)
• Now regardless of the number of requests that come within X + 60s, all those would show the same page
• Now the platform runs a background service that'd rebuild the page and be ready to serve the updated version as soon as it's available, say time it took to generate new page is Y seconds
• Any request that comes in after (X + 60 + Y)s would serve the new cached version
• Then repeat from step 2

and how it matches what I've implemented as you mentioned correctly:

Here what happing with your approach is page is cached (say for 60 second) till this will get expired it will serve the page to all the users (Old + new) the cached version, once the I wait for 60 seconds and reload it will get the updated content.

Did that make sense? Happy to set up call to understand more about the requirement, understanding of ISR.

[makadiwa]

Hi Rishi,

Glad that you get what I have written :)

Looking at your reply my understanding was correct.

However it will be good if can have a call for fruitful discussion. Let me know your preferred time. I'm working in IST timezone.

Thanks in Advance!

[rishi-raj-jain]

@makadiwa
Yup! A call works. Feel free to send me an invite for tomorrow at rishi18304@iiitd.ac.in. Timings: 2 PM IST - 2:30 PM IST.

[makadiwa]

Hi Rishi,

Thanks for giving the time, I have mailed(malik.kadiwar07@gmail.com) you the meeting details. See you at 2 PM IST

[makadiwa]

Hi Rishi,

Thanks for joining the call.

Let me know when you have any solution for on-Demand ISR with layer0 as we have discussed.

Thanks!

[rishi-raj-jain]

@makadiwa Hey, I've raised a request with the team. Hope that we can reach back to you with the good news soon!