Cool, i checked out your boilerplate, I'd maybe extract error handling logic from the middleware to separate module, maybe add logging. Also, have you thought about having StatusError extending the regular one ? So that you can have comprehensive errors with statuses even from within services, instead of response 500. I'd also add that is of high importance if one should extend regular error to attach stack trace from the super class.
All great points!! I was thinking about logging after reading this good guide. Centralized logging would be great. Common context such as user, request-id, timing, etc. can be added to all log output. Lots of log shipping programs like to parse structured logs, and formatting in JSON makes it super easy. Also console.log() is not performant for production
@Strahinja - love of the idea of a StatusError. We do something similar in our application. Controllers can throw new Error() which our Express error handler logs as a server error and responds with an HTTP 500 to the client. Controllers can also use a custom error object and throw new ResponseError(err, 400), which logs a warning and returns an HTTP 400 to the client.
@blake
That sounds really nice. I made a discussion regarding this. You could maybe respond there and maybe put a bit of code so we can put exchanging of ideas in motion.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Cool, i checked out your boilerplate, I'd maybe extract error handling logic from the middleware to separate module, maybe add logging. Also, have you thought about having StatusError extending the regular one ? So that you can have comprehensive errors with statuses even from within services, instead of response 500. I'd also add that is of high importance if one should extend regular error to attach stack trace from the super class.
All great points!! I was thinking about logging after reading this good guide. Centralized logging would be great. Common context such as user, request-id, timing, etc. can be added to all log output. Lots of log shipping programs like to parse structured logs, and formatting in JSON makes it super easy. Also
console.log()is not performant for production@Strahinja - love of the idea of a
StatusError. We do something similar in our application. Controllers canthrow new Error()which our Express error handler logs as a server error and responds with an HTTP 500 to the client. Controllers can also use a custom error object andthrow new ResponseError(err, 400), which logs a warning and returns an HTTP 400 to the client.@blake That sounds really nice. I made a discussion regarding this. You could maybe respond there and maybe put a bit of code so we can put exchanging of ideas in motion.