Repository navigation
arc.http should allow mixing sync and async middleware #552
Description
Is your feature request related to a problem? Please describe.
If my handler looks like the following, the arc.http and arc.http.async helpers in version 7.0.0 will complain with
TypeError: All arc.http middleware functions must be async
console logEvent = (event) => {
console.log(event)
return event
}
export const handler = arc.http(
logEvent,
async () => {
// do async work
},
)
However, it would be quite weird to have to turn the above logEvent into an async function.
Describe the solution you'd like
If you want to keep supporting the callback interface, I think it would be best to stick with the API of versions <7. Version 7.0.0 forces me to make functions async that are not async in nature.
Describe alternatives you've considered
An alternative could be to have arc.http be 'smart' the way it currently is in 7.0.0, but arc.http.async to behave the way it did <7.
Activity
filmaj commentedon Mar 22, 2025
Currently (v8)
arc.httpdoes require all functions to be of the same type, either sync or async. It would be nice if this method was smart enough to inspect each middleware individually and execute appropriately. So, I'll accept this as a feature request.Side note: I disagree, I don't think it's weird and works just fine 😄 I believe the only downside to having an
asyncfunction with noawaitcalls is that under the hood the function's return value is wrapped in aPromise. This may have a tiny performance impact - maybe? But how many middleware functions is one stringing together in an arc handler, really? Even if it was hundreds, I doubt that would register in benchmarks.[-]arc.http[.async] in version 7.0.0 are overly strict regarding mixing sync and async middleware[/-][+]`arc.http` should allow mixing sync and async middleware[/+]alexbepple commentedon Mar 23, 2025
I agree that it works just fine. My – slight – gripe is that there is mismatch between language semantics & runtime behavior. If one forgets
async, the error only shows at runtime, not while writing code. And later, when reading code, one might wonder why that function is async. One has to remember that it’s due toarc.http. It’s a small, but entirely unnecessary distraction.