apavlinovic
commented
14 hours ago 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
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: https://github.com/vercel/next.js/discussions/46722#discussioncomment-10262088
I'm using this thread to collect aspects about the current
next-intlmiddleware 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:
localeto the rendering phase (see https://github.com/vercel/next.js/discussions/58862). Ideally this would be possible without a middleware in the first place though.Mentioned both here.
Separately from this, there are some use cases we could support better that do not rely on Next.js:
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.