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.

[kaminskypavel]

@mscottford you the real MVP.

[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?

[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
}

[liuhuapiaoyuan]

This is too awesome, but if nextjs locks middleware to promote its own cloud services, I feel a bit disgusted

[devajakamerus]

This is too awesome, but if nextjs locks middleware to promote its own cloud services, I feel a bit disgusted

Well I can see they have a point for maintaining consistent behaviour across runtimes but if I choose to use Node and write code that only works on Node, it's my decision and responsibility.

And there are Node based serverless platforms as well..

[XEngine]

If all pages or other things can have switcable runtime, middlewares should also include it. This is vendor locking and I agree with the @liuhuapiaoyuan

[Neo-Ciber94]

Algo making the current middleware implementation more modular would be great.

Currently combining middlewares is hard, not sure why the convension: (req, res, next) or (req, next) => res, was ignored, have been proved that it works.

[liuhuapiaoyuan]

Why there is no any follow-up information from the official , is really hard to understand!

[caoimhebyrne]

This is pretty much the only thing blocking my application, and it's quite frustrating to see that nothing has happened since the discussion has been started.

All I need to do is be able to refresh my session cookie (if needed) in server components, and middleware is the standard for that, since server components can't set cookies.

I can't use middleware properly, because the edge runtime does not support libraries which use node:sockets (basically any postgres library), so I'm unable to query my database in the middleware to retrieve information about the session / issue a new session to the user if required.

Using an API route in the middleware is just extremely counter-productive, and leaves a massive code-smell. If Next.js really cared about developer experience, I would've thought this would be resolved a lot sooner.

[BB-19]

As a workaround, you can use an API route + useSWR (with refreshInterval) to keep the session alive. At least that is what I am doing for now..

[caoimhebyrne]

Eh, that's not a solution I'm happy with for now, but yeah there are workarounds, there shouldn't need to be one though

[feedthejim]

Hi all, I just wanted to share a quick update that we're looking at this particular problem and will share more about it later as we start iterating on it.

[hohogpb]

can't wait

[gerrysaporito]

Much needed!

[liuhuapiaoyuan]

Oh, has any news?

[feedthejim]

No news yet, I'm hoping that we can share more in a proposal in a few weeks but I can't promise it

[mattszein]

Please, take in mind that we need this fix in current Nextjs version (14). Could be adding it in a minor update version.

[devajakamerus]

So we ended up replacing the whole nextjs middleware call in sandbox.js with a plain function. That means any update has to be checked first but it was actually so simple to do that it shouldnt be an issue. Also patched out the waitUntil promises since we dont need it. Our middleware is basically equivalent to example below, I don't think others are needing much more complex stuff either. Read cookies, redirect, set headers etc. normal things.
async function customMiddleware(request) { if ( db check etc here ) { return NextResponse.redirect(new URL('/redirecturl', request.url)); } const headers = new Headers; headers.set("x-middleware-next", "1"); return new NextResponse(null, { headers });

After all middleware function are very simple. In our case it's only to decide whether redirect or pass. At this rate it seems writing our node middleware sandbox is the easiest solution. Which only needs to be a thin wrapper to satisfy the response types the framework expects.

[Arctomachine]

How do you make this function run on every request without actual middleware?

[davimdantas]

Did you patch Next.js package to replace the middleware?

[khuezy]

Look at his comment down below.

[feedthejim]

As a quick update, as someone shared in this thread, we've been exploring route-level middleware. The significant design constraint is how this fits with partial pre-rendering and streaming.

An example of a pattern that would emerge for example is:

1. you run some lightweight logic with the middleware at the edge, i.e., reading a cookie, a header, or some very fast DB call
2. after that, we'd send you a static PPR shell as fast as possible from the edge
3. then, you'd run some route-level logic with route middleware at the origin (where you're rendering), which would be the best place to do some data reading since your DB should be closer. Then, you could pass data to the rendering phase. The use case we're thinking about here is mostly auth.
4. then you'd do your regular rendering

This is the ideal scenario we have in mind for performance. Now, I assume this does not solve some of the concerns in this thread.

Please answer in the replies: 1) if that proposal sounds good to you and 2) if not, what blockers specifically have you encountered with the current middleware? what kind of logic are you running?

My understanding is there are a few buckets. I have a few questions for each of those.

1. edge runtime does not support some crucial APIs
   • what APIs do you need, and why?
2. I'm self-hosting so the location of the middleware is not that important to me
   • since location is not an issue, what you need is just a place to run top-level logic, right? or is there something in middleware that you couldn't run?
3. the API of middleware itself is too restrictive
   • what can we add to make it more flexible?

[darthmaim]

@feedthejim I hope with the addition of route level middleware it will be possible to detect prefetches at runtime. Right now its recommended to add this to your matcher for some use cases (for example CSP):

missing: [
  { type: 'header', key: 'next-router-prefetch' },
  { type: 'header', key: 'purpose', value: 'prefetch' },
],

But it is currently not possible to have a middleware that runs for both prefetches and normal requests (for example a rewrite), and some other middleware that doesn't run for prefetches (for example CSP), because those headers are already stripped out before the middleware actually runs.

[Pedromigacz]

Yes, I just need a place to run top level logic, I just need to refresh my cookies over there. I need to run code before the streaming start. I need to be able to set headers based on the request object.

[liuhuapiaoyuan]

Is there any progress? When can we experience the new middleware?

[0x00000000000000000000000]

@feedthejim the best case is edge runtime should capable in doing whatever node runtime could, right?

[nicolo-tito]

In my case, what I need is a place to run top-level telemetry logic that can't run in current edge middleware.
The trace exporter I'm using along @vercel/otel doesn't support the edge runtime so I need to:

export async function register() {
  if (process.env.NEXT_RUNTIME === 'nodejs') {
    const { AzureMonitorTraceExporter } = await import(
      '@azure/monitor-opentelemetry-exporter'
    )
    registerOTel({
      traceExporter: new AzureMonitorTraceExporter...

Because of this, the current middleware running in edge doesn't have access to the opentelemetry (node) active context, so I can't add info from the authentication session and export the tracing.
This would be solved by a middleware running in node (as long as it can be defined once at top-level).
(I didn't deep dive, but I guess that while @vercel/otel configure opentelemetry for the edge env as well, that woud result in different contexts/tracing, so it would be impossible to trace from a middleware running in the edge env using the node-only AzureMonitorTraceExporter).

[devajakamerus]

A somewhat straightforward solution would be to add config option like useNodeMiddleware and then during server startup just import fhe function from "middleware.node" or whatever the convention would be. Then instead of the next middleware just run it and continue with the result.

Looking at it the middleware result is just { response, waitUntil, fetchMetrics? } so whatever function works as long as the type matches. In our case the need is basically redirect/set cookie/pass, nothing fancy or messing around with RSC and other 3-letter abbreviations.

I was messing around with the server and just patched the middleware execution to run an imported function. Basically there is a "blank" middleware.ts with matcher but instead of executing that in the sandbox it's just a function call. Also I noted that on "next build" the regular middleware was 27kB so using a plain function should improve performance a lot. After all there's no need to any fancy bundling etc. since node can just import whats's necessary on startup.

Of course that's not a way to run production but I'd expect this to be easy to support officially. Another thing, I'm a bit concerned with global DB pooling and such, making sure the same pool is used everywhere after all the bundling etc.

[hrithiqball]

https://github.com/vercel/next.js/releases/tag/v14.2.7

new update! edge middleware upgrade! still cannot switch to node

[khuezy]

This release is backporting bug fixes. It does not include all pending features/changes on canary.

[Ennazk]

[khuezy]

They're literally working on it right now.

[Ennazk]

I'll believe it when I see it

[jelmd]

We always run our stuff on our servers and js stuff runs on nodejs and thus nodejs is always there. So this edge-runtime junkware limitations make no sense at all. All students tried to implement a simple app using Auth0/Prisma/MySQL to have a simple login/logout/register/app page (sessions) failed (having ~6 month for it). So obviously nextjs is everything else but simple and one needs to waste a lot of time to get even the usually simple things [not] fixed. Everything we saw so far suggests: reject any work/implementations, which requires/uses NextJS.

So NexTJS should really add a config option to tell it: your are running on a real server [in a NodeJS environment and not a very limited useless platform like vercel's].

[devajakamerus]

I think it's up to users to choose what they want to do in middleware. Running node often means db, redis, sqlite etc. is close so latency is not an issue. Many backends have heavy chains of middleware without problems, session checks every request etc. Also compared to pure js in a function, running a full react tree just to e.g. redirect user is worse.

[juan-carlos-correa]

In this guide it is explained how to split the auth.ts file so that you can access your session in the middleware while respecting the edge-only limitation.

IMO the middleware should be as small as possible as it gets executed on almost every requests, and enforcing it to use the edge runtime only can help on this - still I think it can be helpful to some having the ability to switch runitime, and I hope this will be implemented by Next very soon.

I really appreciate the guide, will give a shot. I prefer to have this option while the Next.js team is working on allowing Node.js environment in the middleware.

Anything else, a possible but messy way that I have found using Node.js related code is through API routes :v

Yes, making a temporal API route so in the middleware you call it... not ideally, specially because we are running BE anyway. But if you find a better approach while the Next.js and Auth.js teams are hardly working on this, please let me know.

[0x00000000000000000000000]

yep I agree it is increasing our development time to create our own workaround to avoid this issue, big L

[hrithiqball]

https://x.com/rauchg/status/1842054402288611671?s=46

ril or fecc

[clayrisser]

Switching to onestack because of this issue not getting resolved.

https://onestack.dev

[0x00000000000000000000000]

Is Next 15 going to make nextjs middleware compatible with all node libraries?

[khuezy]

For you @0x00000000000000000000000 , Next 16.

[0x00000000000000000000000]

is it true?