The individual server bundling was an incremental path to implement this new runtime, over time it will become a lean wrapper on top of the actual component renderer. Then another bundle pass can combine these endpoints and add a router layer there. Another reason is to make it really lightweight and performant (size limitation and cold boot speed, differs on different platforms), so it's not ideal to concat all endpoints by default.

The individual server bundling was an incremental path to implement this new runtime, over time it will become a lean wrapper on top of the actual component renderer. Then another bundle pass can combine these endpoints and add a router layer there. Another reason is to make it really lightweight and performant (size limitation and cold boot speed, differs on different platforms), so it's not ideal to concat all endpoints by default.

Makes sense, curious to see where this goes!

Something similar like the custom server functionality but then for WinterCG compatible runtimes (which vercel is a part of) would be great, since each runtime / provider might have different ways to access environment variables / static assets / etc, then you can implement those yourself.

Let me know if you'd like to see / hear more of my findings.

Looks like Middleware still does not support runtime: nodejs (next: 13.1.1)

Any plans to add this?

We're looking to implement authentication in some routes, and to me, it would make sense to do this in the middleware. As we're running this in Node it doesn't seem possible (our 3rd party library makes use of Node functionality).

+1 to have Middleware support in the runtime and some indications if that is in the plans would be awesome.

+1 for this, not being able to use a full Node runtime in middleware blocks some legitimate use cases. Not being able to use Buffer.from for instance limits the ability to decode JSON Web Tokens, which I'd like to be able to do for various reasons. My workaround for now is to use new Buffer, which is deprecated and won't be a viable solution forever. I may need to start offloading Node-dependent logic into API routes, which adds more complexity and unnecessary network requests.

Extending what the Edge runtime supports is probably counter to the reasons it was created in the first place, so being able to opt into forgoing the performance advantages and using Node instead would be nice to have.

Edit: I've realized that import { Buffer } from 'buffer' solves my particular issue. From what I read about Edge, I did not expect this to work. So my immediate pain is gone, but the general argument still stands.

Since this hasn't received a lot of attention here, I've created a new feature request discussion for improved visibility:

#46722

thank you @karlhorky ! 🙌

I've lost a couple of hours researching too, because of this. Would love to see nodejs runtime in middlewares.

Indeed, I would have liked to get a gcp secret, but it appears even that is unsupported due to the gcp client library using Node event apis not supported on edge. 😁

For self-hosters it does indeed make sense to allow those to use different runtimes, it feels like a bit of a Vercel lock-in at the moment. It would be great if we could solve this 🙂

You can use https://nextjs.org/docs/messages/edge-dynamic-code-evaluation unstable_allowDynamic to solve this issue. Export the config from your middleware file.

@lukebrandonfarrell can you expand on how you suggest using this?

It seems like this flag is just about using eval(), new Function(), WebAssembly.compile and WebAssembly.instantiate.

It seems like it does not relate to usage of Node.js APIs, which is what @arackaf is asking for above (and also what #46722 is proposing)

@karlhorky Of course, so yesterday I was experiencing an error when running next build:

info - Creating an optimized production build 
Failed to compile.
./node_modules/graphql/error/GraphQLError.mjs
Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile') not allowed in Edge Runtime 
Learn More: https://nextjs.org/docs/messages/edge-dynamic-code-evaluation
Import trace for requested module:
./node_modules/graphql/error/GraphQLError.mjs
./node_modules/graphql/error/index.mjs
./node_modules/graphql/index.mjs
./node_modules/@apollo/client/core/LocalState.js
./node_modules/@apollo/client/core/ApolloClient.js
./node_modules/@apollo/client/core/index.js
./node_modules/@apollo/client/index.js
./src/utils/check-user-onboarding-status/check-user-onboarding-status.ts

This was due to creating a middleware in our application and using check-user-onboarding-status.ts (an internal util) which used @apollo, which uses graphql which apparently uses Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile').

Since we don't run on Vercel, but we run on AWS this wasn't a problem, so to bypass these build issues, we exported config from middleware:

export const config = {
 runtime: 'nodejs', // for Edge API Routes only
 unstable_allowDynamic: [
 '/src/utils/check-user-onboarding-status/check-user-onboarding-status.ts',
 '/node_modules/graphql/**',
 ],
};

Maybe this doesn't solve your specific issue, but I wanted to share what problem we were running into, how we can to this thread, and what solved it for us.

Hope that makes sense :)

@emmgfx this discussion (from Feb 2022) is about a switchable runtime for pages and API Routes - NOT about Node.js support in Middleware.

What you are looking for is Node.js runtime support for Middleware, which has been discussed here:

• Node.js runtime support for Next.js Middleware #71727
• Switchable Runtime for Middleware (Allow Node.js APIs in Middleware) #46722

Node.js middleware support has since landed in Next.js canary versions:

• Add nodejs runtime support for middleware #75624
• Node.js runtime support for Next.js Middleware #71727 (comment)

Also - Turbopack support is coming:

• Add node middleware handling for turbopack #76360

I see this doc now
https://nextjs.org/docs/app/building-your-application/routing/middleware#runtime

I guess middleware can be used with nodejs runtime.

What do you mean? I clearly see:

Middleware currently only supports the Edge runtime. The Node.js runtime can not be used.

Sorry I expressed very badly. I meant we can not use nodejs as runtime in middleware

Right, the Node.js runtime cannot be used with Middleware yet, I opened another discussion here for that:

• Switchable Runtime for Middleware (Allow Node.js APIs in Middleware) #46722

Update:

Node.js middleware support has landed in Next.js canary versions:

• Add nodejs runtime support for middleware #75624
• Node.js runtime support for Next.js Middleware #71727 (comment)

Turbopack support is coming:

• Add node middleware handling for turbopack #76360

This sounds awesome!

Agreed, disgusting and sad.

I just hit this error because... I used lodash 🤡

./src/domains/base-layers/adapter.ts
Dynamic Code Evaluation (e. g. 'eval', 'new Function', 'WebAssembly.compile') not allowed in Edge Runtime 
Learn More: https://nextjs.org/docs/messages/edge-dynamic-code-evaluation
The error was caused by importing 'lodash/isEmpty.js' in './src/domains/base-layers/adapter.ts'.

For frontend only development this framework is ok, especially if you opt for the new and shiny rendering options like streaming, however since recently I started to develop an API with it, since the entire team has the most experience in this framework, and I must say it was a mistake. Unless you like to invent a wheel all over again, go for smth mature and opinionated. Next will just make you frustrated big time.

Anyone has experience with the newly improved dev server in next 15, did they get the job done this time? (I always cry, when I compare it's performance to anything that runs on Vite 😢 ) `

P.S. Next.js on dev containers is yet another level of "performance".

@paulschuetz this discussion (from Feb 2022) is about a switchable runtime for pages and API Routes - NOT about Node.js support in Middleware.

What you are looking for is Node.js runtime support for Middleware, which has been discussed here:

• Node.js runtime support for Next.js Middleware #71727
• Switchable Runtime for Middleware (Allow Node.js APIs in Middleware) #46722

Node.js middleware support has since landed in Next.js canary versions:

• Add nodejs runtime support for middleware #75624
• Node.js runtime support for Next.js Middleware #71727 (comment)

Also - Turbopack support is coming:

• Add node middleware handling for turbopack #76360

Hey Karl! Thank you very much for the information and I am super happy to see the nodejs runtime support for middleware 🌞

@nachomglz this discussion (from Feb 2022) is about a switchable runtime for pages and API Routes - NOT about Node.js support in Middleware.

What you are looking for is Node.js runtime support for Middleware, which has been discussed here:

• Node.js runtime support for Next.js Middleware #71727
• Switchable Runtime for Middleware (Allow Node.js APIs in Middleware) #46722

Node.js middleware support has since landed in Next.js canary versions:

• Add nodejs runtime support for middleware #75624
• Node.js runtime support for Next.js Middleware #71727 (comment)

Also - Turbopack support is coming:

• Add node middleware handling for turbopack #76360

@talatkuyuk this discussion (from Feb 2022) is about a switchable runtime for pages and API Routes - NOT about Node.js support in Middleware.

What you are looking for is Node.js runtime support for Middleware, which has been discussed here:

• Node.js runtime support for Next.js Middleware #71727
• Switchable Runtime for Middleware (Allow Node.js APIs in Middleware) #46722

Node.js middleware support has since landed in Next.js canary versions:

• Add nodejs runtime support for middleware #75624
• Node.js runtime support for Next.js Middleware #71727 (comment)

Also - Turbopack support is coming:

• Add node middleware handling for turbopack #76360

Thank you!