[⚡ Feature]: Supporting Next.js runtime Node.js

[lcswillems]

Description

I see Cloudflare supporting more and more Node.js modules.

Additional Information

No response

Would you like to help?

• [ ] Would you like to help implement this feature?

[dario-piotrowicz]

Hi @lcswillems 👋

Thanks for the issue 🙂, unfortunately I think that supporting the Node.js runtime is quite out of the question, mainly for two reasons:

• This adapter works by generating a worker using the Vercel CLI build command (vercel build) output, such output comprises of edge functions and (AWS) lambda functions, the adapter collects the code from the former to build the worker and discards the latter (when discarding the code doesn't generate a loss of functionality, if it does then the adapter's build process fails). The latter is code very AWS lambda specific and not something we can really use (unless we were to deploy it to AWS).
• The Cloudflare runtime does support more Node.js modules but not all of them (fs, path, os, etc...), I am not sure if and how we on next-on-pages could support those? should they be no-op? surely that would break in many many use case no? (PS: I have no idea if/how/when they could be included in the runtime either)

The only practical solution I can think that would address both issues above would be to, actually make @cloudflare/next-on-pages work with both runtimes, and for node runtimes have the lambda(s) deployed to AWS, although that would introduce many issues:

• we want the code only to run in a worker as that is what provides the best and fastest user experience, mixing this with lambdas, which often could be required to run before the worker code, could quite defeat the purpose here
• we'd have to find a way to connect the worker we produce with the AWS lambda(s) we get, making the whole application more complex and with more failure points. This would likely be quite awkward/cumbersome locally.
• we'd have to find a way to "version"/"keep in sync" the worker and the AWS lambda(s), which might be very tricky since the two would reside on different platforms.

Additionally (likely a personal opinion)... this project is called next-on-pages as it aims to allow running a Next.js applications on the Cloudflare Pages platform, so having it more generic and include AWS (or whatever else platform) seems out of scope to me and not something that this project was designed to do/created for.

Please let me know what you think of the above 🙂

If you have any potential solutions/ideas please also feel free to throw them my way 😄

[lcswillems]

Hi @dario-piotrowicz , what about just transforming the AWS lambda into workers? Doesn't seem too hard? And it would fail only if I use node modules not supported by Cloudflare.

[dario-piotrowicz]

@lcswillems as I mentioned above:

This adapter works by generating a worker using the Vercel CLI build command
(vercel build) output, such output comprises of edge functions and (AWS) lambda
functions, the adapter collects the code from the former to build the worker and
discards the latter (when discarding the code doesn't generate a loss of functionality,
if it does then the adapter's build process fails). The latter is code very AWS lambda
specific and not something we can really use (unless we were to deploy it to AWS).

The Vercel build generates complex lambdas which usually contain multiple routes bundled and grouped in an optimized way so that they grow as big as they can without reaching the AWS lambdas max side (50MB). So besides other things here, opposite to what we have with edge functions, there isn't even a 1-to-1 relationship between lambdas and routes.

It is as I said an AWS specific build, so pretty useless for us. I did look into it in depth a while back (looked wether we could infer any useful information/extract any useful code from the lambdas output I mean) which gives me confidence in saying that there, in my opinion, isn't really anything valuable from the lambdas that we could reuse 😕