How to change limit? API response for ${req.url} exceeds 4MB. This will cause the request to fail in a future version.
See original GitHub issueWhat version of Next.js are you using?
11.1.0
How are you deploying your application?
Other platform
Describe the Bug
When streaming a large file in an API response, are getting this warnings on the terminal.
(this change was first introduced in PR https://github.com/vercel/next.js/pull/26831 and modified to 4mb in https://github.com/vercel/next.js/pull/26887)
API response for /api/... exceeds 4MB. This will cause the request to fail in a future version. https://nextjs.org/docs/messages/api-routes-body-size-limit
But we are not using Vercel. We are not using AWS serverless functions at all. So to throw a warning is not relevant to us.
I am concerned that we will update Next.js and our file downloads will start throwing runtime exceptions in production as wording of #26831
In a future version this scenario will throw an error.
Possible solution(s)
I propose a config option to suppress this warning (future error) for non-Vercel users of Next.js.
Alternatively, I’m wondering if middleware would make this a non-issue?
We are hoping to avoid spinning up a custom server, but will do if required.
Issue Analytics
- State:
- Created 2 years ago
- Comments:19 (7 by maintainers)
Top GitHub Comments
My app would also greatly benefit from being able to override this restriction. We too are not using serverless functions and are ok with larger response payloads. I really like the Next API and don’t want to have to create a custom server and express API.
@balazsorban44, Prior to opening this issue I read through all the relevant documentation. I’m aware that it is intentional.
However, in our use case, these are private files (requires authentication check), a lesser-used feature in larger application, and all users are in the same country. Therefore we could not justify a CDN. Even a dedicated media host would be overkill. As we grow this may change but not any time soon.
We could certainly start a custom server but that seems like a workaround for red tape. Plus we’d lose the
npm run dev
hot reloading advantage for those particular endpoints.On the other hand, it would be so easy to add a config switch, and many developers are in use cases like ours, where, nobody benefits from overengineering. That is, until they can grow their company to a larger scale.
So, I’m just thinking through the Next.js team’s motivation for adding this restriction. What your team has done makes sense in certain use cases, but not for everyone. I’m particularly concerned about the Error coming in a future version.
My team would be glad to create a PR for a config switch. What do you think?