Middleware enhancements after new Next.js middleware architecture

[amannn]

Is your feature request related to a problem? Please describe.

It seems like there's work happening on the Next.js side on a middleware revamp: vercel/next.js#46722 (comment)

I'm using this thread to collect aspects about the current next-intl middleware that we could potentially address in case a revamp is relevant after the Next.js change.

Describe the solution you'd like

My personal wishlist for Next.js:

1. Passing a locale to the rendering phase (see Reading params deeply in Server Components (e.g. for i18n / multi-tenancy) vercel/next.js#58862). Ideally this would be possible without a middleware in the first place though. Update: Seems like this is coming as rootParams.
2. Easy exclusion of: Next.js internals _next, static files (both public as well as generated by Next.js from icon.png & friends)
3. A dynamically created matcher

Mentioned here.

Separately from this, there are some use cases we could support better that do not rely on Next.js:

1. Get the locale within middleware #1356
2. Locale detection could be more flexible #1369
3. Feature Request: RoutingConfig for Locale Cookie Sync Control #1793
4. Maybe opting out of root redirect? Possible already by adapting the matcher, but would there be an advantage to make this more explicit?
   We can make these changes in any case, but in case a refactoring is necessary after the Next.js change, maybe it'd be worth waiting a bit.
5. Ability to disable routing redirects #2056

[apavlinovic]

We have a big issue with next-intl, which is preventing us from using a middleware today at all.

Here's our issue, maybe this is something that can be addressed in a future update for middlewares, since it's preventing us from recommending next-intl for public production projects:

• Since we are attaching messages to the request context, these messages get physically imported and dumped into the configuration file
• For some reason, when you add a middleware.ts file, it inherits that request context and all of the messages are available in the middleware.
• This seems like a handy feature, but it really isn't, since it increases the size of a middleware file by however many messages you attached to the request context
• As a result, middleware performance is severely degraded, up to a point where it is causing NextJS image optimizer to time out.
• We tried reaching out to you earlier about this, but gave up, since we just stopped using middlewares until this issue is fixed... which judging by the comment that "a 54 kb middleware is not bad" doesn't seem likely

I just want to highlight a few things about the current behaviour of the next-intl's request configuration:

• Since you are recommending that translation files are loaded in the request context, you are inadvertently slowing down anything in NextJS that uses request context. It's JSON that needs to be parsed, and moving megabytes of data across a server side rendering pipeline is not a good idea.
• Middleware's are basically unusable outside of any toy project when using next-intl, since the size of messages grows pretty fast for any serious project, and it is killing server performance by a mile
• This may be an architectural mistake, since there doesn't seem to be any reason why a middleware would have access to your current translation messages. Why does a middleware, which doesn't render the UI, know about these messages?

You can test this for yourself, just add a few more messages to your example-app-router and see how fast the middleware file grows. If you can't think of text, use Lorem Ipsum.

For us, this is the number one problem with your library, and it is very hard to recommend it to anyone - this is simply not scalable, next-intl is accidentally killing a built in NextJS feature.

Middlewares should never be aware of your translation messages, less likely bundle them in their execution code. A middleware gets executed for EVERY request, this is pure insanity.

[amannn]

@apavlinovic The issue you've linked to was closed due to inactivity from your side.

I just tried adding a very lengthy message to example-app-router and did not see any increase in middleware size, which btw. is currently at 41.1 kB. The messages are definitely not imported into the middleware. I'm not sure if you're using a special build configuration or you're accidentally importing the messages into the middleware due to your import graph.

If you'd like to get to the bottom of this, please create a new issue using the bug report template and provide a reliable reproduction based on the provided template.

[amannn]

Seems like there's some movement here: vercel/next.js#70961.

As far as I understand the feature, it's mostly targeted at validation. The best I can think of is a validation that the [locale] param contains a valid value and alternatively call notFound(). This would be a slight improvement, but if the mere presence of an interceptor opts the page into dynamic rendering, this already has a downside in comparison to running the validation in [locale]/layout.tsx.

From a first glance, the new interceptors feature currently doesn't look like it could help with the pain points that were mentioned above. I'll keep an eye on it though.

[Kuchasz]

Next-intl's middleware must be the first one that produces the response to work properly. It won't use response produced by the others even if does not do any redirects. It makes way harder to make it work with any middlewares composer. I've built a clunky solution which has one huge limitation - next-intl middleware must be always first in chain. Other middlewares just append some stuff to the generated response.

Accepting optional NextResponse as argument in next-intl's middleware could solve. Not sure if anyone else would like to use it xD

Even the docs see here somewhere in between states that this middleware is the only one that should produce the happy path response. Do you have any thoughts on that? Maybe i may solve that differently or you can propose some more extensible solutions in next-intl middleware.

[armandabric]

I getting in the same gotcha as @Kuchasz. The current next-intl isn't chain-able easily. If possible it could be a good idea to improve this as next.js push us to use more and more the middleware.