I have been a full stack web apps developer for a good while now and has almost always been advised to turn off browser side logs in production. While for the most part I agree with the common wisdom, I believe, in certain situations and if done right, logs in production can be helpful.
All the reasons that are given for not having them on? Let’s take a look at couple of them and why they are not good enough to make me paranoid about production logs.
While yes, removing them hides the data from plain sight, it still does not provide any real security. Anyone with evil intentions and technical know how to harm your system can do so without logs being shown. Remember, all the files, the code and the data is already executing and resides on the user system and can be accessed with relative ease.If there is a vulnerability to be exploited, then you have other things to worry about rather than logs.
I personally don’t even consider this a valid argument, but it’s given. I couldn’t care less what someone else thinks about my production developer console not looking clean.It isn’t supposed to look fancy, that’s what the actual website is for. It’s supposed to be an area for sharp messages, stating clearly and concisely what’s going on with the page.Well written logs look cool, and you can’t change my mind.
The benefits may be niche and use case driven, but there certainly are times when they help.
I have had more than one occasion where support requested me to fix an issue faced by the user and I couldn’t figure out the cause just by user’s description. And a simple screenshot of console from the user showed me the light of day.A log simply tells a better story than the visual behavior of the website. And that story is much clearer in case of certain issues.
If your app is fresh out on production or perhaps you have open demo available for potential customers in the early days of marketing, rest assured it is bound to run into issues. It’s a good idea in these cases to keep the logs on until you achieve more stability and also to provide better informed feedback to potential customers instead of an “I don’t know what’s happening”.They can always be turned off later down the line when production issues are far and wide.
If you are doing it you might as well do it right. Certain guidelines when it comes to logging.
Instead, use a wrapper module which takes in arguments and logs them using console.log. It provides more control, this way you can easily tweak it to turn the logs on/off based on some environmental variables. A very basic example :
A way to have finer control over you logs is to use log levels. What this means is instead of having a simple console.log you can customize the above mentioned wrapper to have multiple type of logs such as info, debug, error where each caters to certain type of use case. And all or some of them can be turned off depending upon the environment they run in.An example of one such simple logger with multiple levels can be found here.
This read was not intended to recommend production logs but as a request to keep an open mind about it, look at the your requirement and decide if it makes sense to have some or all of them on. And a couple of tips thrown in to do them properly.Logs are the best tools a developer can ask for, and they can be so even in production. It doesn’t have to be a crime. If it makes sense, it’s okay.
Written by Shardul Malik
Blog
Comments