Ship sensible defaults for number of pages prerendered on build

[fiasco]

Build time will roughly equal the build time per page multiplied by the number pages to render. This will make build times quite long with large sets of data. So we should ship a reasonable default to keep build times within a reasonable timeframe.

1. what is a reasonable build time we should aim for?
2. what should we consider the average render time of a page to be?

Answer these questions should tell us how many pages we want to prerender in the build stage.

[lauriii]

#32 is already changing the default behavior for this. The proposed solution there is that by default, none of node pages are generated on build time. This makes sure that the default value shouldn't run into scalability issues with any number of nodes on build time. This also seems to make sense with the revalidation time we are using at the moment which is just 60 seconds.

We are planning to add wiki page to document how app developers could achieve generating static pages for nodes. In the end, it will be the app developers responsibility to decide how they want their app to be build and cached.

[fiasco]

I don't like that change. Its made building from paths more complicated. I would've prefered we kept getPathsFromContext as the return value and passed a limit of paths or some way of prioritising those paths and then set the limit to 0.

Though I don't think I agree that we should build zero pages on build time either. That seems like a sensible feature so that, at the very least, your most popular pages don't tank on a release.

Where did that decision get made?

[lauriii]

At the moment, most of this is due to #17. Because of that, we reduced the default revalidate time temporarily to 60 seconds to provide an experience more in par with sites already utilizing cache tags based cache invalidation.

Given that the revalidate time is just 60 seconds, it doesn't seem good use of resources to pre-build all of the paths on build time which within realistic parameters could easily take over 60 seconds.

Another argument in favor of removing this was that we wanted to create default experience that would be able to run on sites of any size. Many sites have thousands of nodes and this would essentially create builds that could take ages to run without much for them to gain with the current setup. For example, building 5000 nodes would take over 2h to build.

Its made building from paths more complicated.

I'm not sure I fully follow what's the complexity this is creating. I'm wondering if there's a specific example that you could give where you think the current setup is more complicated?

I would've prefered we kept getPathsFromContext as the return value and passed a limit of paths or some way of prioritising those paths and then set the limit to 0.

I agree that something like this would make a lot of sense! However, it's something that at the moment would be the responsibility of the developers implementing the app since it's hard for us to predict what is the logic they'd like to deploy here. We could totally simply limit the maximum number of the pages, but without some sort of prioritization, it would not make a lot of sense.

Where did that decision get made?

This was discussed on one of our team stand ups. On a hindsight, we should have opened an issue for this to at least document the rationale.

[lauriii]

Discussed this with @fiasco on Slack. We agreed that instead of simply turning this feature off for all sites, we should try to setup some steps that would allow small sites to continue benefit from this. We could for example check the total number of nodes, and based on that decide what to do.

An alternative idea proposed by @fiasco was to also setup some pre-defined prioritization of which pages would get generated on build for large sites. We could for example generate static versions of all pages that are linked from the main menu.