Originally published at coreycleary.me. This is a cross-post from my content blog. I publish new content every week or two, and you can sign up to ...
For further actions, you may consider blocking this person and/or reporting abuse
The only caveat to this is that log style that is good to appear during development in terminal (colors, descriptive text messages) is different from log style that is good for production (meatadata, timestamps). So I would still use a logging library instead console.log, just configure it differently in dev and prod.
Good article!
And good timing as far as I'm concerned :)
I'm writing an API and outputting to console.log/console.error and was wondering if it was better/recommended to write a log function early and use it everywhere or keep my output to the stdout.
I was supposed to research that tonight so you saved me time!
I would definitely use a function, since you will need to timestamp and tag your logs, log structured data, etc.
And what if you want to extract part of the application into an internal library?Libraries shouldn't touch IO, they can only accept a logger injection.
And what if you want to use the code in a frontend web application? Who will route your logs there?
So yeah, always use a function/library, just don't try to connect to the logging server instead of stdout yourself, especially in a stateless deployment.
That's an interesting identifier you got there.
Not valid, but interesting.
@corey . Awesome article. Right article, right time. I am getting to that point in my own project. Now to investigate how to get it done using nginx hosted on Azure and DigitalOcean. Thank you!
Awesome, glad it was helpful
Good insights. Goes well with ensuring developers can debug their code in production.