There are two popular logging frameworks in NodeJS. One is winston and another one is Bunyan. There is another tool called debug.
As far as I understand, they are just doing the same thing which is logging something. debug is a default component of an Express app and it looks quite popular based on the number of downloads in NPM.
Can you suggest when to use debug and other logging framework? I am not asking to compare between different logging frameworks. I just wonder the position of debug.
debug is geared specifically toward interactive debugging. It logs human-readable plaintext and is designed to usually be disabled and then have interesting modules enabled periodically when a developer is actively debugging something. It is also fairly good in both node and browser environments. Its main use seems to be for re-usable libraries as opposed to applications.
winston, bunyan, and bole are geared toward newline-delimited JSON format which is mostly intended to be computer-readable. It's good for applications where your log data is gathered and stored in a central database for later analysis and searching and long-term trending.
So a quick rule of thumb might be debug for re-usable packages published to npm and one of the ndjson-format ones for applications where logs are stored long-term and analyzed later.
Related
Context: I'm developing a TF Provider and I could see the latest "Writing Log Output" doc from HashiCorp where they recommend using tflog package for logging.
That said, I can see TF Provider for GCP are still using log package. What're the advantages of using tflog over log?
The Structured Logging section of the documentation you linked describes the authors' justification for recommending this different logging strategy:
The tflog package uses structured logging, based on go-hclog. Rather than writing logs as sentences with embedded variables and values, tflog takes a sentence describing the logging event and a set of variables to log. When variables are separate from the log description, you can use them to programmatically parse, filter, and search log output. This separation also allows other parts of the system to associate variables with downstream log output.
Although not mentioned explicitly as an advantage in the documentation, it does also mention that tflog has a notion of log levels, and there's no corresponding concept in the standard library log package at the time of writing.
Given that, I would conclude that the two intended advantages of tflog over standard library log are:
tflog uses a structured logging approach where the separate variables in the result are machine-parsable and therefore amenable to automated filtering via scripts.
tflog associates a log level with each message, and the SDKs allow customizing the log level for a particular execution to control the amount of output.
I think getting any further context on this would require asking the authors of the SDKs, since this is a subjective design tradeoff rather than a situation where there is one clear correct answer.
I assume that some existing providers continue to use standard library log just because that code was written before tflog existed. tflog v0.2.0 (apparently the first publicly-published version) was released in December 2021, whereas big Terraform providers like the Google Cloud Platform provider have been under development for almost a decade before that.
In Node, does it make sense to port some logic to wasm for json manipulation operations in order for the algorithm to be quicker?
tl;dr Don't use WASM for JSON manipulation.
Setting up the WASM tooling is no small thing, and will likely require more ongoing troubleshooting and maintenance than lighter-weight solutions.
Wasm generally comes into its own when you need to do truly compute-intensive stuff like customized signal (image/video/audio) processing for your browser users or natively inside server-size Javascript environments.
If your purpose in doing this is avoiding overhead in JSON processing, you might consider looking for fast JSON packages on npm. fast-json-stable-stringify is an example.
You should also keep this in mind: V8 -- the open-source Javascript engine in nodejs, deno, and chromium -- is under active development by a large and highly competent team at Google. That engine includes the JSON. functions. Performance improvements show up in every release, and they're highly motivated to keep making things faster. JSON handling is one of those areas. If you roll your own, your code won't get any faster with the next release of V8/nodejs. If you use the stuff in V8, it might.
Take a look at this dev summit presentation, for example. Maybe you can outsmart the V8 team. If so you should join them.
So, if you want to learn WASM, do something that will add interesting new capabilities to your personal toolbox.
Unlikely. The V8 engine has a pretty good JIT compiler. If it is a hot path and properly written, it will become machine code anyway.
I spent the last couple of days figuring out what development stack to use for the interactive student platform I'm planning to build.
I figured out that the MEAN stack may suit the job very well. However, I face a dilemma whether to use Node.js as backend technology for the application:
Reasons to consider Node
The backend will mainly consist of realtime components. E.g. collaboration tools, notifications, etc.
These components will handle this data concurrently
It will scale better than a conventional server-side programming language such as PHP
Exposing the data with REST for e.g. a mobile applications will be a breeze
Having one data format (JSON) in the front- and backend will speed up development.
Doubts
Some components require computation. Although not that complex, it may slow down the application.
Although the application is mostly a single page application, the application will (in a later stage have some features that Node seems not typically suited for. E.g. a payment workflow.
I already made the switch from a previous approach, so this time I want to be sure to choose the right approach. Will Node.js be the right choice for this application, or will a, for example, PHP backend with Laravel suit the job better as the application matures?
I think there's a whole range of possibilities you're not considering, for example it's a perfectly valid approach to use Node for some of the back-end (e.g. connections to third parties, managing the UI, handling concurrent users) while delegating some of the back-end to other components that are more suited (e.g. components that require heavy computation).
That said, I don't see anything you describe in your 'doubts' as being particularly non-nodish. The computation stuff you say will be lightweight, but my recommendation there is to treat it like any other async task, then if you decide later that it is a problem (e.g. slows down the app) it's pretty trivial to extract that out into either a separate Node process (therefore not blocking your main app's event loop) or use a component built in your language of choice (Java, .NET, C, Perl, whatever) as described above.
I don't understand why you suggest a workflow isn't something Node is suited for. I've seen and built a number of them in Node and other frameworks, it's no less suited for it than any other framework, and better than some.
I would like to script benchmark of my socket.io implementation.
After some research I have identified several NodeJS modules, but they have either not been updated for past years (wsbench), or are only supporting websocket protocol (wsbench, thor) or is not testing socket.io implementation but socket.io project (socket.io-benchmark).
Since socket.io project has been highly active the past year, I wonder what is the latest and greatest tool/module to use for benchmarking?
My requirements:
Easy to script and run the tests
Test reports giving good overview of test runs
Test reports should be easy to save in order to compare with later benchmarking
Just came across this in search of some benchmarking for my Socket.IO project.
I found socket.io-benchmark, however had some additional items that I wanted to work through but found one of the forks nearly there.
https://github.com/slowthinker/socket.io-benchmark
I also forked it to add a cap on messagse/second sent to give it more realistic parameters.
Hope that helps!
I would suggest Artillery: Artillery is a modern, powerful, easy-to-use, open-source load-testing toolkit: https://github.com/shoreditch-ops/artillery
Here some feature:
Mulitple protocols: Load-test HTTP, WebSocket and Socket.io applications
Scenarios: Specify scenarios to test multi-step interactions in your API or web app
Perfomance metrics: get detailed performance metrics (latency, requests per second, concurrency, throughput)
Scriptable: write custom logic in JS to do pretty much anything
High performance: generate serious load on modest hardware
Integrations: statsd support out of the box for real-time reporting (integrate with Datadog, Librato, InfluxDB etc)
Extensible: custom reporting plugins, custom protocol engines etc
and more! HTML reports, nice CLI, parameterization with CSV files
I'm trying to evaluate the reasons to use a logging system like Winston in node.js vs just writing my own logging method. It seems like logging libraries don't really offer much.
Some logging systems (like log4j) have logging hierarchies where if you log to a.b.c it logs to a.b and a as well (unless you have other complicated stop-propogation configurations). Is this kind of stuff usually overkill? What situation would you need that for?
I'm considering just writing a logging function that writes logs to a mongo database, which I'll then be able to pretty easily query and search through. Presumably a logging library can do that, but it seems like it would be just as much work to use a library for that as to write it from scratch.
So in short: what are the benefits to using a logging system?
I don't know about log4j, and not too much about Winston; haven't used it for more than 3 minutes.
But here are the few advantages I'd like to see in a logging system:
Error levels
I must be able to specify the log level I'd like to write to. It's good to have some defaults also (warning, error, debug, etc).
Streaming
You are able to do everything you want when something gets logged: Write it to a file, write it to the database, etc. It's up to you.
Customization
I'd like to be able to:
Timestamped messages
Colored messages when writing to process.stdout (super important while developing!)
Possibility of prefixing the message with the level (for files), or with anything else (when launching various loggers within the same process). This is useful for differentiating between various levels/logger instances that write to the same stream.