4 ms·
I haven't looked into this recently so I don't know if anything has changed, but when I last looked up Proxy benchmarks I found that it performed very poorly. D
by TheAceOfHearts 8y ago
I haven't looked into this recently so I don't know if anything has changed, but when I last looked up Proxy benchmarks I found that it performed very poorly. Does anyone know if this is no longer the case?
My initial reaction to this is "just because you can doesn't mean you should". Perhaps that's a bit harsh, but it seems wasteful to be creating these wrappers instead of just adding the desired functionality directly to your favorite logging library. Did you try bringing it up with the people maintaining the wrapped libraries? It's also worth mentioning that async_hooks is considered an experimental API.
The simpler solution is to stick a unique id in the context object of each request, perhaps passing around a request-specific log function as well if needed. You should have access to it from all your call sites so you can pass it in as needed, and there's no need for magic.
- dadschool 8y agoAgreed, we append a logging function to the request context and inject it where needed. With async/await it actually isnt too unwieldily, though it was a bit more intrusive with promises. I think a lot of guys from multithreaded backgrounds (in my case java) often struggle with this approach because looks like such an anti-pattern for them.
- lxe 8y agoYou will lose this context when an error is thrown deep in a library somewhere and your error stack ends up missing most of the useful info. Also how do you deal with I caught exceptions?
- TheAceOfHearts 8y agoThis isn't an issue if you're using promises. You can use try/catch from within async functions and it works exactly as you'd expect. A few years before async functions were available you could also achieve the same thing with generators. In fact, the original release of koa used co [0] under the hood. I'll note my response is written with koa middleware in mind. I haven't kept up much with express, although I think it should be possible to achieve the same thing since they also support async functions. With koa you can add a middleware that wraps all downstream middleware in a try/catch: app.use(async (ctx, next) => { try { await next() } catch (error) { // handle errors } }) [0] https://github.com/tj/co https://github.com/tj/co
- hombre_fatal 8y agoThe other main difference between koa and express is that, in express, you send responses from handlers while in koa, you bubble up a {req,res} context back to koa which sends it which gives you real middleware since you can still mutate the response. The promise chaining nature also makes it so that your example handler can catch all downstream errors unlike express where you must call next(err) and handle it in a downstream handler vs koa's upstream middleware pattern (clojure's ring works the same way). I thank co and early koa for making node bearable for me long before async/await were available.