-
Goals
Basically to allow for checking this last box at the bottom right (thanks for the idea for the diagram @thescientist13)
Non-Goals
Use CasesRedirect logged out usersMiddleware for multiple protected app routes to:
It is point 2 "Query PostgreSQL..." that is currently not possible without overhead. Let's examine the overhead: With
|
.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
- Usage of Middleware
- 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'
Beta Was this translation helpful? Give feedback.
Replies: 94 comments 153 replies
-
|
I've been wanting the same for a while. My reading of the situation is that the problem is one of two worlds:
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. |
Beta Was this translation helpful? Give feedback.
-
I do not understand this comment. Why there will be a performance footgun? |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
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):
It does come with some caveats:
|
Beta Was this translation helpful? Give feedback.
-
|
@leerob Thanks! ✌️ |
Beta Was this translation helpful? Give feedback.
-
Alternative: Improve Node.js API support for more Capable Edge RuntimesSome 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 edgeDeno Deploy supports Node.js builtins as of 26 May 2023:
Source:
Cloudflare Workers TCP
|
Beta Was this translation helpful? Give feedback.
-
Update on Cloudflare's
|
Beta Was this translation helpful? Give feedback.
-
|
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 👍 |
Beta Was this translation helpful? Give feedback.
-
|
really need this request! hope soon come |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
As per this twitter discussion: https://twitter.com/AxelVaindal/status/1676581063638786048 The use case is the following:
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).
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. |
Beta Was this translation helpful? Give feedback.
-
|
I'm guessing the primary workaround for this, then, is to move crypto-necessary tasks (and the like) into each router handler, right? |
Beta Was this translation helpful? Give feedback.
-
|
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, |
Beta Was this translation helpful? Give feedback.
-
|
I stumbled across this problem while attempting to work with the upcoming v5 of next-auth. I initially configured the 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 A full example that takes this approach is available. Note that the I would have much preferred to just set 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. |
Beta Was this translation helpful? Give feedback.
-
|
@mscottford you the real MVP. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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.
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.
To further underscore this, it is a key design constraint of Middleware today.
Correct, since this discussion was opened, Next.js Edge Runtime now supports:
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. |
Beta Was this translation helpful? Give feedback.
-
|
There needs to be clear examples of where edge runtime is falling short and where node would improve the situation in the documentation. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Is it recommended to handle protecting auth routes in layout component? |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
can't wait |
Beta Was this translation helpful? Give feedback.
-
|
Much needed! |
Beta Was this translation helpful? Give feedback.
-
|
Oh, has any news? |
Beta Was this translation helpful? Give feedback.
-
|
No news yet, I'm hoping that we can share more in a proposal in a few weeks but I can't promise it |
Beta Was this translation helpful? Give feedback.
-
|
Please, take in mind that we need this fix in current Nextjs version (14). Could be adding it in a minor update version. |
Beta Was this translation helpful? Give feedback.
-
|
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. 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. |
Beta Was this translation helpful? Give feedback.
-
|
How do you make this function run on every request without actual middleware? |
Beta Was this translation helpful? Give feedback.
-
|
Did you patch Next.js package to replace the middleware? |
Beta Was this translation helpful? Give feedback.
-
|
Look at his comment down below. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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.
|
Beta Was this translation helpful? Give feedback.
-
|
@feedthejim This sounds really exciting! I found this sentence in your announcement interesting:
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 |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Is there any progress? When can we experience the new middleware? |
Beta Was this translation helpful? Give feedback.
-
|
In my case, what I need is a place to run top-level telemetry logic that can't run in current edge middleware. 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. |
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/vercel/next.js/releases/tag/v14.2.7 new update! edge middleware upgrade! still cannot switch to node |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
They're literally working on it right now. |
Beta Was this translation helpful? Give feedback.
-
|
I'll believe it when I see it |
Beta Was this translation helpful? Give feedback.
-
|
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]. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
https://x.com/rauchg/status/1842054402288611671?s=46 ril or fecc |
Beta Was this translation helpful? Give feedback.
-
|
Switching to onestack because of this issue not getting resolved. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
Well, as already pointed out above, such "out of reality"/"theoretical"/simple examples do not work, because "proper" |
Beta Was this translation helpful? Give feedback.
-
|
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 :( |
Beta Was this translation helpful? Give feedback.
-
|
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. 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 ProtectedLayoutand if you want to get the current URL like 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 AuthLayoutThis 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 :) |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Update (Request Interceptors)@unstubbable has a PR open for an experimental feature called Request Interceptors, which address some of the concerns in this discussion: 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. |
Beta Was this translation helpful? Give feedback.
-
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:
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
No need to be sorry bro, that issue is addressed in the |
Beta Was this translation helpful? Give feedback.
-
|
@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
(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) |
Beta Was this translation helpful? Give feedback.
-
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.
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.
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.
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).
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I share the frustration many in here feel, especially when it comes to auth and securing routes with middleware. Something i havent read here is the possibility of starting nextjs with a custom server. The docs provide a guide 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 🙏 |
Beta Was this translation helpful? Give feedback.
and others
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 🙏