3 ms·

> 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/nes

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

zelphirkalt 1y ago
Am I reading this correctly? They are advocating giving up on structuring code in separate files? Is that a scoping problem that NextJS has, which makes it difficult to use multiple files? Seems like a rather ridiculous statement of a framework to make.
- wetoastfood 1y ago
  It's the single file that is used to define the middleware function that runs. You can import whatever you want into it and decide how "you should combine [your middleware] into a single file."
  - hn_acc_2 1y ago
    I prefer this to having app.use / router.use scattered anywhere throughout the app init (i.e. Express)
  - qbane 1y ago
    As a JavaScript developer, combining/consolidating middlewares manually just defeats the design of middleware. I would rather call it a callback function.
digianarchist 1y ago
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.
- tshaddox 1y ago
  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).
  - digianarchist 1y ago
    They validated this on the thread. They made an architectural decision to run middleware only on edge.
    - tshaddox 1y ago
      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).
      - digianarchist 1y ago
        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.

zelphirkalt 1y ago

Am I reading this correctly? They are advocating giving up on structuring code in separate files? Is that a scoping problem that NextJS has, which makes it difficult to use multiple files? Seems like a rather ridiculous statement of a framework to make.

wetoastfood 1y ago
It's the single file that is used to define the middleware function that runs. You can import whatever you want into it and decide how "you should combine [your middleware] into a single file."
- hn_acc_2 1y ago
  I prefer this to having app.use / router.use scattered anywhere throughout the app init (i.e. Express)
- qbane 1y ago
  As a JavaScript developer, combining/consolidating middlewares manually just defeats the design of middleware. I would rather call it a callback function.

digianarchist 1y ago

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.

tshaddox 1y ago
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).
- digianarchist 1y ago
  They validated this on the thread. They made an architectural decision to run middleware only on edge.
  - tshaddox 1y ago
    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).
    - digianarchist 1y ago
      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.