RFC: next export back from the dead (or straight to the grave?)

[eric-burel]

Describe the problem you want to solve or enhancement you want to bring
next export is incompatible with all the cool features of Next.
We've been able to keep it around, but for how long? The day might come where we might need to kill this feature...

Define relevant concepts

• next export build your app as a static app => no server at all.
• This is necessary to host on static hosts like Github Pages or Amazon S3.
• Many features of Next rely on the presence of Next node.js server under the hood, like i18n routing, the Image component etc.
• getServerSideProps is not compatible with next export*
• getInitialProps in _app is a way to bypass the getServerSideProps limitation, and keep next export. This hack is however counter productive as you lose Automatic Static Optimization: your pages are not built as HTML but as JS, it means a slower rendering. Thanks @clement-faure for pointing this out
• Dynamic routes, like /my-dashboards/[dashboardId] are not correctly routed after a next export if you don't use getStaticPaths or if you use the callback. That's because they create a [dashboardId].html page, but the url will be /my-dashboarsds/1234 => pointing to 1234.html which doesn't exist. To solve this, you need URL rewriting using a reverse proxy like NGINX. I haven't seen any open source project doing that.

The main blocker is i18n: it requires a server to send the right text or to redirect the user based on the language headers.

Describe your solution

1) Best of both worls: next export even in full-stack apps relying on Next server-based feature

For all those features, you need:

• a client-side fallback. For instance if a page is using getServerSideProps, warn the user that they should also fetch the data client-side if not present, because getServerSideProps would be ignored. For i18n routing, you need to redirect client-side for example. Or to inject the translations on the fly.
• A way to easily setup a reverse proxy or a gateway. You still need a "minimal" server for URL rewriting to support dynamic routes + redirecting

2) Keep next export around

This mostly means not introducing getServerSideProps. This would work as long as we make i18n an opt-in feature. Like we could provide all the code, but comment the part that does a getServerSideProps for example. Or let people set it up based on Next.js documentation.
This seems to be Blitz.js choice at the time of writing.

Questions to the community

• We trade a Node server to a gateway: does it make sense?
• Is it really worth the hassle? We could also propose a version of Vulcan Next with just the development tooling like Jest and friends and drop "next export" in Vulcan Next itself.
• Vulcan Next is full-stack, so we could accept to drop next export.