Nuxt.js: Incremental Builds + Regeneration for Static Site Generation

[AlexFromJraft]

With Gatsby and Next now releasing public betas for incremental build/regen features, I was wondering if there were any plans in Nuxt to also support this?

Feature Request: Incremental Static Regeneration

Problem:
Every time a static site rebuilds, this results in some downtime

Solution:
Mechanism to update existing pages by re-rendering them in background as traffic comes in/ensuring that the newly built page is pushed only after it's done generating

——————

Feature Request: Incremental Builds

Problem
When Nuxt generates a large static site (e.g. 20,000 pages), rebuilds utilise significant amounts of time/resources

Solution
Whenever a data change is made, Nuxt only rebuilds what's necessary resulting in faster build speeds.

——————

Both these features are going to be a crucial component of static site generation in future. What are the communities thoughts on these features, and are there currently any plans internally from the Nuxt team to implement them?

[Spreizu]

I've actually implemented this type of system with a simple local database (lokijs) that holds the hashes of the pages payload object. During static generation we then hash each routes payload and compare it with the value in the local database. If it matches, then the route is removed. If not, then the page is kept in the routes list and the hash is pushed into the database.

This solution, however, requires you to specify the minimal amount of payload to each route, that change only if the actual content has changed. Meaning, it can't contain API request timestamps etc., as these will always end up as a different hash.
Also, this solution does not work, if you don't specify payload to each route. There may me other ways to get the pages data of course.

Additionally, you need to make sure that the nuxt static version directory does not change with incremental builds. My solution to this is to pass an argument to "incremental generation" call and if it gets detected, then the current static version is used.

Also, my solution does not remove deleted pages. For this, we actually regenerate the whole site at night.

This solution, combined with nuxt-generate-cluster, is pretty fast for large static sites.

[Atinux]

Actually this is more "Incremental Static Generation" than Incremental Build since this is not related to Webpack at all.

We are aware of this hybrid approach and are working on it directly for Nuxt 3.

Gatsby and Next has two different approach.

Gatsby is using GraphQL in order to detect in which page what data is mapped to be able to re-generated the pages linked to a specific data.

Next.js is mostly doing a caching layer on top of server-side rendering + the ability to pre-render these pages when running next build. But you still need a server behind to pre-render the pages that are not cached yet.