Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It _can_ prerender all of those combinations. Here is a directory I made with 1000+ pages, prerendered and hosted for free on netlify: https://www.givepuppylove.com/organizations/ . I've found that single digit thousands is about the maximum you can currently have and keep build times reasonable.

If you want to recognize the user's location and display the appropriate currency or language, you would probably want to wrap content dependent on location in a "ClientOnly" type component. So it would not be prerendered in that case. Example code:

  export default function ClientOnly({ children, ...delegated }) {
    const [hasMounted, setHasMounted] = useState(false)
    useEffect(() => { setHasMounted(true) }, [])

    return hasMounted ? <div {...delegated}>{children}</div> : <div></div>
  }
This allows you to grab things off the "window" and change behavior based on that info, which you can't do with prerendering.


As far as count of pages Vercel has a limit of 16000 and Netlify technically has no limit (AFAIK), although the build times will cost you eventually. You can work around this limit in a lot of cases while keeping things prerendered by putting dynamic information in querystrings.


You're totally right. Apparently this on the Nextjs team's radar though:

>Up next, we will be working on a supplemental RFC to address two additional incremental static generation capabilities:

> - Re-generating and invalidating multiple pages at once (like your blog index and a certain blog post)

> - Re-generating by listening to events (like CMS webhooks), ahead of user traffic

Source: https://nextjs.org/blog/next-9-5#stable-incremental-static-r...

But yeah, if you have 10k pages it seems unavoidable to me that initial build time will be high. With `fallback: 'blocking` you could decide to build each page at runtime when it is requested for the first time – this spreads out initial build time.

What would be nice is being able to re-use compiled pages across builds. Imagine having 10k pages compiled, and you have to push out a new build that only updates 5 pages, or none at all (eg an API change). It would be nice if it could make use of the compiled pages from the previous build, only re-compiling the pages that needed it. Of course the devil is in the details, and figuring out which pages need to be re-compiled basically requires you re-building the pages.


Right, actually building all those pages at once necessarily takes time. But on Netlify, most of my build time isn't actually used doing `next build`, it's the un-logged-to-user file transfer to their server / CDN cache invalidation / whatever hosting magic they do after the static files are built.

So at least in my case, NextJS would have to create a way to not rebuild files that haven't changed, and then the hosting/CDN provider would also need to be able to see which files those are and respond accordingly. This all seems very doable eventually though.


What happens if there are millions of pages?

Wish Next.js would have a "scalability issues and solutions" documentation...


For each page, you can set `fallback: 'blocking'`. If set, the page is not built at compile time. Instead, it will be compiled the first time it's requested. So the first request will take longer, then after that it'll be fast.

Alternatively, on a per-page decision you could decide to use server side generation (page built at compile time) or server side rendering (page compiled when requested).

You have options that let you spread out the time, but ultimately it's going to take time to build millions of pages.


Like acoard said below, I think the recommendation there would be to use their hybrid cache / dynamic rendering option. You do lose a lot of the cool benefits of being fully static in that case though. In general, yes that kind of documentation would be very helpful.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: