-
Notifications
You must be signed in to change notification settings - Fork 86
Support for incremental SSG (ISG/ISR) #151
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
Comments
This package actually does support it, to an extent! Here's a demo: You can use these URLs in the box there for the demo: Here's the code for it: Do you have any other questions related to this? |
Can you please elaborate to what extent there is support? Is there for example only support for the In my test |
I created netlify/next-on-netlify#37 to explore the option of adding incremental static regeneration. |
Ideally, pages with incremental static regeneration (ISR) should be statically pre-rendered and then re-rendered upon request at the provided revalidation interval. This is currently not possible, because we can only either have a static page or have a page that is server-side rendered. As a temporary workaround, we will be SSRing pages with ISR. This means they will be less performant that regular static pages, but at least their content will be fresh. We believe that a focus on the freshness of the content matches the intention of the user more closely than a focus on the page's performance. Discussion: https://github.com/netlify/next-on-netlify/issues/35 Read more about ISR: https://nextjs.org/blog/next-9-5#stable-incremental-static-regeneration
Hey @joostmeijles, You are right — there is currently no support for incremental static regeneration (ISR). Ideally, pages with ISR should be statically pre-rendered and then re-rendered upon request at the provided revalidation interval. This is currently not possible, because we can only either have a static page or have a page that is server-side rendered. Netlify is investigating and researching possibilities for fully supporting ISR. In the meantime, your proposal to server-side render pages with ISR is a fantastic workaround. This means that these pages will be less performant than regular static pages, but at least their content will be fresh. I believe that a focus on the freshness of the content does indeed match the intention of the user more closely than a focus on the page's performance. Based on your excellent work done in netlify/next-on-netlify#37, I created a WIP branch to server-side render pages with incremental static regeneration: Again, thank you for raising this issue and for your very helpful proposal! 😊 |
Thanks so much for this work @joostmeijles and @FinnWoelm! This is so exciting to get even more support for ISR. Are there any other gaps that need to be filled to get this better supported? |
@cassidoo I think Netlify stale-while-revalidate support is needed to fully support ISR. |
It seems that ISR somehow stopped working on the Netlify CDN. The serverless (SSR) functions complete but do not return and therefore result in a timeout after 10 seconds. For example:
@FinnWoelm @cassidoo any clues ? |
@joostmeijles things are still working on my end! The last release is 20 days old, so there shouldn't have been any change sincethen. Is it possible that you use some sort of third party library that keeps a connection open? Last week, @garrypolley reported something like this when using Prisma: netlify/next-on-netlify#55 (comment) Otherwise, happy to have a look at your code and/or see if we can reproduce this issue somewhere. |
Possibly! Will dig a bit deeper 🙂 |
Okay, sounds good! Quick test would be to add a super simple page without any Something along the lines of this: // pages/mypage.js
export default function MyPage() {
return (
<p>Hello World</p>
);
}
export function getStaticProps() {
return {
props: {},
revalidate: 1
};
} |
I am trying to get this working for a project and am finding that the pages are always hitting the function and are not being cached at the CDN. Is that the behaviour you are finding? |
That’s the expected behavior. It currently basically works the same as SSR
pages.
Op do 3 dec. 2020 om 13:06 schreef Dave Taylor <[email protected]>
… I am trying to get this working for a project and am finding that the
pages are always hitting the function and are not being cached at the CDN.
Is that the behaviour you are finding?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/netlify/next-on-netlify/issues/35#issuecomment-737900953>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBEECRB3SKGKC6VBPQ546TSS55MLANCNFSM4QQSDNRA>
.
|
@joostmeijles If I'm understanding this correctly, ISR is now actually just SSR under the hood when hosted on Netlify. |
As far as I know Netlify does currently not support stale-while-revalidate. Without this feature it is not possible to implement ISR (and thus SSR is used). SSR basically is a blocking call, and the end user waits for the result to be calculated, while true ISR calculates the result in the background and returns the previous result to the user. |
Thanks @joostmeijles! That makes sense. Intended/Normal ISR State |
@iDVB hey! what @joostmeijles said is correct - netlify does not currently support SWR (stale-while-revalidate). so yes, currently, ISR on netlify is a blocking call.
the current behavior is temporary. we want to and are aiming to support ISG/ISR in the way that @joostmeijles describes ("true ISR calculates the result in the background and returns the previous result to the user") - or as close to this behavior as possible without compromising our caching and jamstack philosophies. re: wrapping your heads around the intended mechanics, i highly recommend watching a few minutes of ryan florence's explanation in this video (timestamped!): https://youtu.be/bfLFHp7Sbkg?t=907 to answer your question though, yes, each subsequent request gets the fresh update hope that helps!!! :) |
Howdy, I had a question about three lines that log out when building:
We have ~25 pages that are pulling from markdown using fs, and they have neither fallback nor revalidation values set, however they all end up logged under Functions bundling, which ends up taking anywhere from 4-7 minutes. Is this expected behavior? The line about copying pre-rendered pages to out would lead me to believe it isn't. If you can look at build logs, deployment 6058d81084773b0007928857 would be an example. |
@dlaugharnTAG howdy! fair question! i believe, per https://github.com/netlify/netlify-plugin-nextjs/blob/main/src/lib/steps/setupPages.js and here, that we log these lines no matter what. if there are no file names underneath those particular logs you quoted (the file names get logged in the pages loop in setup.js), then there aren't actually functions set up for these files (or there shouldn't be). the line about copying pre-rendered pages to also: i think i need the whole link to the deploy logs (including the site name) to see them 🤔 |
@lindsaylevine Do you have an estimate on when this will become a reality? This would make Netlify a viable alternative to Vercel for sites depending on ISR. |
@mikaelgson stay tuned 👀 what i can say right now is that we are a lot closer to offering "our version of ISR" than ever before! i will of course be sure to update this thread when i can share more info. :) |
Hi @lindsaylevine, We're having the exact same problem. We haven't implemented previews yet but our Thanks in advance 😄 |
@lindsaylevine first of all thank you for all the amazing work on this plugin 🙏 We've been exploring Netlify as an alternative to Vercel for our Next project for a while now, and with On-demand Builders this now seems a lot closer to reality. I'm currently trying to plan the internal timelines for us to test next on Netlify with ODB and was wondering how "stable" the experimental branch / ODB is considered at the moment - is this usable for a production environment yet, or should we wait a bit longer? Also curious how close you might be to an implementation of the |
@tbgse thanks for the kind words 😊 i would say the odb branch is reliably stable. it's been in a separate tagged release for 2-ish weeks now for testing and we haven't had any issues reported. that means, within the next week or two, we'll likely merge it into main and release it as the standard/default plugin! i pinged internally earlier to see how much i could share re: |
Hi all, |
updated title to help better direct incoming users looking for ISR stuff :) |
Is there way I can trigger the on-demand builder to "rebuild" a particular page? |
@saidattax providing this mechanism is something we are very careful with because it is pretty easy to get your site in an inconsistent state with such a capability. since users have no tools to debug this, it would increase the load on our support team to debug sites, which we want to avoid. I can generally recommend these strategies right now:
nevertheless we are very interested in hearing about your usecase and how we can solve it better in the future. |
@mraerino Thanks for reply The content for my sites is updated on-demand from a dashboard. I could indeed trigger a new deploy, but I need the build to be quick. Builds take 30-60 seconds usually. Currently, the data for the site is fetched from a database and SSRed. However, in the case of data-server downtime, I'd need a cached version to be sent. Hence, I wanted to trigger ODBs to build specific pages that need updating. Thanks |
@mraerino we are also waiting for a revalidate feature where we can regenerate pages in the background. We use this for example to allow our marketing team to update localization files, inject experiment data, adjust content in a CMS for a single page etc. those changes will then be picked up during revalidation through getStaticProps and updated without requiring a full redeploy. Since we have a lot of individual pages (20k+) running a full redeploy is very resource and time consuming, so through revalidation that gives us a bit more flexibility where pages can update one by one as needed. |
how would you handle data changes that affect more than one page? |
Since we're running an ecommerce site that is usually not a problem. E.g. we have a ton of marketing related pages, but no real "overview" page where all the titles would be displayed, so there are rarely situations where a change to one page would also impact other places. The same goes for product pages, e.g. if the description of a single product is updated in our catalog, only that one specific product page would need to change. In other places where this content is used, we would mostly use client side rendering (e.g. in the cart / checkout etc.) so no re-generation would be needed besides that single page re-fetching some of it's data and updating on the edge. There is of course always a tradeoff that in some situations a user might see stale content or inconsistent content between views - in most cases we deal with that by re-fetching data on the client side and apply modifications as needed. But for us this has mostly been a tradeoff that we've been willing to make if in return it allows us to give a bit more "real time" feel to our stakeholders in marketing / product who make edits to our content, while still having the benefits of SSG. If you're up for it I'd be happy to connect and walk you through our setup a bit more in detail. |
so if one of the stakeholders comes to you saying that some content is outdated, because it was not properly re-validated, how would you debug that situation? would you just re-deploy the site and wait for the next time this happens? |
Right now we're logging into Sentry during revalidation, so if an error occurs during revalidation, we have at least "something" to look at. These errors are very rare for us, and like you said, running a full deploy usually then fixes the problem. Having more insight to debug this would be absolutely fantastic though. I guess I could imagine an overview that shows which pages are scheduled for revalidation, when the page was last revalidated and a status marker if the last revalidation was successful or not. Access to a log of the builder would be really helpful too, if it tried to revalidate and ran into errors (e.g. maybe because an API was down while trying to revalidate the content). It would also be quite important that the stale content will continue to be served if the builder runs into an error. 95% of times if a revalidation failed in our case it was due to an API being not reachable or an odd response. In that case having the builder retry a couple of times (or the ability to manually click a button for it to try again) would be really nice. It would be even better if this revalidation could not just be triggered by setting an interval (like it is implemented with next at the moment on vercel) but potentially could also be called directly / through a webhook so that for example CMS updates could immediately trigger a page to be revalidated. |
Came here after quite a while trying to understand why Netlify doesn't pick up forms. This should definitely be mentioned somewhere inside the Netlify Form docs, I imagine it's quite common use case. |
Is there a timeline as to when this will be completed? |
@mraerino response headers indicating the the page render mode and settings would be very helpful - eg: whether SSR or SSG, and if SSG, then fallback and revalidate settings. I understand that this is a NextJS responsibility (I think it probably requires running a custom server at present [clue]), but I'd find this helpful!
Agreed! Watch the pending NextJS feature: programmatically purging routes
|
Hi there, does Netlify support ISR for NextJS app now? It seems that Vercel can support well ISR with 'revalidate' in getStaticProps, and I did use Next Essential plugin in Netlify and still, my static sites are not updated after 'revalidate' interval. |
The issue not persist in vercel, Netlify support team please share your updates, when the netlify users can expect full support of ISR. |
hey all. i know it's been a LONG time. please hang tight just a tad bit longer. we are about to release a huge plugin rewrite in the coming month (beta to come this week), and the ISR conversation continues to evolve for us internally. for now we still recommend DPR / using fallback: true without the revalidate flag. |
Hi, here is how I have solved this issue for now until this feature is implemented:
Example:
This could create flashes of the old data in the UI if the updated and initial data doesn't match, however once the build is done again, this won't happen. This approach works for our use case because we have fairly small amount of pages to generate. As a result our homepage is loaded significantly faster because it's no more SSR. |
Hey all just curious if there has been any more updates to this topic? It's been a while since the last update. Is it still under consideration to be supported one day? |
@tbgse we have a new release candidate of the build plugin that it worth trying |
It seems that next-on-netlify current does not support incremental SSG (https://nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration).
Are there any plans to support this?
The text was updated successfully, but these errors were encountered: