Comments (44)
hello all! for those who haven't seen: today netlify announced our first step towards solving the problems ISR/ISG originally set out to solve.
https://www.netlify.com/blog/2021/04/14/faster-builds-for-large-sites-on-netlify-with-on-demand-builders-now-in-early-access/
https://www.netlify.com/blog/2021/04/14/distributed-persistent-rendering-a-new-jamstack-approach-for-faster-builds/
what i can offer you today is a tagged release of our plugin:
npm install --save @netlify/plugin-nextjs@experimental-odb
right now, all this does for "ISR" support is use on-demand builders for getStaticProps pages with fallback: true
or fallback: blocking
. that means that any path not prerendered for these static pages will be built once, on demand, and then cached. in the future, we will offer something to accommodate the revalidate
property and its intended behavior - without compromising the jamstack philosophy. as always, i will keep everyone updated!!!
let me know if you have any questions!
from next-runtime.
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: incremental-static-regeneration
. It looks like it's working well β but I would like to refactor some code before I merge it into master. So it may be another week before it ships.
Again, thank you for raising this issue and for your very helpful proposal! π
- Finn
from next-runtime.
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.
from next-runtime.
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.
from next-runtime.
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?
from next-runtime.
@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.
Still curious why then would you want to support both if you could alternatively just forward developers on to using SSR?
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!!! :)
from next-runtime.
Can you please elaborate to what extent there is support?
Is there for example only support for the unstable_revalidate
(https://github.com/cassidoo/sonnet-18/blob/f3f21bcb3b27bbfbdcac73c8798eb4c951ded06a/pages/compare/%5B...slug%5D.js#L48)?
In my test revalidate: 1
did not generate a serverless function.
from next-runtime.
from next-runtime.
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.
@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.
from next-runtime.
@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. :)
from next-runtime.
@raaims hey! we're considering 2 different options in the near-ish future for this issue. one depends on a delayed internal release, one would be allowing plugin users to turn off preview mode and thus disable functions for getStaticProps pages. because of the first option, we've kindof been playing the waiting game when it comes to solving this issue for the handful of users that have communicated it to us. that said, this issue is unfortunately not really the right place to discuss it; if you want to open a separate issue asking for a solution for the getStaticProps functions stuff, please do!!!! <3
from next-runtime.
@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: revalidate
- there is something we have in the works that would address the same problem revalidate
is specifically trying to solve but can't really say when that's coming or what it is quite yet. as always, hang tight~!!!
from next-runtime.
updated title to help better direct incoming users looking for ISR stuff :)
from next-runtime.
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.
from next-runtime.
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:
{"errorMessage":"2020-10-21T14:05:48.488Z 604afa24-2c41-46d8-840e-a925c1e03587 Task timed out after 10.01 seconds"}
@FinnWoelm @cassidoo any clues ?
from next-runtime.
Hi, here is how I have solved this issue for now until this feature is implemented:
- Removed all the
revalidate
options (or have set it to false) - Using react-querys
initialData
with props set from thegetStaticProps
. This query fetches the updated data from the CMS. - CI setup with a cron to create a new build with desired interval, which then updates the initial data.
Example:
const Page: NextPage = ({ initialData }) => {
const { data } = useQuery('page',
() => fetchData(),
{
initialData,
},
);
return <div>{data.value}</div>
};
export const getStaticProps: GetStaticProps = async () => {
const data = await fetchData();
return {
props: {
initialData: data,
},
};
};
export default Page;
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.
from next-runtime.
This package actually does support it, to an extent!
Here's a demo:
https://sonnet-18-incremental.netlify.app/
You can use these URLs in the box there for the demo:
https://github.com/cassidoo/next-netlify-starter
https://github.com/netlify/next-on-netlify
Here's the code for it:
https://github.com/cassidoo/sonnet-18/blob/static-props/pages/compare/%5B...slug%5D.js
Do you have any other questions related to this?
from next-runtime.
I created netlify/next-on-netlify#37 to explore the option of adding incremental static regeneration.
from next-runtime.
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?
from next-runtime.
@cassidoo I think Netlify stale-while-revalidate support is needed to fully support ISR.
from next-runtime.
@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.
from next-runtime.
Is it possible that you use some sort of third party library that keeps a connection open?
Possibly! Will dig a bit deeper π
from next-runtime.
Okay, sounds good! Quick test would be to add a super simple page without any import
s and seeing if that works.
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
};
}
from next-runtime.
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?
from next-runtime.
@joostmeijles If I'm understanding this correctly, ISR is now actually just SSR under the hood when hosted on Netlify.
I think it begs the question then, why would I choose to use ISR?
Would it not just be simpler to use SSR?
I would love to know the technical details here, what it means for end-user performance and how Netlify is working under the hood.
from next-runtime.
@joostmeijles If I'm understanding this correctly, ISR is now actually just SSR under the hood when hosted on Netlify.
I think it begs the question then, why would I choose to use ISR?
Would it not just be simpler to use SSR?
I would love to know the technical details here, what it means for end-user performance and how Netlify is working under the hood.
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.
from next-runtime.
Thanks @joostmeijles! That makes sense.
Current Netlify-ISR state:
So it sounds like Netlify-ISR is also then still a blocking call?
Still curious why then would you want to support both if you could alternatively just forward developers on to using SSR?
Intended/Normal ISR State
A co-worker and I are really trying to wrap our head around the intended mechanics of ISR and how its supposed to actually work? (Say, assuming someone deploys to Vercel)
How does the browser, the cache, and the function work together to update the users stale page? Is it long-polling or something? Or is it only each subsequent request that gets the fresh update?
from next-runtime.
Howdy, I had a question about three lines that log out when building:
π₯ Copying pre-rendered pages with getStaticProps and JSON data to out
π« Setting up pages with getStaticProps and fallback: true as Netlify Functions in netlify/functions
π« Setting up pages with getStaticProps and revalidation interval as Netlify Functions in netlify/functions
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.
from next-runtime.
@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 out
(aka your publish dir) is specifically talking about copying prerendred html to your publish dir. unfortunately, for preview mode, we also have to generate a function for every getStaticProps page. we may consider adding some sort of configurable option to disable preview mode; this wouldn't be the first time someone's given feedback about the additional bloat of our preview mode support.
also: i think i need the whole link to the deploy logs (including the site name) to see them π€
from next-runtime.
Hi @lindsaylevine,
We're having the exact same problem. We haven't implemented previews yet but our getStaticProps
pages are being bundled into functions. Let me know if you need additional information (and where should I send you the info).
Thanks in advance π
from next-runtime.
@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 revalidate
property πΌ
from next-runtime.
Hi all,
As a workaround I think it's possible to achieve incremental SSG by combining this plugin (setting fallback: true
or blocking
) with useSwr
.
from next-runtime.
Is there way I can trigger the on-demand builder to "rebuild" a particular page?
from next-runtime.
@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:
- trigger a new deploy using a Build Hook if your content changes daily
- not cache your SSR response at all if your content changes hourly or more often
nevertheless we are very interested in hearing about your usecase and how we can solve it better in the future.
would you mind sharing with us what you're trying to achieve and why the options i lined out might not work well for you?
from next-runtime.
@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
from next-runtime.
@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.
from next-runtime.
how would you handle data changes that affect more than one page?
e.g. you change the title of a post and a bunch of your category overviews or taxonomy pages need to change?
from next-runtime.
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.
from next-runtime.
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?
do you have means to detect this situation inside your stack?
what kind of insights into cached pages would be useful to have on the netlify side?
from next-runtime.
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.
from next-runtime.
Is there a timeline as to when this will be completed?
from next-runtime.
what kind of insights into cached pages would be useful to have on the netlify side?
@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!
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.
Agreed! Watch the pending NextJS feature: programmatically purging routes
There's been a lot of discussion here about programmatically purging routes that have been generated with ISR. We're happy to share we're actively working on this now π We've spent the time since this feature launched evaluating options and have come up with a solution we think you'll love.
leerob on 23 Apr
from next-runtime.
The issue not persist in vercel, Netlify support team please share your updates, when the netlify users can expect full support of ISR.
from next-runtime.
@tbgse we have a new release candidate of the build plugin that it worth trying
from next-runtime.
Related Issues (20)
- [Bug]: `Runtime.ImportModuleError - Error: Cannot find module 'follow-redirects'` when deploying with netlify-cli and pnpm HOT 5
- [Bug]: `Error: Cannot find module 'next/dist/server/future/route-modules/pages/vendored/contexts/amp-context'` in NextJS preview mode HOT 38
- [Bug]: Cannot find module 'styled-jsx/style' HOT 7
- [Bug]: Middleware rewrites cause `TypeError: Invalid URL` when pointing to a directory in `public` HOT 2
- [Bug]: Middleware rewrites cause infinite redirect loop when pointing to a directory in `public` HOT 1
- [bug]: `netlify dev` fails to run middleware
- Cache headers returned from Middleware aren't respected HOT 7
- [Bug]: next.config.js > redirects is not respected HOT 7
- [Bug]: NextJS server page query param is not an array as expected HOT 1
- [Bug]: Error: Cannot find module 'next/dist/server/future/route-modules/pages/vendored/contexts/router-context' HOT 3
- [Bug]: ISR and next/link Prefetch Cause RSC Page Return Content in self.__next_f.push Function With App Dir on Next.js 14.0.3 HOT 2
- Failure toinstall[Bug]: HOT 2
- [Bug]: React Context not persisting across client side page transitions. App router. HOT 3
- [Bug]: Server actions not working with static rendering on Netlify
- [Bug]: API Routes return 502 due to Headers reference error HOT 1
- [Bug]: @netlify/plugin-nextjs is messing up everything HOT 2
- [Bug]: ENOENT internal error with monorepo setup HOT 7
- [Bug]: Plugin "@netlify/plugin-nextjs" internal error: ENOENT: no such file or directory with runtime 5.0.0-beta.7 HOT 9
- [Bug]: Issue with data revalidation after new build HOT 3
- [Bug]: NETLIFY_NEXT_PLUGIN_SKIP no longer works in v5 HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from next-runtime.