Why is middleware not supported like layout in the App router?
Unanswered
Golden-winged Warbler posted this in #help-forum
Golden-winged WarblerOP
The power of being able to define nested layouts in the App router by simply adding a
Why doesn't
Is there an open issue or roadmap for a distributed middleware.ts like layout.tsx?
layout.tsx is powerful.Why doesn't
middleware.ts work this way as well? Why are we limited to having a single middleware file and more so, why do we have to manually inspect the incoming request path to decide what middleware to apply (when we need conditional stuff like /admin pages?) This gets very unwieldy pretty quickly. This ought to work the same for both pages and routes.Is there an open issue or roadmap for a distributed middleware.ts like layout.tsx?
65 Replies
in the beta version you could have multiple nested middlewares, but based on user feedback this feature was removed for various reasons, mostly because the behavior was too confusing and expensive. you can read more about it here: https://nextjs.org/docs/messages/middleware-upgrade-guide#no-nested-middleware
Golden-winged WarblerOP
That explanation does not rationalize it for me. Every point can be refuted or countered.
Can I suppose this means there is no chance for changing middleware to apply like layouts? If middleware was too confusing, why are layouts distributed? Middleware ought to apply the same way as layouts, no?
Can I suppose this means there is no chance for changing middleware to apply like layouts? If middleware was too confusing, why are layouts distributed? Middleware ought to apply the same way as layouts, no?
I don't even follow the "expensive" part when computationally "cheaper" (which doens't add up logically) was described in the previous bullet
It seems like it ought to be possible to replicate the automation that ought to be there, I will just have to wire up the imports back down to the one middleware, and pull the details needed from the distributed middleware.ts files
Golden-winged WarblerOP
isn't that lifting business logic into the presentation layer?
@Golden-winged Warbler isn't that lifting business logic into the presentation layer?
since the composition of server component and client component, business logic has been combined with presentation layer
Golden-winged WarblerOP
how would this work for API routes?
like certain routes should have auth vs not?
API routes can't be middleware-d like layout.tsx, so either use middleware.ts or create a function that you can paste in the route that you want to protect xD
in this case i choose the latter since i haven't configured Prisma to work in edge environment
Golden-winged WarblerOP
This setup is weird given all the other benefits Next offers with automatic layout, routes, and such.
@Golden-winged Warbler I don't even follow the "expensive" part when computationally "cheaper" (which doens't add up logically) was described in the previous bullet
vercel bills middleware usage per invocation, if you have multiple nested middlewares you would get multiple charges with a single request
Golden-winged WarblerOP
You don't have to run next on vercel though...
@Golden-winged Warbler This setup is weird given all the other benefits Next offers with automatic layout, routes, and such.
its ok, maybe in Next 16 they will bring back, or 15, or 17 idk
Golden-winged WarblerOP
and your middleware should have to cost anything more than the same compute you pay for the server it's running on
unless you are using 3rd party APIs, at which point, I'd expect the dedup logic or other optimizations to be able to make it easy to avoid the "extra expense"
well
you can always opt in to your custom API route handler
and add your middleware that way
make a ...catchall route and handle your middleware there
Golden-winged WarblerOP
you mean use an express like router for
api/[...slug]?yep haha
Golden-winged WarblerOP
that defeats the purpose does it not?
defeat what purpose
Golden-winged WarblerOP
Can Next still do its fancy evaluation, caching, rendering automation for SSG, ISG, SSR?
no thats only for API handler
and it always requires user auth, so its always an SSR
Golden-winged WarblerOP
like will it be able to infer the API usage from within the clients and make sure I use "use client" where needed
its only for API handler
Golden-winged WarblerOP
why would /api always require auth?
because thats thats what i use in my case
all of the api handler are dynamic (in my case)
Golden-winged WarblerOP
I suppose the non-api side would see fetches at some point?
wym
Golden-winged WarblerOP
It still defeats the purpose that I can look at the filesystem and see what the route tree looks like
the page rendernig?
well you see i dont like how the route tree is so deep such that it takes a big width of space so i just simplify it to 4 route files haha
Golden-winged WarblerOP
like, Next can look at what I am doing and infer if it can statically generate or if dynamic is requried, same idea for knowing if something can run on server or client, has to ...
would that still work across custom routing?
its an api handler. it always run in server and most of it are dynamic
Golden-winged WarblerOP
... I'm talking about the non-api routes ...
non-api routes are still left as is, i didnt do custom routing for non-api routes....
i still need the RSC feature
i still need the RSC feature
Golden-winged WarblerOP
they still need to access things, but now they are accessing their own API routes outside of Next's routing
but I make a custom route matching on my own
i didnt do it on a separate back-end
Golden-winged WarblerOP
this has veered to far away from the original topic into how you have implemented something, I'm not asking how you did something, rather how things work, why they do, and why the lack of consistency
the explination I got for the lack of consistency is not good, imho
(brb) this is still an engaing convo I want to keep going, but I have to step away for a few minutes
middleware.ts, which is designed to run on Edge Runtime, based on V8, Cloudflare worker should be light weight to reduce cold start time. so they made it simple. i guess.
I assume its a completely different environment than your standard API route handler
spin up time would be less than 1s, i guess
Golden-winged WarblerOP
so middleware runs outside of the server generally, or only on vercel?
is that where any api routes run?
nextjs is code for a react framework, not where I run it, correct? I can run a nextjs powered webapp anywhere
@Golden-winged Warbler and your middleware should have to cost anything more than the same compute you pay for the server it's running on
yeah thats true, this reason isn't very strong if you self host your app
but this is mostly why they did it, when the app runs on vercel each middleware invokes an edge function so nesting them would be a performance penalty
people also got confused on their execution order, so they thought it would be better to just remove this feature
you can still organize the middleware code with a few abstractions if you don't like a single file
but this is just a better default for most people
Golden-winged WarblerOP
define most people... :]
this blog might be a hint https://vercel.com/blog/vercel-edge-google-optimize
Golden-winged WarblerOP
yeah, vercel is not a platform I would choose, I think the architecture does not make sense for most people. They are trying to convince you that it does make sense.
Either way, if vercel architecture and money making decisions effect the design decisions of a react framework, it might make Next too confusing and not viable for most people beyond vercel users (which are probably "most" people from their context, but pretty limiting imo)
Either way, if vercel architecture and money making decisions effect the design decisions of a react framework, it might make Next too confusing and not viable for most people beyond vercel users (which are probably "most" people from their context, but pretty limiting imo)