You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! I'm trying to implement a response time calculator in a Next API Route package I'm developing, and running into a roadblock.
The middleware stack currently runs synchronously, which prevents middleware from executing code after an async handler has been resolved. Instead, the stack unravels after an awaited call, executing code after next() in a middleware while doing so. The example below illustrates this.
Would there be any interest in a PR which changes this behavior and adds accompanying documentation?
The simplest method would be to change next() to return the result of it's expression. This would let users form async middleware chains in their applications, resolving the issue described above. It also has the benefit of being a non-breaking change.
The only major limitation is that async middleware would be all or nothing. Any middleware that fails to await or return the result of next() would break the async chain. This could cause some major confusion, and would need to be well documented. The same behavior can be found in other libraries such as koa.js and the long awaited Express v5, however, so it's not an entirely new concept.
Example
importncfrom'next-connect';import{someAsyncWork}from'./another-module';constmiddleware=(req,res,next)=>{console.log('1');awaitnext();// await has no bearing in the current version, however with the proposed solution, it would.console.log('4');};consthandler=async(req,res)=>{console.log('2');constsomeData=awaitsomeAsyncWork();res.status(200).json(someData);console.log('3');};exportdefaultnc().use(middleware).get('/',handler);
Output
Expected
Actual
1
1
2
2
3
4
4
3
The text was updated successfully, but these errors were encountered:
Hello! I'm trying to implement a response time calculator in a Next API Route package I'm developing, and running into a roadblock.
The middleware stack currently runs synchronously, which prevents middleware from executing code after an async handler has been resolved. Instead, the stack unravels after an
await
ed call, executing code afternext()
in a middleware while doing so. The example below illustrates this.Would there be any interest in a PR which changes this behavior and adds accompanying documentation?
The simplest method would be to change
next()
to return the result of it's expression. This would let users form async middleware chains in their applications, resolving the issue described above. It also has the benefit of being a non-breaking change.The only major limitation is that async middleware would be all or nothing. Any middleware that fails to
await
orreturn
the result ofnext()
would break the async chain. This could cause some major confusion, and would need to be well documented. The same behavior can be found in other libraries such as koa.js and the long awaited Express v5, however, so it's not an entirely new concept.Example
Output
The text was updated successfully, but these errors were encountered: