Redirection of Content through SSR/Middlewares

[ovflowd]

With the addition of #5396, we can finally have custom middleware that can be fired to handle different aspects of our website.

With the addition of #5397, we can have a single 404 (Not Found) page instead of one per pages/{languageCode}/404.md. This is useful for static generation since it uses Localization data now backed directly within the Application, instead of the old way where Localization data is injected into the App's individual pageProps. This creates some advantages, and it's a foundational step (together with the new middleware engine) that allows us to cover the functionality of this issue.

What is this issue about?

The Node.js Website is entirely static. We now support SSR and have some cool Server-Side features on the pipeline (such as search), but fundamentally, the pages are static.

This means that each page (which resides in each language folder) is a single unit. This is done since we want to support (for the long term) the website to fully operate on a static basis without requiring any server or server-side routing. Next.js's built-in i18n feature requires a single folder within pages (e.g. /pages/blog/index.md, /pages/index.md, /pages/about/something.md) instead of subfolder localised paths (e.g. /pages/en/blog/index.md, etc.)

The main issue is that Next.js built-in i18n routing could bring Translation Contexts and do the Routing for us. With #5397 and the current implementation, we pretty much have an in-house Localisation system. The main benefit of the current PR is that the Translation system is not static and bounded during build-time, which already brings benefits, such as for the 404 page.

The big blocker

In other words, our next big blocker is how we handle loading pages that do not exist in a specific language.

With #5397, loading Translation Context and Localized Messages is not an issue anymore, as the messages are eval'd during both build-time and runtime.

Yet, we have one big problem **How can we tell Next.js that once it encounters a 404 to attempt to load a page with a similar path (e.g.,/de/blog/something-something we want to extract /blog/something-something) and load the source page (English version) of it if exists?

• These should not be done/generated during build-time.
  • It's OK not to support these with static builds, but it's doable. We need to use getStaticPaths and getStaticProps

The technical hurdle

Next.js supports dynamic pages (even with Static Generation-only, aka "Static Dynamic Pages") (https://nextjs.org/docs/pages/building-your-application/routing/dynamic-routes, https://nextjs.org/docs/pages/building-your-application/data-fetching/get-static-paths)

This could allow us to do something like pages/[language]/[...path].tsx (or .mdx if we want to make it dynamic-static).

Until then, all good; we're able to dynamically handle pages, even tho if we use the static approach, we would need to make beforehand a complete list of all pages that each language does not have (a sort of a diff), which by itself seems like an over-engineered solution.

Then we have an even harder blocker: How do we load the English version of the page within an already computed page? (As far as I know, there's no way to do a dynamic import that loads pages with a dynamically constructed path from a prop).

Open to ideas

This is not necessarily a blocker for launching the nodejs.org website on Vercel (as the same functionality is not on the https://nodejs.org website right now, as it got removed once we moved from Handlebars/Metalsmith). Still, it is a critically important feature in the long-term run.

It'd be ideal if Next.js Middlewares had a way to know if the requested route exists or not and to be able to redirect to another page with an injected context (?) (cc @leerob @Ethan-Arrowood @shuding)

Or any other way that we could tell Next.js to load an alternative page... Well, @nodejs/website I'm open for suggestions :)

[ashutosh887]

@ovflowd I'm willing to contribute to node on this issue. Please assign me

[ovflowd]

@ashutosh887 this issue is a meta issue, so right now we're talking about an existing problem that has no way of being solved.

[ashutosh887]

Sure @ovflowd ... Thanks for the clarification