[RFC] SSG with incremental-static-regeneration and revalidate
See original GitHub issueHi,
Is your feature request related to a problem? Please describe.
When you setup a page /[id].ts
for SSG with fallback: true
and an API route /api/preview.ts
to enable preview mode
, when you makes “preview” changes this works pretty well and you can see live changes of the page. 👍
Still, changes you make that appears correctly in the preview mode
does not update the s3 files static-pages/*.html _next/data/*/*.json
accordingly.
So whenever you display such a page “publicly” (with preview mode disabled), it does not display the latest changes. What it displays is the latest version of the page stored in s3.
Since currently, the preview mode does not update s3 files, we cannot see the changes with preview mode disabled.
So currently, for a specific page youdomain/abcde
, the file static-page/abcde.html
never updates (this is also true for the corresponding json file). When one makes changes in preview mode, the plugin does not update the static-pages abcde.html
so the change does not appear publicly.
How to reproduce the issue To reproduce this problem, please follow the steps:
- Render without preview mode (no cookies) the page
/abced
. It should create_next/data/<id>abced.json
andstatic-pages/abced.html
files in s3 and render the page according to the RFC. 👍 - Modify the content of
/abced
with preview mode ON (with cookies) (to do this, use an API route, e.g./api/preview
). - Render again the page
/abced
, as the result, the content shows the updates make in 2/ 👍 - Remove the
preview mode cookies
- Display again the page
/abced
, since preview mode is OFF this time, the content are not the latest. It displays the result in 1/ instead of displaying the result with modified content in 3/ - If you look, steps 2. and 3. do not update files
_next/data/<id>abced.json
andstatic-pages/abced.html
in s3. It does not invalidate cloudfront cache neither.
Describe the solution you’d like
A good solution requires that when you make changes made in preview mode
, the next time you render without preview mode the page, it shows the changes.
To fix it, we need to make the fallback page never cached max-age: 0
, so the lambda can return the newly generated page (and cache it) the next time the same route is hit. But we also need to store the html and json files in preview mode for each preview request (RFC STEP 2)
Describe alternatives you’ve considered The alternative is to force delete those files in s3 and to invalidate cloudfront cache without the plugin. It is not standard, does not follow the RFC and it is a ugly and unsatisfying solution. Per file cache invalidation is not scalable (limit of 3000 concurrent invalidation on AWS) and it has a cost.
Additional context @dphang discusses a related issue here :
I did find that issue too, it is because fallback page gets cached after 1st hit. But if you bust the cache after hitting a non-prerendered route (add a random query parameter), with the new change it would pick up the page that was just stored in s3, so all props are populated.
To fix it, we need to make the fallback page never cached (
max-age 0
), so the lambda at the edges can return the newly generated page (and cache it) the next time the same route is hit. But we also need to version the pages properly as I realized we are not clearing them properly (we only have one set of pages under static-pages, so subsequent deploys may pick up an old version).
_Originally posted by @dphang in https://github.com/serverless-nextjs/serverless-next.js/issues/798#issuecomment-727603410_
This discussion triggers a related issue, that is users request cached, still up-to-date versions after a new deployment. This analysis apply to preview mode
too as described in this thread.
Also, https://github.com/serverless-nextjs/serverless-next.js/issues/355
A.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:16
- Comments:18
Top GitHub Comments
Hey @arelaxend, incremental static regeneration imho is a killer feature of Next.js. Do you have any idea if and by when serverless-next.js will support this?
Hi, if there is an update on this? Or is there some other method to solve this problem?