Update production best practices #1679
Conversation
github-actions
bot
added
requires-translation-fr
requires-translation-es
requires-translation-it
requires-translation-ja
requires-translation-ko
requires-translation-pt-br
requires-translation-ru
requires-translation-sk
requires-translation-th
requires-translation-tr
requires-translation-uk
requires-translation-uz
requires-translation-zh-cn
requires-translation-zh-tw
requires-translation-id
labels
✅ Deploy Preview for expressjscom-preview ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
bjohansebas
force-pushed
the
update-performance-info
branch
from
4133f2f to
0b2aeca
Compare
bjohansebas
changed the title
There was a problem hiding this comment.
I think this is an improvement for sure. Great work @bjohansebas!
I think we probably need to re-think the role our docs play in the ecosystem. Best practices have evolved quite a bit since this was all written, and it will evolve again in the coming years. We probably don't want to be the source for too much content like this unless we are able to keep it updated.
That said, for now, I am very much in support of improving this type of doc so LGTM!
|
|
||
| #### For debugging | ||
|
|
||
| If you're logging for purposes of debugging, then instead of using `console.log()`, use a special debugging module like [debug](https://www.npmjs.com/package/debug). This module enables you to use the DEBUG environment variable to control what debug messages are sent to `console.error()`, if any. To keep your app purely asynchronous, you'd still want to pipe `console.error()` to another program. But then, you're not really going to debug in production, are you? | ||
|
|
||
| #### For app activity | ||
|
|
||
| If you're logging app activity (for example, tracking traffic or API calls), instead of using `console.log()`, use a logging library like [Winston](https://www.npmjs.com/package/winston) or [Bunyan](https://www.npmjs.com/package/bunyan). For a detailed comparison of these two libraries, see the StrongLoop blog post [Comparing Winston and Bunyan Node.js Logging](https://strongloop.com/strongblog/compare-node-js-logging-winston-bunyan/). | ||
| If you're logging app activity (for example, tracking traffic or API calls), instead of using `console.log()`, use a logging library like [Winston](https://www.npmjs.com/package/winston) or [Pino](https://www.npmjs.com/package/pino). There are more packages with the same purpose, you can check the LogRocket blog post ['Comparing Node.js logging tools'](https://blog.logrocket.com/comparing-node-js-logging-tools/) for a comparison between these packages and others. |
There was a problem hiding this comment.
We should deprecate and remove all references to winston and bunyan. Pino is the only good recommendation these days.
There was a problem hiding this comment.
Should I also delete the blog post? I think it would be good to keep it.
| @@ -142,26 +142,23 @@ Now, all errors asynchronous and synchronous get propagated to the error middlew | |||
|
|
|||
| However, there are two caveats: | |||
|
|
|||
| 1. All your asynchronous code must return promises (except emitters). If a particular library does not return promises, convert the base object by using a helper function like [Bluebird.promisifyAll()](http://bluebirdjs.com/docs/api/promise.promisifyall.html). | |||
| 1. All your asynchronous code must return promises (except emitters). If a particular library does not return promises, convert the base object by using a helper function like [util.promisify](https://nodejs.org/api/util.html#util_util_promisify_original). | |||
There was a problem hiding this comment.
This is pretty poorly worded imo, and frankly wrapping callback libraries in util.promisify is not best practice either. Additionally, since we added error handling support in v5 I wonder if we should remove or rewrite this section entirely?
There was a problem hiding this comment.
Agree... seems like we can focus on v5 and remove this section
There was a problem hiding this comment.
I'll remove it, I'll open an issue to see if someone wants to make the change, or if not, I'll come back to it soon. I still need to think carefully about how to document it properly, and since my focus was on replacing links and updating some references in this PR, I don't want to delay it any further.
Co-authored-by: Chris de Almeida <ctcpip@users.noreply.github.com>
Co-authored-by: Chris de Almeida <ctcpip@users.noreply.github.com>
…date-performance-info
Modernize this page by making the following changes: