Skipping static generation for pages using getStaticProps at build time

[abriginets]

Describe the feature you'd like to request

Could you please allow skipping static page generation at build time for pages using getStaticProps? Currently I have an index.tsx file for a page but I can't build it at CI because it doesn't have access to the data. Instead I would like to only build this page when there's an incoming request. getStaticProps is great because it introduces an additional caching layer to the application but forcing developers to generate such pages at build time feels more like a limitation. Currently this is not possible and I see the following error during the build:

> Build error occurred
Error: getStaticPaths can only be used with dynamic pages, not '/countries'.
Learn more: https://nextjs.org/docs/routing/dynamic-routes

Describe the solution you'd like

Additional config options is fine.

Describe alternatives you've considered

I can rename index.tsx to [index].tsx and run a check if page path is /page-name and return 404 if it's not. It's rather workaround than a solution.

[abriginets]

Or maybe it'd be better to have a --disable-static-generation flag for next build CLI command.

[JonasLeonhard]

So we've encountered a somewhat similar problem.

Our setup currently builds a CMS docker image as the backend, and a Next frontend image as seperated Gitlab-Ci Jobs and pushes them to our Gitlab container registry. The CMS docker image (craftcms/nginx) nginx configuration file contains the proxy_pass configuration to forward all requests towards the frontend container. Both containers are then deployed via Portainer.

By using proxy_pass in the backend container we can ensure that the frontend can only be reached when the backend CMS container is running.

The problem arises in the building process of the frontend image using getStaticProps and revalidate.
Since our pipeline builds both images at the same time, next builds (ISR) pages for every page, statically building 404pages for every page, because the updated backend is not available during our Gitlab pipeline since both Images get deployed the same time. After a deployment we would have to wait for 30 seconds to revalidate, even though the CMS is already running and data would be accessible now.

We think that by allowing getStaticProps at build time to be skipped, we would not have 30 seconds of "revalidate downtime".

Secondly a problem arises when we already have an existing instance of frontend and backend containers deployed and we redeploy both a new frontend and backend container with differing data or queries by pushing new images to the registry.
Now the frontend container would use the existing and deployed CMS container to build (ISR) pages in the Gitlab pipeline, therefore creating the same problem as described above. By redeploying both the new Cms backend and Next frontend container at the same time, we would have 30 seconds of "revalidate downtime" again. Because the frontend shows the data of the old backend container as it was statically build during next build while building the image.

[icyJoseph]

How about using getServerSideProps with cache control? As documented in the going to production docs:

// This value is considered fresh for ten seconds (s-maxage=10).
// If a request is repeated within the next 10 seconds, the previously
// cached value will still be fresh. If the request is repeated before 59 seconds,
// the cached value will be stale but still render (stale-while-revalidate=59).
//
// In the background, a revalidation request will be made to populate the cache
// with a fresh value. If you refresh the page, you will see the new value.
export async function getServerSideProps({ req, res }) {
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=10, stale-while-revalidate=59'
  )

  return {
    props: {},
  }
}

This would:

• Skip pre-rendering at build time
• Do render at runtime
• Keep the revalidate behaviour of getStaticProps, somewhat, by injecting cache-control

Am I, perhaps, missing something else?

[holmey]

I think the difference is: When using revalidate all visitors will see the same generated version of your site. When "just" sending Cache-Control headers these are valid for one specific visitor. All the other visitors would trigger server side rendering again and would not benefit from an already generated version.

[icyJoseph]

Right, you need to consider an additional caching layer to pull this off successfully, like CloudFront. That's what I had missed.

Note: Your deployment provider must support caching for dynamic responses. If you are self-hosting, you will need to add this logic yourself using a key/value store like Redis. If you are using Vercel, Edge Caching works without configuration.

It was right under the code snippet...

[holmey]

Thank you for the input. This is maybe a solution we should consider now.
But we really like the Incremental Static Regeneration that enables us to use static-generation on a per-page basis, without adding another service to the infrastructure.
And for dynamic routes it already seems to be a solution to just return an empty array in getStaticPaths(). So maybe I am just missing the functionality for static routes.

[leotuna]

Any updates?

[jackmcosta32]

Hi there, I had the same issue and came up with the following solution:

At build time I'm passing a new environment (BUILD), by doing the following:

BUILD=true yarn build

And on my page, I've set up a try/catch block with the following:

export const getStaticProps: GetStaticProps = async ({ preview }) => {
  try {
    ...
    
    return {
      props
    }
  } catch (error) {
    console.log(error)

    if (process.env.BUILD) {
      return {
        notFound: true,
        revalidate: true
      }
    }

    throw error
  }
}

It seems to be working fine