←back to thread

Next.js is infuriating

(blog.meca.sh)
1033 points Bogdanp | 5 comments | 02 Sep 25 06:57 UTC | HN request time: 1.068s | source
Show context
pavel_lishin ◴[02 Sep 25 12:38 UTC] No.45102328[source]▶
> Let's not skip over the fact that you can't have multiple middlewares or chain them either.

Surely this can't be right?

https://nextjs.org/docs/messages/nested-middleware > If you have more than one Middleware, you should combine them into a single file and model their execution depending on the incoming request.

By Talos, this can't be happening.

replies(2): >>45102832 #>>45105164 #
1. digianarchist ◴[02 Sep 25 16:21 UTC] No.45105164[source]▶
I can’t help but feel some of these decisions are made because it’s what is best for Vercel and not what’s best for the framework.
replies(1): >>45105569 #
2. tshaddox ◴[02 Sep 25 16:43 UTC] No.45105569[source]▶
I don't see how this particular case makes anything better or worse for Vercel. It's just a poor developer experience to need to come up with your own composeMiddlewares function (or find one of the many that people have posted in various threads).
replies(1): >>45105867 #
3. digianarchist ◴[02 Sep 25 17:04 UTC] No.45105867[source]▶
They validated this on the thread. They made an architectural decision to run middleware only on edge.
replies(1): >>45107412 #
4. tshaddox ◴[02 Sep 25 18:52 UTC] No.45107412{3}[source]▶
That's unrelated to the complaint I'm responding to, which is simply that you can only provide a single middleware file. This is merely a DX problem. You absolutely can develop your own composeMiddlewares function and import different middleware functions from different modules. It's just on you to do that, and to reimplement some basic functionality for each composable middleware function (like matcher regexes).
replies(1): >>45119692 #
5. digianarchist ◴[03 Sep 25 19:43 UTC] No.45119692{4}[source]▶
From their blog post:

> Previously, Next.js middleware only supported the Edge Runtime, which provided better performance and isolation but had limitations when integrating with Node.js-specific libraries and APIs.

That's not something that can be resolved with a library abstraction. That was an architectural decision.