In November of 2014, when NodeSource was still a small consulting group, my teammates Dan Shaw, Rod Vagg, and I were having dinner after a customer engagement, discussing how to bring Node.js production deployments to the same level of polish and tooling capability of the other runtimes our customers were already employing.

As a Node.js developer, you know that testing code and maintaining its quality are essential aspects of software development, arguably just as important as writing code. In this article, we will dive deep into the world of testing in Node.js, explore its importance, and examine the various types of tests required for building reliable and robust applications. By the end of this article, you should be able to set up tests for Node.js applications.

Node.js v21, the latest Node update, is now available as a stable release. It supersedes v20 in the'Current' release line, which has been promoted to the long-term support (LTS) channel as of 24 October. This new version stabilizes the fetch and WebStreams API, adds a built-in WebSocket client, improves support for ES modules, and brings some notable performance improvements (as well as a customary update of Node.js dependencies such as V8).

As a developer, choosing the right Websocket Node library to integrate into your realtime application project can be a humbling experience. You are faced with a lot of choices that offer different capabilities and features that will allow you to build scalable and efficient applications. However, given the constantly changing landscape, a crucial question remains: have you selected the most suitable one? Are there other options that could enhance your project even more?

We are excited to share the release of our new Cost Calculator to showcase just how much the wrong APM provider can add to your cloud hosting costs (try it now). Observability is vital, but it comes with computational overhead that shares the same infrastructure as your application. This is compounded in typical Node.js APM tooling due to the internal workings of Node.js itself.

In the first part of this series, we built the asynchronous components of a much larger solution. Today, we will build the API interface that can be consumed in real-time.

The thrill of seeing your user base skyrocket will only last until your server crashes! In this article, Giridhar Talla discusses several strategies to make your Node.js applications ready to handle high traffic volumes.

Complex functionality can take a while to load. Users, in general, don't like to wait, so solutions must evolve. If you are already familiar with async/await in JavaScript, think of await as the place where blocking logically occurs. This forces the algorithm to wait, and technically, it's still synchronous code. Step functions allow long-running processes to run in the background asynchronously, so the logic does not get blocked and force people to wait.

You can find the issue by reading the stack trace after a program fails. A stack trace, however, only reveals the status of the application at the time of failure and not before the error was met. Logging packages can help with this. They provide specifics about the behavior of the program before the failure and transmit them to the location you specify, such as a file or a monitoring tool. Node.js has access to a wide variety of logging tools, but not all of them are made equal.

Playwright and Puppeteer have emerged as two of the most powerful end-to-end testing Node.js libraries. Their robust APIs make it easier to test the UI and workflows of sites and web applications. Although they are similar tools that offer comparable features, there are circumstances in which one is better to use than the other. In this article, we'll look at scenarios where it's better to use Playwright than Puppeteer for functionality and performance reasons.