Abstract SSR & API Routes from Node.js

[davidbarratt]

Feature request

Using next for server-side rendering or API routes must be done in a Node.js runtime. This is because the next package is tightly bound to Node.js preventing using other runtimes like Deno, Electron or even the browser (which now has things like native filesystem support).

It would be helpful if the core functionalities of next were abstracted from Node.js. This would be similar to the way a database abstraction layer would work. Effectively next would have "adapters" (or something like that) for different runtimes. The default adapter (and the only one in core) would be a Node.js adapter, but other adapters could be created in userland.

The next app would receive its necessary dependencies from the adapter. For instance it might get the parsed URL and a list of routes with regexes and callback functions to call to get the component for that route. The adapter might also provide a callback to determine the proper _app.js and the like.

Having a clear and documented interface for what an adapter should look like (and obviously a Node.js example) would be really helpful as well. :)

Describe alternatives you've considered

1. Reimplementing all of next for a different environment seems like a ton of work. :(
2. Perhaps shimming the Node.js APIs for a different environment, but that's also a can of worms.

[frank-dspeed]

https://github.com/stealify/stealify/issues/63 i have also covered that topic that is the way to go!!

The Concept of Platform and Environment Agnostic ECMAScript / ES / Javascript

• never write code that only runs on a specific platform like node-graalvm node or the browser
• never write code that assumes an environment to have something
• write additional code that utils your existing code platform and environment-specific

we introduce 1 extra folders for thats environment

• holds platform indipendent code like fs, net, child_process, window)
• (holds code that uses the platform code on diffrent environments, macos, docker, windows, linux, ie6)

So we end up in 2 folders

• modules (Agnostic code)
• environment
  • ie6
  • node
    • linux
    • windows
  • deno

the code in modules should depend on one or more environment dependencies. via a uniq interface