[HN Gopher] Considerations for Incremental Static Regeneration i...
___________________________________________________________________
Considerations for Incremental Static Regeneration in Next.js
Author : rhymesey
Score : 25 points
Date : 2022-05-21 09:33 UTC (13 hours ago)
(HTM) web link (www.csrhymes.com)
(TXT) w3m dump (www.csrhymes.com)
| brtkdotse wrote:
| I sometimes feel like I'm taking crazy pills when it comes to web
| development. This literally the functionality WordPress + a
| caching plugin has been providing for 15+ years.
| klysm wrote:
| Yes you're right, but Next.js also provides many other modes of
| rendering content with a fairly consistent API.
| [deleted]
| leerob wrote:
| Many people are still using Next.js with WordPress, but they're
| using it "headless". The difference here is that static assets
| can be served globally (versus a monolithic WP single region
| server) and cache purges can happen globally in about 300ms.
| [deleted]
| [deleted]
| [deleted]
| TimMeade wrote:
| Very good points. I think most devs don't think in multiple
| servers. There should be built in considerations for most of
| these i hope Next themselves are considering this.
| SwiftyBug wrote:
| Until I read this post I didn't even know my Vercel apps ran in
| multiple servers. I have to go check some things out I guess.
| leerob wrote:
| By default, static pages and assets on Vercel are deployed to
| every region in our Edge Network. Happy to answer any other
| questions about Vercel!
| zoover2020 wrote:
| How does this work with a cache when deployed to Vercel?
| Does it imply multiple servers?
| leerob wrote:
| Vercel has built-in regional caching. When you use on-
| demand ISR to programatically invalidate the cache,
| purges propagate globally in about 300ms.
|
| https://on-demand-isr.vercel.app/
| SwiftyBug wrote:
| That's very cool! Can I have SSR pages be served from
| multiple regions as well? This would be very beneficial to
| my e-commerce as I have to SSR some hyper-customized
| product pages. I'm assuming that Vercel serves requests
| from the server that is closest to the user, is that
| correct? If one specific server starts receiving a lot of
| traffic, does Vercel forward requests that would otherwise
| go to that busy server to the next closest server?
| leerob wrote:
| You can customize which region you want your functions to
| run in that handle server-rendering. Currently running
| multi-region functions (lambdas) requires an enterprise
| plan, but using Edge Functions, they can be multi-region
| or global if you'd prefer. It depends on where your data
| is and if it's replicated.
|
| You are correct that Vercel serves requests from the
| region closest to the visitor. Our servers automatically
| scale (serverless) so it doesn't need to balance across
| regions. However, in an instance of downtime, Vercel
| would route traffic to the next nearest region.
| CosmicShadow wrote:
| I've definitely felt like I've had to come up with clever ways of
| making sure my pages are the latest, especially after a user
| edits their page and expects to see it instantly updated. I've
| also had to remove thousands of pages from static generation,
| only to be generated on first load or else Vercel times out on
| the build and you'll be banging your head on the wall trying to
| figure out what is going wrong as their logs don't tell you. The
| number of pages you can get away with is way lower than you think
| it should be. I haven't tried the new on-demand revalidation yet.
| colejohnson66 wrote:
| I have a website with over 13,000 pages generated at build time
| with no issues. It takes about 5-10 minutes. If you site is
| timing out at the 45 minute mark, I'd wager you're doing
| something wrong.
| leerob wrote:
| Hey, Lee from Vercel. How many pages were you trying to build
| when you hit the 45 minute limit? We've recently revamped our
| build and deploy infrastructure, which should help builds
| complete faster with many static pages.
|
| https://vercel.com/changelog/faster-builds-for-everyone
| tunesmith wrote:
| Just curious if there's any clear benefit to using ISR over
| setting up a CDN in front of your website, other than the page
| being regenerated in the background? Our website has Akamai in
| front, and we are pretty much all SSR/getServerSideProps. We've
| thought about diving into ISR a few times but so far it seems the
| marginal benefit might not be very high in our case. We currently
| have a practice of sending API calls to Akamai to invalidate
| cache entries when pages are updated.
| leerob wrote:
| If SSR + caching is already working well for you, you might not
| need ISR. And it likely also depends on the type of application
| you're building. For example, if you need user auth on every
| request, generating static assets probably won't work since
| they're not personalized.
|
| One difference with ISR is that it's durable, where your cache
| is not. You can persist the statically built pages to disk,
| like S3, and be able to roll back to old versions.
___________________________________________________________________
(page generated 2022-05-21 23:02 UTC)