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

[karlhorky]

Goals

1. Compatibility / Performance: Allow for using common Node.js APIs in Middleware (eg. fs, net and tls to perform database queries without fetch overhead)
2. Symmetry: Avoid bug reports / confusion that experimental.runtime = 'nodejs' does not work for Middleware

Basically to allow for checking this last box at the bottom right (thanks for the idea for the diagram @thescientist13)

	Pages	APIs	Middleware
Edge Runtime	✅	✅	✅
Node.js Runtime	✅	✅	❌

Non-Goals

1. Achieve same performance and architectural simplicity as Edge runtime Middleware

Use Cases

Redirect logged out users

Middleware for multiple protected app routes to:

1. Read sessionToken cookie
2. Query PostgreSQL for valid session (without fetch overhead) 👈 currently not possible without overhead
3. If session expired:
   1. Return Set-Cookie header to delete invalid sessionToken cookie
   2. Redirect to /login

It is point 2 "Query PostgreSQL..." that is currently not possible without overhead. Let's examine the overhead:

With edge runtime

1. Usage of Middleware
2. Usage of fetch required, with HTTP overhead
3. Manual handling of cookie forwarding to Route Handler
4. Usage of environment variables for API_BASE_URL
5. Creation and maintenance of an API route / Route Handler (eg. /api/users/current)
6. Increased API surface (potentially relevant for security concerns)
7. Usage of a database query function

.env.*	middleware.ts	app/api/users/current/route.ts	database/users.ts
API_BASE_URL=http://localhost:3000	import { NextResponse } from 'next/server'; import type { NextRequest } from 'next/server'; export default async function middleware(request: NextRequest) { const userResponse = await fetch(`${process.env.API_BASE_URL}/users/current`, { method: 'GET', headers: { // Forward cookie to Route Handler cookie: request.headers.cookie, }, }); if (!('user' in userResponse)) { return new NextResponse(null, { status: 307, headers: { 'Set-Cookie': 'sessionToken=; Max-Age=-1; Path=/', location: `/login?returnTo=${request.nextUrl.pathname}`, }, }); } return NextResponse.next(); }	import { cookies } from 'next/headers'; import { NextResponse } from 'next/server'; import { getUserBySessionToken } from '../../../database/users'; export async function GET() { const cookieStore = cookies(); const token = cookieStore.get('sessionToken'); const user = await getUserBySessionToken(token.value); if (!user) return NextResponse.json({ error: 'user not found' }); return NextResponse.json(user); }	export const getUserBySessionToken = cache(async (token: string) => { const [user] = await sql< { id: number; username: string }[] >` SELECT users.id, users.username FROM users INNER JOIN sessions ON ( sessions.token = ${token} AND sessions.user_id = users.id AND sessions.expiry_timestamp > now() ) `; return user; });

With nodejs runtime

1. Usage of Middleware
2. Usage of a database query function

middleware.ts

database/users.ts

import { NextResponse } from 'next/server'; import type { NextRequest } from 'next/server'; import { getUserBySessionToken } from './database/users'; export default async function middleware(request: NextRequest) { const user = await getUserBySessionToken(request.cookies.token); if (!user) { return new NextResponse(null, { status: 307, headers: { 'Set-Cookie': 'sessionToken=; Max-Age=-1; Path=/', location: `/login?returnTo=${request.nextUrl.pathname}`, }, }); } return NextResponse.next(); }

export const getUserBySessionToken = cache(async (token: string) => { const [user] = await sql< { id: number; username: string }[] >` SELECT users.id, users.username FROM users INNER JOIN sessions ON ( sessions.token = ${token} AND sessions.user_id = users.id AND sessions.expiry_timestamp > now() ) `; return user; });

Background

Examples of confusion

• RFC: Switchable Next.js Runtime #34179 (comment)
• RFC: Switchable Next.js Runtime #34179 (comment)
• RFC: Switchable Next.js Runtime #34179 (reply in thread)

Proposal

Middlewares should have a flag experimental.runtime (similar to the RFC posted by @shuding ), which can also be set to the value 'nodejs'

[AndrewIngram]

I've been wanting the same for a while. My reading of the situation is that the problem is one of two worlds:

1. Those running Next.js in a similar vein to a normal web server, with the whole thing running in one process
2. Those using Vercel-like solutions, where different parts of a request can be handle by different runtimes all over the world.

For those running Next in the first way, which is usually me for most projects at work, it feels pointless to have middleware be restricted to only supporting the edge runtime. Plenty of things which would logically want to be there, like managing rewrites for A/B testing, are handicapped because most 3rd parties are only providing Node SDKs for this kind of thing.

For those running Next in the second way, limiting middleware to the edge runtime conceptually makes a lot of sense, because otherwise people are being handed a performance footgun.

I'd be happy with edge as the default, and maybe a warning (suppressible) if you switch it to Node.

[libinglong]

For those running Next in the second way, limiting middleware to the edge runtime conceptually makes a lot of sense, because otherwise people are being handed a performance footgun.

I do not understand this comment. Why there will be a performance footgun?

[stefanosandes]

For those running Next in the second way, limiting middleware to the edge runtime conceptually makes a lot of sense, because otherwise people are being handed a performance footgun.

Now imagine all technology we use as developers is linked to prevent "performance footgun." There will be only one programming language with two or three methods. This can be a Vercel concern as a solution provider, but in the end, it needs to be an engineering decision respecting every single use case.

[arackaf]

I'm trying desperately to do anything at all with RSCs at work, but can do nothing until Middleware can "run" in Node. And I put "run" in scare quotes since this is a self-hosted app, and middleware is already running in Node.

[karlhorky]

Workaround (PostgreSQL using Vercel Postgres / Neon Database)

For PostgreSQL, it looks like some new packages for the upcoming Vercel Postgres service are enabling database communication in the Vercel Edge Runtime using a WebSocket-to-TCP proxy (Cloudflare blog post):

• @neondatabase/serverless (underlying dependency behind following packages) (demo repo)
• @vercel/postgres
• @vercel/postgres-kysely (ORM)

It does come with some caveats:

A note on edge environments

In edge environments, IO connections cannot be reused between requests. To allow your Pools to continue to function, we set maxUses to 1 when running on the edge (otherwise the Pool might hold on to a Client used in one request and try to use it again in another). Unfortunately, this means the Pool also can't reuse the connection within the request. For this reason, if you're firing more than one database query to serve a single request in your app, we recommend obtaining a Client from Pool.connect, using that Client to query the database, and then releasing it.

[thescientist13]

@leerob
Would it be possible to get a position on this from Vercel just so folks can know where this sits on the Next.js roadmap, if it is on there, or ever will? Between this thread and a number of the post release replies in the original Switchable Runtime RFC, I think a lot of people were confused by the outcome that left this particular scenario unaccounted for, and could really benefit from knowing what the future of Node + Middleware is to Next.js.

Thanks! ✌️

[karlhorky]

Alternative: Improve Node.js API support for more Capable Edge Runtimes

Some non-Vercel platforms and edge runtimes mentioned below support more capabilities / APIs from Node.js.

This may provide a path forward for the industry - fewer limitations on edge runtimes. More capable edge runtimes may be able to solve most of the issues that people have with edge runtimes.

This may offer an alternative for Next.js Middleware - to instead add more Node.js capabilities to edge runtime environments.

Deno Deploy supports Node.js builtins at the edge

Deno Deploy supports Node.js builtins as of 26 May 2023:

all Node.js built-in modules like fs, path, and http can be imported and used on Deno Deploy.

This means: you can now run Node.js programs at the edge

Source:

• Tweet: https://twitter.com/deno_land/status/1662100754105094144
• Blog post: https://deno.com/blog/node-builtins-on-deploy

Cloudflare Workers TCP connect() to any database

Cloudflare recently announced that its edge runtime environments on Cloudflare workers will support TCP connections natively 🙌

• Announcing connect() — a new API for creating TCP sockets from Cloudflare Workers (Cloudflare blog)
• pg support for TCP connect() on Cloudflare Workers
• porsager/postgres support for TCP connect() on Cloudflare Workers - this client (Postgres.js) is similar to Vercel Postgres in that it supports SQL in tagged template strings

So running on edge environments on Cloudflare Workers will not be as limited as the current Next.js edge runtime environments are.

Edit (9 July 2023): @javivelasco confirmed that increasing Node.js compatibility will be at least one of the ways forward here: https://twitter.com/javivelasco/status/1677996931987980288

[karlhorky]

Update on Cloudflare's connect()

@Ethan-Arrowood from Vercel has started to collaborate with Cloudflare on a WinterCG specification for connect():

• Tweet: https://twitter.com/arrowoodtech/status/1707401024368152650
• Cloudflare blog post: https://blog.cloudflare.com/socket-api-works-javascript-runtimes-wintercg-polyfill-connect/
• Reference Node.js implementation: https://github.com/Ethan-Arrowood/socket
• Spec: https://sockets-api.proposal.wintercg.org/

So maybe this means that a future Next.js Edge Runtime would also support TCP connections via this new API? And when database clients ship any required connect() compatibility layers (eg. the Cloudflare compatibility work done in Postgres.js (2nd PR)), then this will "just work" out of the box.

Sounds like pretty far in the future (years?) but could be a path forward

CCs

• @leerob if you could confirm the general idea here and maybe also show non-working pseudocode for how it will look, would be amazing
• maybe @javivelasco was also involved here

[simon-robertson-shift]

I encountered this problem today while attempting to use the MongoDB driver within the middleware. It has taken a while to work out what the actual problem is. I think there might be a workaround within the top-level layout module for my specific use-case but it's an unexpected and disappointing problem to run into while using Next.

Being able to switch the runtime used by the middleware would be very much appreciated 👍

[hohogpb]

really need this request! hope soon come

[esja3224]

Ran into the same issue while trying to connect to Redis to implement an authentication flow. Our team uses middleware for a cleaner and logical code flow rather than for performance benefits.

Being able to run middleware on the centralized server using the Node runtime would make using middleware much more viable for our use case. Would really appreciate if this feature could be added to the roadmap!

[gerardnico]

Thanks for this discussion. I was really confused.

Same here. I try to authenticate a request (implementation of the authenticate function of the doc) and can't because the node crypto is unavailable.

What is really strange is that it works on route handlers (api route), which I use for OAuth authentication.

[axelvaindal]

As per this twitter discussion: https://twitter.com/AxelVaindal/status/1676581063638786048
I've upvoted this, as firebase-admin is currently not working in middleware.

The use case is the following:

• When the user logs in, we generate a session cookie to authenticate him server side (thanks to createSessionCookie).
• This cookie is passed along any request made to the server, and can be found in the middleware (using req.cookies.get).
• It cannot be decoded because firebase-admin relies on crypto and os, which are not supported in edge runtime.

Unfortunately, Firebase team is not considering supporting edge anytime soon, and I feel Firebase is big enough provider we should make sure to provide at least enough guidance to folks using it in production with Next.js (ideally without third party packages).
See: firebase/firebase-admin-node#1801 (comment)

A simple way to opt-out of Edge if we are self hosted, as @arackaf suggested, would be enough for us, as our middleware already runs in Node.js anyway.

[theDanielJLewis]

I'm guessing the primary workaround for this, then, is to move crypto-necessary tasks (and the like) into each router handler, right?

[hohogpb]

yes, same thought with you, after a while, i use fetch to do auth instead of directlly use prisma function in middleware, change the prisma part code from middleware to api,
i have create a template project and a demo，https://github.com/hohogpb/next-prisma-auth-starter demo : https://next-prisma-auth-starter.vercel.app/

[mscottford]

I stumbled across this problem while attempting to work with the upcoming v5 of next-auth. I initially configured the NextAuth provider to use the mongodb-adapter for session storage. That resulted in an error about the Edge runtime not supporting the stream module. It took me forever to figure out that the middleware.ts file was the cause of the issue.

The pull request for next-auth v5 references some documentation that is in progress. It uses a technique that's similar to what you suggest above. The database adapter is only added to the auth configuration when it's accessed outside of the middleware. This requires using jwt for storing the session, and it also limits the middleware to just checking the data that's stored in the JWT.

A full example that takes this approach is available. Note that the middleware.ts file imports auth.config while the rest of the files in the application import auth. The auth.ts file imports auth.config and extends the configuration to add the database provider.

I would have much preferred to just set config.runtime to nodejs in middleware.ts.

I hope that this information helps someone else who runs into this issue. I've lost a lot of time trying to figure it out, and I'm still not sure what approach I'm going to take. I suspect that I just won't use any middleware for authentication for this project.

[andycansdale]

Still no word from Vercel on this? Is it on their roadmap? It's very frustrating for those of us that will be self-hosting on AWS and other solutions that are not Vercel to have middleware limited to Edge runtimes. As someone above mentioned, it really does feel a bit like vendor lock-in on the part of Vercel. It's hard to know without some kind of response from the team.

In our case we want to use openid-client for checking and refreshing access tokens from httpOnly cookies. Middleware is the obvious place to do this, but it would seem that the only current solution is to query an API route from our middleware.

I really hope they add an experimental flag that allows us to select the runtime for middleware.

[raflymln]

please make this happens, it's really crucial for some applications that really need to use other than edge-runtime-provided module like bcrypt in their middleware, i hope nextjs team would read this

[leerob]

We're continuing to evaluate the constraint for Middleware using the Edge Runtime and exploring ways to bridge the gap towards allowing folks to experimentally/"dangerously" opt-into using the Node.js Runtime.

I appreciate the feedback here, but let's assume good intent and not make broad generalizations. Let me add a bit more clarity here.

Plenty of things which would logically want to be there, like managing rewrites for A/B testing, are handicapped because most 3rd parties are only providing Node SDKs for this kind of thing.

We agree. While the Edge Runtime has good constraints, for code that should run potentially in front of every request in your application, those constraints also have the tradeoff of smaller compatibility with existing ecosystem libraries. While there's been a lot of progress here in the past few years since we added Middleware, there's still libraries (as well as internal packages) that do not (or will not) support running with the Edge Runtime. We hear you.

Limiting middleware to the edge runtime conceptually makes a lot of sense, because otherwise people are being handed a performance footgun.

To further underscore this, it is a key design constraint of Middleware today.

Increasing Node.js compatibility will be at least one of the ways forward here.

Correct, since this discussion was opened, Next.js Edge Runtime now supports:

• AsyncLocalStorage: Support for maintaining data for an invocation between different asynchronous execution contexts, which allows you to pass state to the context even when the function is hot and module context is preserved.
• EventEmitter: A flexibleAPI to build event-driven systems that serves as a core building block for communication between libraries that control I/O and listeners that process data when events occur.
• Buffer: The most common way of handling binary data in Node.js, available globally or importable from buffer.
• assert: A set of assertion functions to validate invariants and logical rules that are very useful to explicitly test assumptions in your code path that need to run in Edge Functions.
• util.promisify and util.callbackify: A helper function to convert a callback-style function signature into one that returns a Promise, and a helper function to convert a function that returns a Promise into one that accepts a callback.
• util.types: A set of functions to validate that objects are of a given type.

---

It's also worth mentioning that another path forward here today is using Server Components with the App Router. You can add async logic, like handling authentication, in the root layout which applies to all routes. This is similar to Middleware in some cases. Further, you can add that logic in a nested layout, or a route group, only applying the logic to a specific set of routes.

[harishy100]

There needs to be clear examples of where edge runtime is falling short and where node would improve the situation in the documentation.

[MartinDavi]

@leerob What's going on behind the scenes with this discussion? There are enough people with real use cases asking for an update since your last one three months ago.

[brandensilva]

It is hard to feel like good intent is the goal when operability for Node is so easily dismissed when many of us have a path forward to improving our codebases with middleware given the standard node ecosystem as a whole.

In fact I wouldn't be surprised if most of us don't have edge problems on the regular as much as we have compatibility problems integrating with node. It's nice to throw the shiny toy around of performance at the edge but that is to be expected as much as node compatibility is to be expected with both on equal footing.

[MrLoh]

App router layouts are really not a replacement for middleware because they do not expose the request URL which is needed all the time. These limitations are really annoying. With RSC next.js is so much of a server framework now, and having normal middleware is a pretty standard requirement.

[iqbal125]

Is it recommended to handle protecting auth routes in layout component?

[michal-th]

I was waiting for some time if this gets addressed as I needed to access Vault for some session encryption keys, which couldn't be done in Edge runtime. But since i had to move on with the project, i reverted to a workaround - posting it here as it might help someone:

I'm on v14.x , using app directory, so i refactored all of the route handlers to use access wrappers:

// pageAccess.ts

export type RouteHandlerContext = { params: {[key: string]:string }, userId: number, someExtraData: ExtraDataModel }

export function withAccess(fn: any) {
    return async function (request: Request, context: RouteHandlerContext) {
        const res = NextResponse.next();
        const session = await getIronSession(request, res, ironOptions);
       // add any custom logic
        if (!Object.keys(session).length) {
            return forceLogoutResponse()
        } else {
            context.userId = Number(session.userId);
            return await fn(request, context);
        }
    }
}

export function withElevatedAccess(fn: any) {
    return async function (request: Request, context: RouteHandlerContext) {
        const wrappedFn = withAccess(async (request: Request, context: RouteHandlerContext) => {
             // add any custom logic
            context.someExtraData = await getExtraData();
            return await fn(request, context);
        })
        return await wrappedFn(request, context)
    }
}

I refactored all my routes (hundreds in my case..) as follows:

// route.ts

export const GET = withAccess(
    async (req: Request, { userId }: RouteHandlerContext) => {
       // ...handler code
    })

export const POST = withElevatedAccess(
    async (req: Request, { userId, someExtraData }: RouteHandlerContext) => {
       // ...handler code
    })

This allowed me to move anything i was doing in middleware to move into the wrapper, with extra bonus of getting more granularity on access control (i have multiple levels, and the logic handled in middleware was growing)

For the UI part i used very similar approach, using a PageWrapper component for all the pages (luckily i had this in place from the beginning since i am injecting i18n messages and some other props):

// PageWrapper.tsx

export default async function PageWrapper({ children, headerTitle, messages }: Props) {
    // do your stuff
   await doCommonChecks();

   return (
        <NextIntlClientProviderWrapper  messages={{ ...messages  }}  >
              <SubHeader title={headerTitle}/>
               <div className="container">
                   {children}
               </div>
        </NextIntlClientProviderWrapper>
    );
}

and finally, all the page.tsx files use the wrapper:

// page.tsx

export default function SomePage() {
    const messages = useMessages();

    return (
        <PageWrapper headerTitle="SomePage.___header_title" messages={{
            SomePage: messages?.SomePage as AbstractIntlMessages
        }}>
            <SomePageContent/>
        </PageWrapper>
    )
}

[yiminghe]

try https://github.com/yiminghe/next-compose-middlewares

[3nvi]

The one solution I'm currently using is to:

• define a route handler and add all the logic that requires a NodeJS runtime in there
• have middleware.ts make a fetch call to the route handler's URL (forwarding cookies, certain headers, etc.)

This fetch call can happen using a local call via http://localhost/api/my/route/handler (since you're calling an endpoint on the same machine) and avoid going through the internet, thus bypassing any DNS resolution & SSL handshake costs. The additional latency added by the fetch call (rather than executing code directly in the middleware) was 0-1ms for me.

I know it's not ideal, but at least it's something

[mrroll]

This won't work if you're hosting in Vercel-like environments, right? It should work everywhere else though.

[3nvi]

unsure, since we host it in a Docker instance. My guess is that it should work though since the default runtime for a route handler is a nodeJS runtime.

I doubt they'd phrase it like that if it was not valid for Vercel

[Poweranimal]

@3nvi How do you secure the route handler not being called from the internet?

[emmgfx]

@3nvi How do you secure the route handler not being called from the internet?

You can use a secret. Defined in the env, sent in the middleware and checked in the route, no?

[rickitan]

Fuck it. I already have a express server infront of my Next.js App.

So I just did the middleware at the express level and I love it.

[jakeleventhal]

using a server for serverless functions, nice

[clayrisser]

@rickitan when I try putting an express server infront of a Next.js app, the websocket breaks for hot reloading in development. How do you get around this?

[rickitan]

Hey @clayrisser I'm not having that problem.

My package.json has a dev command:

NODE_ENV=development TZ=UTC node server.js

On my server.js file:

const express = require("express")
const next = require("next")
const dev = process.env.NODE_ENV !== "production"
const app = next({ dev })
const handle = app.getRequestHandler()

app.prepare().then(() => {
  const server = express()
  server.all("*", (req, res) => {
      return handle(req, res)
  })
  server.listen(port, () => {
        console.log(`> Ready on http://localhost:${port}`)
  })
})

Hope that helps!

P.S I'm in pages router and have no plan in migrating anytime soon. So I don't know if it's broke for app router.

[petercunha]

Fuck it, I'm switching to Express. I just want to roll a self hosted server. Is that so much to ask? Do we really need to be locked into edge functions? This thread has been open over a year and yet no update from the Vercel team.

I am trying to use Next.js middleware + Prisma to validate user sessions. But apparently this requires edge functions + Prisma Accelerate (both of which cost money). There is NO way to self host when using middleware. What kind of f**ked up design choice is that? Self hosting prohibited? Give me a break.

I'm not too keen on the idea of building a proxy server just to handle middleware. So I'm leaving. Bye Bye Nextjs.

[emmgfx]

Nothing to say, @leerob ?

[hrithiqball]

@petercunha will you share your repository to us because im trying to self hosted too due to static image serve issue with nextjs and edge function. for your reference this is the setup. repo. i shouldve picked normal react with express in the first place 🥲🥲

[iMerica]

If anyone is interested in collaborating on a fork of Next.js that is more open and not vendor locked, feel free to submit PRs to unlocked-next/unlocked-next.js (totally new, no changes yet).

Goals:

• Open, vendor-agnostic and feature complete in any Node.js server environment (especially middleware!).
• Disables telemetry by default (or rip out the feature entirely).
• Drop-in replacement that mirrors release versions of upstream. No change in imports required.
• Keep the scope strictly about making Next.js open, neutral and flexible. Nothing else.

Forking and decentralization is how open source moves forward.

[gaetansenn]

Or just use Nuxt 🚀

[kodobrody]

I wanted to do a simple thing: After user sign in (next-auth v5) if his profile is not complete, then just always redirect him to /finalize, and I can't due to moongose not working on edge and unability to disable edge for middleware. That sucks :/

[XEngine]

I don't want this to go stale, so bumping.

[bilalmohib]

Dont know why they dont understand they just ignore user requests

[johncalvinroberts]

Relevant tweet from @leerob describing how/why vercel chose to move all rendering for their own next.js app to Node.js runtime instead of edge for performance and ecosystem reasons: link

Basically backpedalling a bunch of value props used to shill edge runtime due to reasons that have been obvious to everyone in this thread for over a year now!

[XEngine]

I laughed so hard when read this. I am glad that they eventually realize

[Sayan4444]

Is this fixed now? Can I use libraries without edge support in the middleware?

[hrithiqball]

https://github.com/vercel/next.js/releases/tag/v14.2.2
there is new release but i dont think its fixed yet

[karlhorky]

Update from X/Twitter

@leerob voices support for "route level middleware", which would run in the render process - from my understanding, this would be a non-edge runtime environment:

@lfre: Support middleware running within the render process instead of a separate context with limited runtime.

@leerob: Agree. What we really need is route level middleware as well as edge level middleware.

Source: https://twitter.com/leeerob/status/1780716511797088359

[mrroll]

Finally! Hopefully it translates into letting us use Node.js as the runtime for Middleware soon.

[benjick]

Anything new from Lee on this? I don't have twitter

[mrroll]

I haven't heard anything, no.

[Arctomachine]

While I support addition of route level middleware because it might be something interesting and useful, I propose improvement of existing middleware.
Simply add switch as it is done in routes: export const runtime = 'node'.
Since it already works for rendering (any route can switch to edge runtime), then implementation of this logic is already in codebase. What left is only to apply it to middleware as well.

[kodobrody]

Aaaaaand Next 15 does NOT change this, GREAT JOB

[gaetansenn]

This is why I love NuxtJS

[emmgfx]

Next 15 doesn't have been released yet. Keep calm, anything could change in 15 or even in another minor release.

[hohogpb]

hahahaha~

[mamlzy]

Next 15 doesn't have been released yet. Keep calm, anything could change in 15 or even in another minor release.

i think next 15 will be stable after react 19 stable

[kodobrody]

Next 15 doesn't have been released yet. Keep calm, anything could change in 15 or even in another minor release.

It's only RC due to React 19 being RC. So no, this won't change, however would love to be wrong

[clayrisser]

It's clear the nextjs team is focused on their ecosystem and isn't interested in integrations outside of it. I'm probably going to switch to vite over concerns regarding the future of nextjs. This is what happens when VCs control the direction of a project instead of developers controlling the direction.

[emmgfx]

It's clear the nextjs team is focused on their ecosystem and isn't interested in integrations outside of it. I'm probably going to switch to vite over concerns regarding the future of nextjs. This is what happens when VCs control the direction of a project instead of developers controlling the direction.

Are you aware that @leerob mentioned that Edge could not always be the best option and they're iterating to a full Node support?

They had a mistake, it's obvious, but I don't think that it's an ecosystem issue, since you can always use it on your own server without a different behavior than Vercel ones.

[clayrisser]

Well, there's a lot more than simply this issue that concerns me. For example, the recent focus on the RSC app router leaves developers worried that the page router will be deprecated, abandoned or at best an afterthought.

Vike and Vinxi look promising.

https://vike.dev/nextjs

https://github.com/nksaraf/vinxi

[emmgfx]

Sorry @clayrisser , but RSC it's a React thing. Next is one of the first one framework that supports them (e.g, Gatsby has his implementation in beta right now). Why do you think that app router was made for an ecosystem reason? I'm using it on my own server, nothing related to Vercel 🤷‍♂️.

[cupofjoakim]

@emmgfx @clayrisser This discussion is going well beyond the topic here. Can we keep discussions to the switchable runtime in the middleware instead of pros/cons with next over all?

[clayrisser]

No problem. Looking forward to this.

[devajakamerus]

You can always edit the webpack plugin file that has a whitelist for allowed node libs (events, buffer etc ). If running on node, of course they will work just fine.

The changes to make this configurable officially are so minimal that it's hard to understand all this.

[benjick]

Could you post how? I've seen similar comments like yours but never any follow-ups on how to actually do it

[devajakamerus]

Well I don't recommend it but if you really want here's a quick and dirty way.

go to node_modules\next\dist\server\web\sandbox\context.js

Look for NativeModuleMap, check the libs that are there already and add yours. For example:

const _nodefs = /*#__PURE__*/ _interop_require_default(require("node:fs")); // added
const NativeModuleMap = (()=>{
    const mods = {
        "node:fs": _nodefs.default, // added
        
        "node:buffer": (0, _pick.pick)(_nodebuffer.default, [
            "constants",
            "kMaxLength",
            "kStringMaxLength",
            "Buffer",
            "SlowBuffer"
        ]),

Then in node_modules\next\dist\build\webpack\plugins\middleware-plugin.js find SUPPORTED_NATIVE_MODULES and add the library name to list. You may need to do the same for any dependent libraries like node:net as well.

Then if you create a silly middleware just to test, it should work fine with dev and npm run start

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

import {promises} from "fs";

export async function middleware(request: NextRequest) {

  const data =await promises.readFile('./test.txt', { encoding: 'utf8', flag: 'r' }); 
  const response = NextResponse.next()
  response.headers.set('test', data)
  return response
}