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?

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

[amannn]

@feedthejim This sounds really exciting!

I found this sentence in your announcement interesting:

Then, you could pass data to the rendering phase.

Could you elaborate on this? Would that data be passed as a prop to a route handler, or would it be available deeply within all components that render as part of the route?

I'm interested in this in relation to #58862, mostly to be able to make a locale deeply available for the i18n use case. Not having to use a middleware at all to read route params would be even better, but that would already help quite a bit. I guess something to consider are implications for static/dynamic rendering, since a middleware can still run for routes that have been statically rendered (and could therefore not consume params that are passed from a middleware, at least not if they depend on anything other than the request pathname).

As a side note: Has there been a discussion about being able to create a matcher that is dynamically created and not statically analyzable? That'd be on my middleware wishlist too.

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

[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].

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

[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

[khuezy]

@clayrisser you mind keeping us updated on your experience w/ onestack? I think we can all agree no software is perfect and I'm curious what headaches you'll experience over there.

[jelmd]

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.

...

Well, as already pointed out above, such "out of reality"/"theoretical"/simple examples do not work, because "proper" authorize() implementations need to access a DB and/or node:crypto stuff. So it does not really matter, how much splitting is done, finally nextjs flaps into your face ...

[petersahanaya]

even on new Next Js 15, we still don't have option for that, sad but i think they made it so we are locking into vercel :(

[petersahanaya]

here is my work around for now, i will using a route groups with layout.tsx on each route groups. because i was using drizzle orm with mysql2 i cannot used it on the middleware because there's no 'net' module on the edge runtime.

app
  └── (protected)
      └── layout.tsx

layout.tsx

import { auth } from "@/auth"
import { jakartaSans } from "@/lib/utils"
import { Children } from "@/types"
import { redirect } from "next/navigation"

const ProtectedLayout = async ({ children }: Children) => {
  const session = await auth()

  if (!session) redirect("/sign-in")

  return (
    <html lang="en">
      <body className={jakartaSans.className}>
        {children}
      </body>
    </html>
  )
}

export default ProtectedLayout

and if you want to get the current URL like req.nextUrl on middleware, we can use import { headers } from next/headers to get current url.

import { auth } from "@/auth"
import { jakartaSans } from "@/lib/utils"
import { Children } from "@/types"
import { headers } from "next/headers"
import { redirect } from "next/navigation"

const AuthLayout = async ({ children }: Children) => {
  const currentPath = new URL(headers().get("referer") || '').pathname

  console.log("CURRENT PATH : ", currentPath)

//TODO: do something some logic based on the current path.

  return (
    <html lang="en">
      <body className={jakartaSans.className}>
        {children}
      </body>
    </html>
  )
}

export default AuthLayout

This is what i do for now, for authenticate user using Auth.js and sorry if there's something wrong, my english is not really good heheh :)

[petersahanaya]

but this still have some issue you can get Invalid URL, due user privacy settings so i don't recommend doing this, to check the URL on layout.tsx

[khuezy]

I think there was a security issue someone noted in this or another thread that said NOT to do auth in layout because you can bypass auth.

[LFCavalcanti]

This is one of the issues that points to Next.JS being administered to favor Vercel's product, instead of being a React Framework, the fact that this is open since March 2023, and even before that people were questioning the removal of route based middleware(like express does) and forcing the Edge runtime.
I'm here, setting up Auth, being forced to setup a separate API to validate session because I can't query PostgreSQL from the Middleware.
One could say this also forces people to choose Cloud native products.

[karlhorky]

Update (Request Interceptors)

@unstubbable has a PR open for an experimental feature called Request Interceptors, which address some of the concerns in this discussion:

• Introduce experimental Request Interceptors #70961

If you have looked for anything brought up in this discussion, would be good to look at Request Interceptors to see if this helps your situation at all.

Request Interceptors are a limited design, and Node.js Middleware is also in planning.

[karlhorky]

Update (Node.js Middleware also in development)

As @feedthejim mentions below, aside from Request Interceptors mentioned above, the Next.js team is also working on planning for Node.js Middleware too:

The design [for Request Interceptors] is intentionally limited because this is not a replacement for the Edge Middleware.

What is not explicitly said in this PR is that we're also working on planning to add support for the Node.js Middleware to unlock some of the DX issues you may have been encountering.

• Introduce experimental Request Interceptors #70961

[LFCavalcanti]

I'm sorry to say... and I already commented in the PR, but these interceptors don't cover all needs.

Not blocking the initial communication is a security concern and the fact that in the PR states you handle Cookies in Middleware when the current Middleware does not handle Cookies is a tell tale that there is a river without a bridge on this issue.

[khuezy]

No need to be sorry bro, that issue is addressed in the Caveats section. Just be patient for the full middleware runtime PR.

[karlhorky]

@LFCavalcanti thanks for writing your feedback in the other issue!

One tip - I understand the frustration with the long time this is taking, but if you are a bit more diplomatic about your message, then I think it will help to get an answer.

Eg. it may be more effective to remove the last bit of your last paragraph after the ...:

I would really appreciate if someone from the core team could directly address why we still don't have an option to execute the middleware with the Node standard runtime... Next.JS is supposed to be a React Framework not a Vercel Serverless Infrastructre only Framework.

(this also applies to everyone else posting the theories about Vercel doing this for reasons of trying to lock users into the platform - probably this won't be in any way constructive, and will actually shift attention away from getting things moving in a way that you want)

Also, are you actually interested in the reason for it? (probably it's something deep in the Middleware design that needs to be restructured in a smart way, which takes time)

Or are you maybe looking for a general overall timing when it is coming? (probably also hard for the team to estimate, since it's still in early planning phases)

[LFCavalcanti]

@LFCavalcanti thanks for writing your feedback in the other issue!

One tip - I understand the frustration with the long time this is taking, but if you are a bit more diplomatic about your message, then I think it will help to get an answer.

The frustration doesn't come from not having the functionally per se, but from the overall attitude around the "opinionated" choices of the Framework, I'm a little(more like a lot) tired of seeing people being dismissive or down right pedantic when use cases where "Serverless" is not the preferred solution are brought up. And I understand, the whole business model of Vercel is built around offering a good product to deploy web applications with serverless infra, but that's not the solution for every problem.

Eg. it may be more effective to remove the last bit of your last paragraph after the ...:

Yes, that bit was written too aggressively, I'll tone it down, but the question over how they steers things is valid, just because they don't like the question doesn't mean people shouldn't ask.

I would really appreciate if someone from the core team could directly address why we still don't have an option to execute the middleware with the Node standard runtime... Next.JS is supposed to be a React Framework not a Vercel Serverless Infrastructre only Framework.

(this also applies to everyone else posting the theories about Vercel doing this for reasons of trying to lock users into the platform - probably this won't be in any way constructive, and will actually shift attention away from getting things moving in a way that you want)

As I said above and enough people have been posing these issues that the question is a valid concern to be addressed, they don't have to answer in the PR, maybe address it in another media, like a blog post or YouTube Video.

Also, are you actually interested in the reason for it? (probably it's something deep in the Middleware design that needs to be restructured in a smart way, which takes time)

Yes I am... Is the reason technical concerning the Framework itself or compatibility/security with serverless operation?(not only Vercel, also using Lambda directly with something like SST).

Or are you maybe looking for a general overall timing when it is coming? (probably also hard for the team to estimate, since it's still in early planning phases)

I already solved the problem using the header manipulation with the NextResponse, but the documentation around that is not good and the concept seems counter intuitive to me... sendind a set cookie header in a response from the Middleware to the Route being called and that header will be sent to the client with the route's response.

[devajakamerus]

The frustration comes from the fact that providing an opt-in solution would be simple, just get rid of sandboxing and run mw on node. Yeah it breaks compability but we're adults and making such decisions is part of the job.

I'd assume most things people would use mw for are agnostic to the framework. Logging, auth checks, db calls etc. with no effect to the actual request handling. Could be done in a proxy but setting another server just to run a function feels pretty silly.

Also simpler execution model would improve middleware performance.

[jburghardt]

I share the frustration many in here feel, especially when it comes to auth and securing routes with middleware.
As some have already mentioned, for those of us who self-host the edge runtime often is not important. A workaround for now is to put put node specific logic into route handlers and calling fetch from the middleware, but this does not feel like a good solution.

Something i havent read here is the possibility of starting nextjs with a custom server. The docs provide a guide
on how to spin it up. note: docs not available for v14, which is odd?

https://nextjs.org/docs/canary/app/building-your-application/configuring/custom-server

if you use the standalone output mode, you can overwrite it with your custom one.

app.prepare().then(() => {
  const server = createServer((req, res) => {
    const parsedUrl = parse(req.url!, true);

    if (parsedUrl.pathname === "/secure") {
      // check if session from req.cookies is in redis - or any middleware
      res.writeHead(302, { location: "/test" });
      res.end();
    }

    handle(req, res, parsedUrl);
  });

  server.listen(port);
  console.log(`listening at http://localhost:${port}`);
});

As mentioned in the docs: this also comes with some caveats and is also just a workaround.

[flexdinesh]

Please let us run node apis in middleware. Locking the middleware behind edge runtime doesn't make sense for self-hosting. I'm seeing a lot of positive changes in the framework in the last few months for users who are self-hosting. Please please please let us toggle the runtime in the middleware to run node apis. In one of my projects I just need to query redis in the same datacenter in the middleware for redirect decisions. It is a super high-traffic web app, and I'm now forced to build a route handler and invoke it in the middleware to get the result, which is terrible for TTFB because of having to make a network request in the middleware.

Please at least give an experimental flag to run node apis in the middleware.

[leerob]

We are working on allowing using the Node.js runtime for Middleware, and it will be included in an upcoming Next.js release. We appreciate your feedback and patience on this issue.

We are also exploring a potential new API, called Request Interceptors, that would address some of the feedback here for supporting nested, file-system based middleware. If this is something you are interested in, please comment on the proposal.

To prevent additional GitHub notifications and emails, we have a new discussion where you can opt-into notifications as progress is made.

Thank you 🙏