Support headers and cookies in getStaticPaths

[eric-burel]

Describe the feature you'd like to request

Hi, this ticket is a follow up on multi-tenancy discussions (#20841, #17260, https://blog.smallcase.com/scaling-microsite-with-next-js/) and more generic discussions I've opened about static rendering and ISR for personnalizaed and private content (#17631, https://blog.vulcanjs.org/lets-bring-the-jamstack-to-saas-introducing-rainbow-rendering-ad1834fe62ff). This is also tightly related to i18n routing, as it proposes an alternative not based on routes.

It seems to me that SSG and ISR could be made drastically more powerful by supporting cookies and headers parameters in addition to route parameters.

Pro:

• no more URL bloating. The foobar.com/en/my-page does not scale beyond i18n, and feels really weird in many contexts. There are already headers for that, being forced into using route params seems a regression.
• no more URL bloating, for real, that's an issue. Imagine having to support multi-tenancy, i18n, and a dark/light theme statically => you already have 3 route parameters...
• easy support of customized and private content by adding a proxy in front of Next that secure headers and cookies. You may use Next.js for paid, private, or customized content, without any limitation, as if it was just normal public generic content.
• it makes SSR almost obsolete, including for private and customized content, in accordance to Jamstack prerendering principle which is sadly mostly limited to public, non-customized content to this day.

Cons:

• increase the combination of possible paths (if you have 10 languages and 3 tenant, you need 30 paths). This feature would definitely work best alongside ISR, so that only critical paths are rendered (for instance, rendering only the main language for each tenant) and other are rendered only on demand.
  This is already an issue with SSG as is anyway, and Next.js has proven able to handle an infinite number of pages thanks to ISR.
• mostly risk of mistakes for the end user: forgetting to compute all possible combinations, relying on unsecured headers to protect private content (you need a server/gateway upfront in this scenario to guarantee that headers are valid), having no fallback for exotic values

Describe the solution you'd like

Example usage:

export async function getStaticPaths() {
  return {
    paths: [
      { params: { ... }, headers: { "Accept-Language": "french", cookies: {"current-tenant-id": "tenant-1" }
    ],
    // using fallback would probably be mandatory or at least strongly recommanded here, a
    // as you might always encounter unexpected values for headers, depending on the value you use. 
    // But it depends if you know possible values in advance or not, use cases may vary
    fallback: true or false
  };
}

This might not be the smartest approach but you get the point: somehow allowing user to rely on headers and cookies in this function.
This could be similar to the syntax used in redirects already, with has.

Describe alternatives you've considered

• Bloating the URL with zillions of URL parameters :(
• URL rewriting or similar approach, using servers like Nginx (requires skills I definitely don't have as a JS developers)
• Using SSR, with a cache. There is a kind of equivalence between ISR and using SSR + using a cache (I've even tried to prove it mathematically https://tinyurl.com/ssr-theory). But the problem is the same as using a solution like Nginx: the average JS developer is not aware of how to handle this.

In the end, SSR feels more complicated than it would be to learn using an extended version of getStaticPaths

[datner]

What a coincidence, I literally ran into that exact problem today. Saw this post and thought to myself that it was old and ignored.
what an absolute fool I was.

The big thing I would add, is that just like you said, theres an issue of exponential routes and therefore pages to render.
I think that along-side something like this, it's critical to provide a way to indicate what should be SSR'd and what can be delegated to the ISR later.

[eric-burel]

Hi, just so you know I've been iterating a lot on this pattern.
Currently the best approach is to use a middleware + URL rewrites. In the middleware, you can inject URL parameters based on header and cookies. This turns the URL in a cache key function of the request. This is indirect but works ok and gives you enough control.
It's maybe even better than those initial proposal, that require a complex declarative language to model which part of the request has to be considered or not.

I've detailed this pattern ("the Megaparam") here: https://blog.vulcanjs.org/render-anything-statically-with-next-js-and-the-megaparam-4039e66ffde and recently in Smashing Magazine: https://www.smashingmagazine.com/2022/07/new-pattern-jamstack-segmented-rendering/

I have a pending PR for a better demo: VulcanJS/vulcan-npm#131, I am waiting for a fix in Next to finish it: #38302

The incoming layout update will make it cleaner because you'll be able to have nested data fetching requirements (eg loading the right language top level while currently you need to set it up for each page)

[datner]

Great pieces! I had similar ideas, but not as complete as the megaparam implementation there, very elegant.'
The one thing I do get hanged up on is that it's systematically operational, but it's never a very clean pattern. It breaks conventions and requires meta information to debug / extends.

I wonder if theres a way to actually cement it in cleaner way 🤔