It can be difficult to know what framework is the best fit for your needs. As software developers, we’re often asked to make technology choices with limited information. In this post, I’m going to pretend I have to choose one of these three frameworks for a new app. By doing a little homework as if I had to choose, I hope to make your life a bit easier. I’ll compare these frameworks in a few ways that I think are important when choosing a technology. Throughout the process, I’ll assign points to each framework that seems to best meet the criteria being discussed.

What’s a framework anyway?

A framework is a collection of tools that provide common functionality for a certain type of application. Frameworks allow developers to quickly start working on business outcomes. We can start solving our problems instead of those that have been solved already. In our case, Sails, Hapi, and Restify are server-side application frameworks. The most obvious functionality a server-side framework should provide is the ability to handle HTTP requests.

What about Sails, Hapi, and Restify?

Sails, Hapi, and Restify are all frameworks, but they weren’t all built with the same intent. Sails is marketed as a Rails-style MVC framework. That means it’s going to offer a lot of features, but it will probably be complex to take full advantage of. Hapi is a web and services application framework. It can still do MVC, but it’s positioned as a more balanced framework. A Hapi application could expose services or a web app. Restify explicitly states in its documentation that it is a web service framework focused on building “semantically correct RESTful web services.”

So what does that mean for us?

It means that while we’re going to evaluate these frameworks relative to each other, our choice will ultimately be contingent on the goals of our application. For example, if we know we need an MVC framework, we might eliminate Restify altogether. However, we can still compare these frameworks in some common areas.

Scoring strategy

I’m going to score these frameworks in relation to each other on a number of different factors. I’ll give points to one or more based on their merits for each point of comparison. In the end, I’ll pick a winner! If I were choosing a framework that I’m going to have to live with for a long time, I think there are several factors I would consider:

• Community—the framework is well liked and adopted
• Documentation—it’s easy to support
• Learning curve—we can train new people
• Performance—the framework can meet my business needs

Community

A healthy community around a technology makes working with that technology so much easier. Given that, here are a few ways we might interpret community health:

• Age—we aren’t worried about it going away
• Issue management—there are active maintainers
• Downloads—people are using it
• GitHub stars—people like it

Sails, Hapi, and Restify are all about the same age, coming to GitHub within a year of each other (between 2011 and 2012). Each framework pushes updates frequently, and, at the time of writing, all three of the frameworks have pushed updates in the last month.

Popularity shouldn’t be the main driver of this sort of decision, but it’s often a good indicator that a product is doing something right. This is where the frameworks currently stand in relation to each other in the popularity department:

At the time of this writing, Sails has 328 issues. Restify has 43. However, Hapi has an astoundingly low nine issues. The Hapi documentation website even has a page devoted to issue tracking! That’s some amazing maintainer support for such a frequently downloaded framework. Hapi also has the most downloads. That’s why I’m giving the overall win for community to Hapi.

Hapi: 1 
Sails: 0 
Restify: 0

Documentation

When looking at the documentation, I’m mostly concerned that there’s a quick-start guide and some references that allow me to see example code. This isn’t so much about seeing which is better, but rather about seeing if one is significantly worse.

Hapi and Restify tick the boxes for a quick-start guide and examples. Hapi has tutorials directly on the site. Restify has some good examples too, but you have to dig for them a bit. They’re in an examples folder in the Restify GitHub repository.

Sails seems to have a great documentation website. However, the quick-start guide isn’t as simple because it involves bootstrapping an entire app with a CLI tool. To counter some of the added complexity of the quick-start, the Sails team provides a repository with a non-trivial sample application written with Sails and Vue.js. Having a sample app for reference is a big plus, which helps make up for the relatively complicated quick-start.

Without using the documentation on a daily basis, it’s difficult to tell how good it is in reality. However, the good news is that there are no red flags for any of the frameworks, and thus no clear winners in this department.

Hapi: 2 
Sails: 1 
Restify: 1

Learning curve

In an effort to get a rough idea about these frameworks’ learning curves, I created a project with each one. I wanted to see how quickly I could get going with a simple use case, such as creating an endpoint that returns some data as JSON. This was extremely easy to do both with Restify and Hapi. Sails, however, was another story.

Hapi

First, I implemented a simple GET call in Hapi to return a list of awesome Blizzard games.

"use strict";

const Hapi = require("hapi");

const server = Hapi.server({
    host: "localhost",
    port: 8000
});

server.route({
    method: "GET",
    path: "/games",
    handler: (request, h) => {
        const games = [
            "World of Warcraft",
            "Diablo",
            "Starcraft",
            "Heroes of the Storm"
        ];
        return { games };
    }
});

const start = async () => {
    try {
        await server.start();
    } catch (error) {
        console.error(error);
        process.exit(1);
    }

    console.log("Server running at: ", server.info.uri);
};

start();

Restify

I did the same thing for Restify. Like Hapi, it was pretty straightforward.

const restify = require("restify");

function respond(request, response, next) {
    const games = [
        "World of Warcraft",
        "Diablo",
        "Starcraft",
        "Heroes of the Storm"
    ];

    response.send({ games });
    next();
}

const server = restify.createServer();
server.get("/games", respond);
server.listen(8000, () => {
    console.log("%s listening at %s", server.name, server.url);
});

Sails

Unfortunately, when I tried to return my precious games in Sails, the implementation was not very straightforward.

Sails has an opinionated view on how the app should be structured. This isn’t necessarily good or bad, but it does add increased overhead when learning it for the first time. With these sorts of frameworks, other people have put in some effort toward creating a structure that allows developers to quickly add new functionality. Hopefully, that upfront learning cost translates into saving time later on, but that doesn’t change the fact that it’s harder to learn initially. For Sails, I had to add an entry to the routes file that took the string value of an action in a controllers directory.

module.exports.routes = {
    "/games": "games"
};

module.exports = async function(req, res) {
    games = ["World of Warcraft", "Diablo", "Starcraft", "Heroes of the Storm"];
    return res.json({ games });
};

While this isn’t a super complex example, it gives me an idea about what it would be like to implement something from scratch. Sails has already introduced an abstraction and corresponding implementation for me. This is confusing to me as a newcomer, and especially on simple projects, separating the actions from the routes in this way can be verbose and confusing. I worry that attempting to do other sorts of things in Sails, such as handling a database connection, will require knowledge of how the creators think apps should be set up. If their abstractions and mental model line up with yours, maybe that’s a good thing. I thought this was confusing, but your mileage may vary.

We found out earlier that Restify is positioned as a web service framework focused on semantically correct RESTful services. It exposes optional middleware for modifying or taking actions on requests and responses. Hapi has a lot of plugins that can accomplish various things, but those features aren’t included in the base package. Both Restify and Hapi have an edge over Sails in the learning department because the features are opt-in, and you can learn them one at a time.

Hapi: 3 
Sails: 1 
Restify: 2

Performance

I was able to find some benchmarks run in environments resembling what I might use for a production server. From late 2018, these tests clearly indicate that Restify has a performance edge over Hapi and Sails for JSON serialization.

I also ran a simple performance test on my machine using Apache Bench and the same server endpoints I created during the learning curve section.

The results on my machine were somewhat similar to those from the benchmarking site. Sails seriously lags behind Hapi and Restify. Hapi performed better on my machine, though still not as well as Restify. Admittedly, the tests I ran on my machine are certainly not ideal, given that my environment isn’t similar to a hosted environment. However, it’s still a good indicator, especially considering how much the results varied. Restify wins here, though Hapi gets some points too.

It’s great that we can run a simple performance test before we pick a framework. Although when we have customers and a business relying on it, using local benchmarking tools isn’t a great substitute for application monitoring. Tools like Retrace can help you understand and improve your Node.js application’s performance characteristics.

Hapi: 4 
Sails: 1 
Restify: 3

Restify vs Sails vs Hapi: Final scores and thoughts

To end my initial thought experiment of what I would do if tasked with picking a framework from these three, I think I would choose Hapi. It seems to stand out from the other two frameworks, specifically in regards to its community support.

Restify follows close behind because of how well it performs and how easy it is to start using it. Plus, if I didn’t get too invested in Hapi’s framework-specific plugins, it wouldn’t be difficult to migrate my logic over to Restify. But when compared to Hapi, its community support doesn’t match up.

Sails can bootstrap some impressive features right out of the gate, but it’s less interesting to me because of the rigidity and the commitment to learning framework-specific nuances.

Assuming the community is flourishing and the performance meets my needs, I believe the ability to start quickly with a small piece of well-understood functionality is of utmost importance. The learning curve for Sails seems like a difficult pill to swallow in this regard. You could make the argument that it would scale better once you understand the paradigm, and you might be right. You have to make the best choice for you, your team, and your business. So the biggest takeaway is probably my initial statement: context matters!

One language for your project or two?

Let’s get the obvious comparison between Node.js and just about every other programming language out of the way to start. Node.js allows you to code in JavaScript on both the client (in the browser) and the server. This is a serious advantage for Node.js that’s difficult to replicate in other languages. JavaScript is the primary language of the web browser, so you’ll be writing client-side code in JavaScript or a language like it. Coding your app’s server in JavaScript simplifies your learning experience and unlocks the ability to share some code between the client and server. Sharing that code between the client and server can help you manage the complexity of your codebase and app.

Recent years have brought forward projects in Python that compile to JavaScript, aiming to provide this same flexibility to Python developers. One example is Transcrypt, which is actively developed. Young developers should be wary of jumping straight into a program like this while they’re learning. Learn to write standard JavaScript before writing code that will be compiled to JavaScript so you can spot common errors and learn to troubleshoot issues in your client-side code.

Scoreboard: Node.js 1, Python 0

Installing your runtime

Installing Node.js is a simple task, whether you use macOS, Windows, or Linux. For most users, it’s as simple as downloading an executable and double-clicking.

Installing Python is often more difficult. Python 2 comes pre-installed on macOS, but you shouldn’t use the installed version for your coding because it’s used by system libraries. Instead, you’ll need to install a new version alongside the existing version. Installing Python on Windowscan also be somewhat tricky. Many tutorials recommend installing a package manager like Chocolatey before getting started, which can be a bit of extra work. If you’re working on Linux, installing Python is no sweat.

Node.js is easier to use out of the box on two out of three platforms, so it scores another point here.

Scoreboard: Node.js 2, Python 0

Library management

Library management is a category in which both languages excel. Pip (which stands for “Pip installs Python”) provides tremendous library management for Python. The maintainers of Pip make sure that it’s fast, stable, and easy to learn in just a few minutes.

NPM (the Node Package Manager) provides package management for Node.js. NPM is one of the largest repositories of software libraries in the world. Like Pip, NPM is fast, well-documented, and a breeze to learn in an afternoon or less.

As your project grows, dependency counts usually grow as well. A good dependency manager saves hours of time and countless headaches.NPM and Pip are two of the best. Both languages score a point in this category.

Scoreboard: Node.js 3, Python 1

Environment management

If you only ever work on one project, environment management isn’t a concern. Most developers find that between work and personal projects, they need to support more than one code repository. When working with a package manager like Pip or NPM, managing more than one codebase can cause serious headaches. What if the version of a library you use for work is different from the version of a library that you use for your personal website? This is where environment managers come into play.

The lead environment manager for Python is virtualenv. Virtualenv is a powerful tool that can manage different Python projects, up to and including installing different versions of the Python interpreter itself. Virtualenv is one of the original environment managers, and it’s been actively maintained for more than a decade. As you’d expect, it’s rock-solid and very easy to learn.

Node.js has a similar tool to Virtualenv called nodeenv. Nodeenv is developed and supported by the same people who make Pip, which is a great recommendation for a software package. Nodeenv comes with a big caveat, though: you need to install Python to make it work. If you’re deciding on Node.js to avoid having to install Python on your computer, using nodeenv would defeat the whole purpose.

Scoreboard: Node.js 3, Python 2

Which is easier to learn?

On the surface, both JavaScript and Python are similarly structured. Both are imperative languages with object-oriented features. Both have terrific IDE support. Python has a barer syntax than JavaScript; the lack of curly braces around classes or functions stands out to most new developers. Python is also whitespace sensitive, meaning that how you indent your code matters. Whitespace sensitivity is a double-edged sword for newer developers. Making sure that your code is always well-indented and organized is an important skill to learn for a new developer, and Python requires you to do that. The dangerous side is that improperly indented code can easily break for no obvious reason, and as a new developer, troubleshooting an issue like this is challenging.

While JavaScript’s syntax is likely to be familiar to many inexperienced developers, Node.js introduces additional advanced topics. Node.js web apps are written in what’s known as an asynchronous, event-driven style, which can be difficult to wrap your head around at first. A new developer learning Node.js has a tall hill to climb to understand advanced concepts like why a call to the database might not have information when the developer expects it to. The event-driven architecture is a very powerful performance boost (we’ll talk about why in the next section), but it poses a real challenge for newer developers.

Additionally, JavaScript has a notoriously thin standard library. NPM is popular in the JavaScript landscape because many things that are standard in other programming languages aren’t included in a normal install of JavaScript. As a new developer, this poses a challenge. You’ll commonly be faced with tasks that are simple in other languages but have no similar tool in JavaScript. Python edges JavaScript slightly here, so it wins a point.

Scoreboard: Node.js 3, Python 3

Which one builds faster websites?

Asking which programming language is faster is a dangerous exercise on the internet! In this comparison, you’ll find little dissension, though. Node.js web apps are mostly faster than Python web apps. The reason is related to that event-driven architecture we talked about in the last section. If you haven’t read the link in the previous section (here it is again so you don’t have to scroll back), you should do that now to truly understand why. Node.js code doesn’t spend as much time waiting on network requests and database queries. This means that it does more work in less time, which means faster server responses and page renders.

Python does have the ability to build asynchronous, event-driven web apps. Modules like asyncio make writing asynchronous Python code similar to writing that kind of code in Node.js. Python doesn’t win a point here, though, because most major Python frameworks don’t have this built in.

Another performance advantage for Node.js is that it runs on the V8 JavaScript engine, which is the same engine used in the Chrome web browser. Google devotes a large number of developers to making V8 as fast as possible, which is good news for Node devs. Node.js is likely to continue to get faster over the next few years. Your web app could be faster in a year without you changing a single line of code! Node.js also has powerful tuning capabilities that boost your already good performance to another level.

Finally, it’s important to remember that just because you choose one language or framework, you’re not guaranteed a fast web app. Monitoring the real-world performance of your app through a tool like Retrace is critical to understanding how your app is actually performing for your users.

Scoreboard: Node.js 4, Python 3

Tallying it up

Looking at the scoreboard, Node.js holds a slight lead over Python, and I think that’s accurate. In 2019, both Node.js and Python are attractive options for building a new web app. As someone who’s just learning, you may find that Node.js has a pile of excellent frameworks to choose from. Python has similarly excellent frameworks in Django and Flask. Neither choice is a wrong one, and both languages have thriving communities. If it were up to me to choose which language I’d use to start a new web project, I would lean toward Node.js. But the most important thing is to start turning your dream web app into reality today. Get out there and get coding!

Your ability to effectively debug code becomes increasingly important as the scale of your codebase grows. This article will focus on the essential aspects of client-side JavaScript error logging to help polish up those debugging skills. Unfortunately, server-side error logging is beyond the scope of this article. Rest assured, though, there are plenty of best practices and tools, like Retrace, available to get you started there as well.

Here’s an overview of what I’ll be covering in this article:

• Client-side vs. server-side logging
• JavaScript’s built-in logging methods
• A step-by-step JavaScript logging example

Client-side vs. server-side logging

When you’re doing local development, you’ve got access to the console. This gives you the ability to recreate errors, peruse stack traces, interpret cryptic error messages, and otherwise debug to your heart’s content. When the page or app reloads, everything in the console disappears. Poof.

This is great during the development process. However, you don’t have access to those console messages once you’ve released your code into the wild and it’s running on users’ machines.

In this case, having some way to send your code’s various error messages from the client to a server you have access to would be beneficial. There are a plethora of tools available for such use cases, typically called logging frameworks, but this article won’t cover them in any depth.

Essentially what these tools do is collect any error messages that occur on the client, and package them up nicely. Once they’re properly bundled, they’re sent to a storage location that you have access to. Handy to have, but a bit complicated to cover here.

With that said, what follows are best practices to observe during that “development phase” of your product when you do have access to the browser console.

JavaScript’s built-in logging methods

You probably got comfortable with the console.log() function the first time you looked at JavaScript. Put it wherever you want in your code and it’ll spit out the contents of whatever you put between the parentheses, right?

It turns out there’s a whole array (pun intended) of methods on the console object that are super useful and often underutilized.

Message levels

As with many other programming languages, JavaScript has support for logging messages at various levels. They are as follows, with their associated method and a description of their output in the console:

• Plaintext—console.log() outputs unstyled text.
• Info—console.info() typically outputs text with a blue background.
• Warn—console.warn() typically outputs text with a yellow background.
• Error—console.error() typically outputs text with a red background.

These methods simply provide helpful visual cues for quick debugging in the console. Aside from the visual styling, they all work in exactly the same way.

Message grouping

Your code isn’t just a messy pile (hopefully). Your log output shouldn’t be either. Message grouping can help!

You can use the methods console.group() and console.groupEnd() to create collapsible chunks of log messages in the console. There’s even support for nested groups.

Take, as a quick example, the following code:

console.group("Group heading");
console.log("First line");
console.log("Second line");
console.log("Last line");
console.groupEnd();

This will give you something similar to the following in the console:

Organizing your log messages by grouping can help you quickly find the messages you care about without wasting time on scrolling or scanning.

Timing your code

There are a multitude of reasons why you might be interested in how long a particular process in your code takes. Fortunately, you don’t have to dig into any complicated third-party tools to get some basic timing functionality.

Take a look at the pseudo-code below:

console.time("Test process");
// Do some process here
console.timeEnd("Test process");

The call to console.time() starts a timer with the label “Test process.” Immediately following that, the process on the following line of code (imaginary, in this case) runs. Finally, a call to console.timeEnd(), with the same label of “Test process” passed to it, ends that particular timer.

How handy is that?!

Don’t let errors break everything

The people working to make JavaScript better are super smart. So, of course, they’ve implemented a tool for us to gracefully handle error-prone code.

Enter the try…catch…finally statement.

This statement allows us to enclose potentially error-producing code in a try block, catch and log an error if there is one, and continue on running our program in the finally block.

Here’s what it looks like:

try {
    // Code to try
} catch (e) {
    // Code to run if an exception (error) occurs
}
finally {
    // This code runs regardless of an error occurring or not
}

Using this pattern will allow you to effectively create error boundaries in your program so that the whole thing doesn’t crash due to a single error.

Logging with JavaScript: an example

To better illustrate the usage of the above utilities, let’s go through a (rather contrived) example. Here’s the code, with an explanation to follow:

console.time("Contrived example"); // Start the timer!

try {
    console.group("TRY BLOCK ACTIONS:"); // Create a console grouping
    console.log("Trying to reach server...")
    console.warn("It's taking awhile...."); // Use the console warn utility so we don't miss it in the console
    console.log("Still trying...");
    console.groupEnd(); // Close the "TRY BLOCK ACTIONS" grouping
    throw new Error("Can't reach server, sorry!"); // Throw an error to be caught in the catch block
} catch(e) {
    console.error(e.message); // Log the error thrown from the try block
} finally { // Block of code to execute regardless of errors
    console.group("FINALLY BLOCK ACTIONS:"); // Create another console grouping
    setTimeout(function() { // Arbitrarily delay code execution for the sake of timing
        console.log("Let's run some code independent of the server response:");
        coolFunction(); // Call external function
        console.log("Finally done with the example!");
        console.groupEnd(); // Close the "FINALLY BLOCK ACTIONS" grouping
        console.timeEnd("Contrived example"); // Stop timing the code and log the time taken to execute
    }, 900);
}

function coolFunction() {
    console.log("Hello from coolFunction");
}

The code starts by calling the console.time() method to begin tracking the execution time of the code.

Next, a try block opens up. In the try block, a new console group initiates with a call to console.group(). Plus, a few console.log methods and a console.warn method are called inside it to keep us updated on what’s happening in our code.

After “trying” for a bit, the group is then closed with console.groupEnd() and an error is thrown, which is caught in the catch block. It’s there that the error message is logged with the helpful console.error method.

Lastly, in the finally block, another console group initiates. Also, some more console.log() methods are called inside it, the group closes, and the code timing process terminates with a call to console.timeEnd().

So, what does all of this look like in the console when you run the code? Check it out:

Awesome!

You can expand and collapse the TRY BLOCK ACTIONS and FINALLY BLOCK ACTIONS groupings, see the warn and error color-coding, and see how long the entire process took. That’s powerful stuff.

What comes next?

As mentioned earlier, using client-side logging functionality effectively is only a piece (albeit an important one) of your overall development process. If you’re comfortable tracking down issues using the console on your development machine, you can step up your debugging game with some of the more advanced tools like logging frameworks and analysis products like Retrace.

To wrap things up, here are a few key takeaways to start writing better code today:

• Use console.log(), and its color-coded variations, liberally during development but make sure to remove them for production
• Use console.group() to streamline your logging activities and save time digging through console messages
• Optimize performance by using console.time() to identify processing bottlenecks
• Use try…catch…finally statements to minimize the potential for program-breaking errors

Now, take your newfound logging power and write incredible code. On to the next project!

The best way to understand how to performance test your application is to walk through an example.

You can use Node.js for many purposes: writing scripts for running tasks, running a web server, or serving static files, such as a website. Today, we’ll walk through the steps to test a Node.js HTTP web API. But if you’re building something else in Node, don’t worry—a lot of the principles will be similar.

The unique nature of Node.js performance

Before we begin, let’s take a quick look at one of the more unique characteristics of Node.js performance. We’ll need to have knowledge of these characteristics later when we run our performance tests.

What am I talking about?

The big consideration for Node.js applications is their single-threaded, run-to-completion behavior—facilitated by what’s known as the event loop. Now, I know what you’re thinking: that’s a lot. So let’s break this down a little so we understand what these mean.

Let’s start with single threading. Threading, as a concept, allows concurrent processing within an application. Node.js doesn’t have this capability, at least not in the traditional sense. Instead, to write applications that perform multiple tasks at once, we have the asynchronous code and the event loop.

The event loop

What is the event loop?

The event loop is Node.js’s way of breaking down long-running processes into small chunks. It works like a heartbeat: Every few milliseconds, Node.js will check a work queue to start new tasks. If there is work, it’ll bring these onto the call stack and then run them to completion (we’ll talk about run-to-completion soon).

By breaking tasks down, Node.js can multi-task, which is your substitute for threading. That means that while one task is waiting, another can start. So, rather than threading, we use async code, facilitated by programming styles like callbacks, promises, and async/await. Most of the out-of-the-box Node APIs have both a synchronous and asynchronous method of execution.

Okay, so maybe you’re wondering: what does all this techno-jargon have to do with performance?

Let me explain…

Node.js performance and the event loop

Imagine you’re building a Node.js application with two endpoints: one for file uploading, and one that fetches a user profile. The user profile API will probably be requested significantly more often than the file upload, and if it doesn’t respond quick enough, it’ll block every page load for every user—not good.

The user upload API is used infrequently. Also, users expect uploading of tasks to take time, but they’re a lot less forgiving with page load times. If we do not program with the event loop in mind, while the file is uploading, Node.js could end up hogging all the system resources and could block other users from using your application—uh-oh!

And that’s why you need to understand Node.js’s single-threaded nature. As we change our application, we need to consider this behavior. We want to avoid doing long-running tasks synchronously, such as making network requests, writing files, or performing a heavy computation.

Now we know about Node.js’s single-threaded nature, we can use it to our advantage. Let’s go step by step how you can set up, run, and analyze a performance test of your Node.js application to make sure you’re doing your best to leverage Node.js performance capabilities.

Step 1: Choosing Node.js performance test tooling

First, you’ll want to choose a tool that will allow you to run your performance tests. There are many tools out there, all with different pros and cons for Node.js performance tuning. One main thing to consider is that even though you’re testing a Node.js application if you’re going to performance test from the outside world across a network, it doesn’t matter if your performance test tooling is written in Node.js.

For basic HTTP performance testing, I like Artillery a straightforward performance testing tool written in Node.js. It’s also particularly good at running performance tests for API requests. Artillery works by writing a configuration file that defines your load profile. You tell Artillery which endpoints you want to request, at what rate, for what duration, etc.

A basic test script looks like this:

config:
  target: 'https://artillery.io'
  phases:
  - duration: 60
  arrivalRate: 20
  defaults:
    headers:
      x-my-service-auth: '987401838271002188298567'
scenarios:
- flow:
- get:
url: "/docs"

Here, you’re requesting Artillery’s website for a 60-second duration with 20 new users arriving at the URL.

Then, to run the test, you simply execute:

artillery run your_config.yml

Artillery will make as many requests to your application as you instructed it to. This is useful for building performance test profiles that mimic your production environment. What do I mean by performance test profile? Let’s cover that now.

Step 2: Create a Node.js performance test profile

A performance test profile, as above, is a definition of how your performance test will run. You’ll want to mimic how your production traffic does or is expected to, behave, if possible to do accurate Node.js performance tuning. For instance, if you’re building an event website, you’d expect lots of traffic around the time you release tickets, so you’d want to build a profile that mimics this behavior. You’d want to test your application’s ability to scale with large amounts of a load in a short amount of time. Alternatively, if you’re running an e-commerce site, you might expect even traffic. Here, your performance test profiles should reflect this behavior.

Leveraging multiple test profiles

A fun and interesting point to note is that you can create different test profiles and run them in an overlapping fashion. For instance, you could create a profile that mimics your base level of traffic—say, 100 requests per minute—and then mimic what could happen if you saw a lot of traffic to your site, say if you put out some search engine adverts. Testing multiple scenarios is important for thorough Node.js performance tuning.

Replicating large-scale distributed systems

I must take a second here to note something: When an application reaches a certain size, mimicking load in this fashion loses feasibility. The traffic volumes you may have could be so wild, unpredictable, or large in volume it’s hard to create a realistic like-for-like way of testing your application before release.

But what if this is the case? What do we do? We test in production.

You might think, “Woah, hold up! Aren’t we supposed to test before release?”

You can, but when a system gets to a certain size, it might make sense to leverage different performance test strategies. You can leverage concepts like canary releasing to put out your changes into production and test them only with a certain percentage of users. If you see a performance decrease, you can swap that traffic back to your previous implementation. This process really encourages experimentation, and the best part is that you’re testing on your real production application, so no worries about test results not mimicking production.

So far we’ve decided on our tooling, and we’ve created profiles that recreate our production, like traffic and workloads. What do we do next? We need to ensure that we’ve got the data we need to analyze our application, and we do that through Node.js performance monitoring and Application Performance Management (APM) tools. What’s an APM? Read on, and I’ll let you know!

Step 3: Set up your observability/monitoring

We don’t want to just run our performance test against our application and hope and pray. If we do, we won’t be able to understand how it’s performing and whether it’s doing what we think it should. So before we begin, we should ask ourselves questions like “For my application, what does good look like? What are my SLAs and KPIs? What metrics are needed to effectively debug a performance issue?”

If your app performs slowly, or different from what you expected, you’ll need data to understand why so you can improve it. All production applications worth their salt are using some form of observability and/or monitoring solution. These tools, often called APMs, allow you to view critical Node.js performance metrics about your running application.

Getting up and running with an APM

APMs come in different shapes and sizes, all with different features, price tags, security implications, performance, you name it. It pays to shop around a little to find the best tool for your needs. It’s these tools that are going to give us the insights and data we need when we run our Node.js performance tests.

So, if we know we should monitor our application—what exactly should we be monitoring?

Ideally, you want as much data as possible—but as much as we love data; we have to be realistic about where to start! The best place to start is with the following three areas:

• Aggregated logs—Application logs emit either implicitly by some libraries or explicitly by a developer for getting an insight into an application. Most aggregated log tools allow you to easily search and visualize your logged data. In our case, we could log out the performance of each of our APIs and plot them on a graph.
• Infrastructure insights—Your application will run on a host of sorts, so you’ll likely want to see all the data. If you’re running in the cloud, most providers give you this data (albeit in a crude form) out of the box. The data you’ll get from these tools will cover things like CPU and memory usage of your host, connection data, etc.
• Application monitoring—This type of tool usually sits within your application code and can draw insights about how functions are performing/being called, what errors we throw, etc.

Some APM tools, like Retrace, have all or most of these three features rolled into one, whereas others can be more specialized. Depending on your requirements, you might want one tool that does everything or a whole range of tools for different purposes.

Tooling tailored to Node.js

On top of tools, we can also include other Node.js-specific tools and profilers, like flame graphs, that look at our function execution or extract data about our event loop execution. As you get more well-versed in Node.js performance testing, your requirements for data will only grow. You’ll want to keep shopping around, experimenting, and updating your tooling to really understand your application.

Now we’ve set up our tooling, got realistic profiles for our performance, and understood our application performance, we’re nearly ready to run our tests. But before we do that, there’s one more step: creating test infrastructure.

Step 4: Create Node.js performance test infrastructure

You can run performance tests from your own machine if you wish, but there are problems with doing this. So far, we’ve tried really hard—with our test profiles, for instance—to ensure that our performance tests replicate. Another factor in replicating our tests is to ensure that we always run them on the same infrastructure (read: machine).

One of the easiest ways to achieve a consistent test infrastructure is to leverage cloud hosting. Choose a host/machine you want to launch your tests from and ensure that each time you run your tests it’s always from the same machine—and preferably from the same location, too—to avoid skewing your data based on request latency.

It’s a good idea to script this infrastructure, so you can create and tear it down as and when needed. They call this idea “infrastructure as code.” Most cloud providers support it natively, or you can use a tool like Terraform to help you out.

Phew! We’ve covered a lot of ground so far, and we’re at the final step: running our tests.

Step 5: Run your tests!

The last step is to actually run our tests. If we start our command line configuration (as we did in step 1), we’ll see requests to our Node.js application. With our monitoring solution, we can check to see how our event loop is performing, whether certain requests are taking longer than others, whether connections are timing out, etc.

The icing on the cake for your performance tests is to consider putting them into your build and test pipeline. One way to do this is to run your performance tests overnight so that you can review them every morning. Artillery provides a nice, simple way of creating these reports, which can help you spot any Node.js performance regressions.

Now you have lightning-fast Node.js

That’s a wrap.

Today, we covered the event loop’s relevance for the performance of your JavaScript application, how to choose your performance testing tooling, how to set up consistent performance test profiles with Artillery, what monitoring you’ll want to set up to diagnose Node.js performance issues, and, finally, how and when to run your performance tests to get the most value out for you and your team.

Experiment with monitoring tools, like Retrace APM for Node.js, make small changes so you can test the impact of changes, and review your test reports frequently so you can spot regressions. Now you have all you need to leverage Node.js performance capabilities and write a super performant application that your users love!

If that’s what you’re looking for, you’re in the right place!

For me, logging was always a somewhat mystical and frustrating idea. I could grasp the concept that you wanted to output information about your system… but the details on what to log and how to log eluded me.

The problem was when I turned to the internet for answers, I could only find tutorials that would show me how to log to a file. These articles rarely explained the full picture: What do you log? When do you log? How much do you log? Where do you put logs? What format should you log? Am I doing this whole logging thing right?

I did not understand. I still had so many questions. And I guess you must too, or you wouldn’t be here! Well, you’re in luck—these questions are exactly what we will answer today.

Today, we will be looking at Winston, the most popular logging library in Node.js, and why it’s so popular. We’ll dive into the ins and outs of why to use logging and how and what to log in a practical way. And after that, we’ll round off with some best practices for structuring your Node.js application so you can write easy, elegant, and clean logging code, using the Express framework.

Sound good to you? Let’s get to it.

Why bother with logging?

The first, most important question is, “Why bother logging at all?”

Let me put it simply. Logs are a simple way of persisting data about your application so you can view this data for analysis later. A great use case for logging would be if, for example, you have a bug in your system and you want to understand the steps that led up to its occurrence.

When you’re working on smaller systems, this can seem like overkill, especially if your application isn’t that big. But as an application grows in size—or possibly multiplies into many smaller systems, perhaps by using microservices or functions—logging becomes even more important because of the increased complexity.

At that point, you will definitely want to have logging tools in place. Preferably, a tool that can integrate errors and logs so you have all the context you need. Tools like Retrace can give you those insights and much more.

What is Winston Logger? Why should I use it?

Today we’re talking about logging within the context of Winston.

If you’ve written JavaScript before, you’ll be used to console.log, the built-in method of logging output. For Winston, the first question you might have is, “What’s wrong with console.log?”

Nothing is wrong with console.log, per se. But Winston gives us more powerful features than the humble console log, such as

• Streams: Winston uses Node.js streams, which is a performant way of chunking up data processing—for instance, data manipulation on large amounts of data. Streams break tasks down into small, manageable chunks so it’s easier for your Node.js system to handle. Curious why? Read up on streams and the event loop.
• Transports: Logs need to go somewhere. By default, console.log goes to your standard output file. However, you may also want to stream your logs to a central location, or store them in a database for querying later. Winston allows you to do that easily with a concept called transports. What’s also nice about using Winston is that you can have as many transports as you like.
• Formatting: Your regular console.log, by default, only deals in strings. We’ll come back to why this is problematic later. But Winston has some advanced features for formatting log code before stashing it away. For example, Winston offers JSON formatting, coloring log output, and the ability to fiddle with formats before they’re posted off to your end log locations.
• Levels: Winston adds another interesting layer, which is log levels. Log levels are metadata for logs. In plain English, this translates to data about data. Log levels tell you the severity, ranging from as severe as a system outage to as small as a deprecated function. The reason for having log levels in the first place is so you can quickly see which logs need attention. Log levels also allow you to configure environments to log the correct amount of data, with amounts of detail.

That’s just a few reasons you’d want to use Winston over the humble console.log.

We’ve talked a lot about the abstract concepts surrounding Winston. So let’s introduce it and look at the syntax.

Getting started: How to set up Winston logging

Let’s quickly set up a basic logging example using Winston.

Don’t worry, it’s not too much. And we’ll be building on top of this basic example as we go.

If you want to follow along, start by installing Winston via npm.

npm install winston --save

Then create the following logging code and save it into a file (of any name).

const winston = require('winston');
const logger = winston.createLogger({
    transports: [
        new winston.transports.Console()
    ]
});

logger.info('What rolls down stairs');
logger.info('alone or in pairs,');
logger.info('and over your neighbors dog?');
logger.warn('Whats great for a snack,');
logger.info('And fits on your back?');
logger.error('Its log, log, log');

Then all you need to do is run the file with:

node yourFileName.js

And voila!

{"message":"What rolls down stairs","level":"info"}
{"message":"alone or in pairs,","level":"info"}
{"message":"and over your neighbors dog?","level":"info"}
{"message":"Whats great for a snack,","level":"warn"}
{"message":"And fits on your back?","level":"info"}
{"message":"Its log, log, log","level":"error"}

Okay, so while this is a simple example, it raises a few questions. What does createLogger do? And why is the output formatted like that?

Let’s look at the createLogger method first. The createLogger method is one that takes a config object and returns a logger object with several methods bound to it which are your logging levels (more on this later). That means we can use this object and the logging levels, for instance, to create our example log output.

As you can see, Winston is using JSON by default. It’s also putting our message into a property (of the same name) and adding a level property. This is what we want: structured log data. Again, more on this later.

So there you have it! A simple Winston installation.

But wait—there’s more!

I couldn’t leave you hanging like that, as I know you’ll have other questions, like, “Why JSON?” “What are the best practices for logging?” “How do I structure my log code using Winston?”

Let’s talk about those things next.

5 Winston logger best practices

1. What should you log?

The answer to what you should log has a short answer and a long answer.

Let’s start with the short answer:

Log as much data as you reasonably can.

Okay, that’s simplistic. What do I mean?

With logging, it makes sense to log as much data as you can. The richer and more structured your log data, the better you’ll be able to visualize and act on that log data.

Learn more about structured logging and why developers need it.

But despite this, there are no “right” things to log. What’s important for you to log really depends on your situation.

But to give you a few good starting points, log data such as

• Timestamp or log entry.
• Timing data for your request.
• Request endpoint data, such as paths: “/users” or verbs: GET, POST.
• IP of the requesting party.
• Correlation ID (if you’re building a distributed system).

You get the idea.

I should note that while you should log as much as you can, there’s an exception. You don’t want to log any sensitive data, such as passwords, secret keys, or personal data. Remember, logs are data still, so they’re still governed by the same rules and laws as any other data. So be careful what you’re logging.

Okay, I’ve told you to log lots of rich data—the kind that tells you a lot about your application—which leads us nicely onto the next part.

How should we log? In what format, and why?

2. How should you log?

With logging, the format you pass is important. If there’s one big thing you should take away from this article, it’s this:

Build logs for machines, not humans.

By nature, machines are far better at deciphering large amounts of data. And if you’re doing even a moderate amount of logging in a small application, you’ll be drowning in logs.

JSON is the default standard for logging in Node.js and is a great option with Winston. Most logging tools also support JSON out of the box, so many will also parse your JSON logs when they’re put into your APM. This is great as it allows you to do things like visualizing based on properties (and even nested properties).

For the curious, we should note that you can log in any format you want—strings, delimited, or a custom format. However, custom format should be avoided where possible. A lot of logging tools will let you parse custom formats. You must specify the rules for every different format, and this can be time-consuming and costly.

3. How to structure log code

So now you’ve got your head around why you’d want to log in the first place, what format you want to be logging in, and how to get up and running. Next, we need to ask another question: how should you structure your log code?

In structuring log code, you want to be logging consistently. Below are techniques in Node.js to help keep your log structures consistent.

Keep things tidy with log namespaces

One pattern I like is passing log namespaces. Messages are useful for humans who want to understand the error, but they can be hard to search in a log aggregation tool.

With namespaces, you can also create your own namespace dictionary, which allows you to define which namespace patterns you want and reject any calls to logs that don’t conform to your namespace dictionary patterns. That makes it much easier to enforce clean logging standards throughout your application.

A logging namespace implementation could look as simple as this:

logger.info('server.endpoint.get.users.getusersfromdb.format');

Here, you’d build up the hierarchy of your application so you can easily see the point where an error occurred. The above example shows us that the log originated in our server, in a GET endpoint called “/users” while it was formatting a response retrieved from the database. Namespaces just make it easier to recognize and locate your logging from within your application.

Logging in the facade pattern

The facade pattern is a design pattern that hides more complicated implementation details. Why do I mention the facade pattern? Because you can leverage it to write more elegant logging code that’s put in place.

I know things like design patterns can seem abstract. So to help those who need a concrete example, let’s introduce one. To try to keep it realistic, we’re going to introduce Express, a common framework in Node.js for creating web servers.

If you want to, try out the following example:

npm install express --save

And add the code to the bottom of your existing logger file.

const express = require(‘express’);
const app = express();
const port = 3000;

const handler = (func) => (req, res) => {
    try {
        logger.info('server.handler.begun');
        func(req, res, logger);
    } catch(e){
        logger.info('server.handler.failed');
        res.send('Oh no, something did not go well!');
    }
};

app.get('/success', handler((req, res) => { res.send('Yay!'); }))
app.get('/error', handler((req, res) => { throw new Error('Doh!'); }))
app.listen(port, () => console.log(`Example app listening on port ${port}!`))

As you can see, the above code is wrapping your regular Express handler with additional functionality. Open a browser window and enter these URLs to illustrate your log outlet.

http://localhost:3000/success
http://localhost:3000/error
http://localhost:3000

This allows you to log your application code in a way that’s consistent across your application. Here, we’re using functional programming in Node.js by passing the handler function as a callback to our handler function, allowing us to execute the function within the context of a try/catch. All of this means we can apply error handling in a way that makes sense.

4. How to access logging middleware

Building on top of the previous example of the Express handler, we can leverage Express middleware to implement logging between the functionalities of our application.

Express middleware is a way of augmenting Express regular handlers with additional functionality that’s intercepted. Middleware intercepts requests for purposes such as authentication—or in our case, logging!

Middleware is useful. Because it can be passed as a function to an existing endpoint, it’s very flexible and can be called on all endpoint accesses. Or middleware can be composed in arrays to create collections of middleware to apply. For logging, this can make life a lot easier. Having a simple access logging middleware is definitely a great starting point if you’re using Express. There is additional Express logging middleware, Morgan and/or Bunyan, that may be used, even along with Winston.

Try adding the following above your previous Express handlers:

app.use( (req, res, done) => {
    logger.info(req.originalUrl);
    done();
});

Now your application has some nicely abstracted logs using the facade pattern, and a nice intercepting middleware that will log server access to your Express application: Nice! Now try those URLs again to see the logging output now after the change.

5. How to centralize logs for visualization, searching, and troubleshooting

If a log is logged, but no alert is triggered or it’s visualized, was it logged at all?
— philosophical Node.js developer (contrived)

The real value of structured logs is when you run it through a centralized logging platform like Retrace. Retrace allows you to view all logging messages in an inline view across all apps, servers, and in all environments. It can give you more contextual insights to help you troubleshoot issues.

You can easily pinpoint errors by applying filters and fields to weed out unneeded information. You can isolate the logs you are looking for by specifying the environment, server, or application. You also can search for terms in your log messages.

Retrace supports both the Winston logging framework and logging directly to the Stackify API. A simple configuration change is all that is needed. See our documentation on how to configure Node.js logging.

Hopefully, that was a useful introduction to Winston and some best practices in Node.js for how to structure your code to keep it clean and consistent with the facade pattern and logging namespaces.

You become better at logging with practice. Write to your log files and try to access them later, with a tool such as Retrace to debug and understand your system—you’ll soon become familiar with what’s useful and what’s not.

Just remember…

• Structure your logs for machines.
• Enrich log entries with plenty of useful data.
• And last but not least: visualize them!

I wondered what it was, and where it came from, and why it wasn’t declared in the file. What was this magic?

Today we’re going to find out. We’ll demystify this somewhat odd-looking feature of Node.js. By the end of this article, you should be comfortable not only using the syntax, but also understanding what it actually does under the hood. To round it all off, we’ll go through some best practices for using module exporting to break down and give your application some great structure.

Sound good to you? Let’s dive in!

What’s a module, anyway?

The first question to answer when we’re discussing module exports is the first part, the module. What is it? And why should we care about it?

In simple terms, a module is code that we group together for the purposes of sharing and reuse. Modules, therefore, allow us to break down complexity in our applications into small chunks. This can help with understanding the code right down to finding and fixing bugs.

Fairly straightforward, right?

Now that you know what modules are, let’s see how they’re used—specifically—in Node.js.

Modules in JavaScript explained

Before we get to how modules are handled in Node.js, I want to take a moment to clarify the different conflicting and confusing alternate module systems in the JavaScript ecosystem.

You might’ve heard of some of them: CommonJS, AMD, RequireJS, UMD… Ugh, it’s all very confusing. Which one should you use and when?

The best way to understand the module system is to see how it’s evolved over time, and why. So let’s do that first.

Javascript modules started in your web browser

Originally JavaScript started in the browser—there was no module system at all.

Why? Because JavaScript was a small language intended to perform only small tasks, not build full-blown applications. A module system would have been overkill, so JavaScript simply didn’t have one!

But, as JavaScript apps grew in complexity, developers started to feel the absence of an ability to break down applications, especially developers using other languages with existing module systems. We started to experiment with all kinds of weird hacks with anonymous functions, and built big global objects that contained all our code in one huge spaghetti mess.

At this point, RequireJS and AMD (asynchronous module loading) entered the scene. They attempted to unify how modules can be achieved in JS. Specifically, they tried to incorporate just-in-time module loading, which led to drastic increases in complexity for these pseudo-modules.

Try Stackify’s free code profiler, Prefix, to write better code on your workstation. Prefix works with .NET, Java, PHP, Node.js, Ruby, and Python.

Javascript modules with Node.js

When Node.js was invented, modules and code encapsulation were high on the priority list. The creators of Node.js were keen for it to not suffer the same fate as the browser by having a big, dangerous global scope. So they implemented Node.js with a module specification called CommonJS (which is where you get the module exports and require syntax from).

To make matters more complicated, though, you can also use the soon-to-be-implemented JavaScript module syntax. At the time of writing, this is still not yet supported in Node.js but can be implemented with a transpiler, like Babel, that converts it back to CommonJS format. (We’ll save this native syntax for another article.)

So which module system is best?

We’ve discussed a few existing module syntaxes: AMD, CommonJS, and even native JavaScript modules. But which one is best? And why would we need to use CommonJS?

The answer is: It depends.

AMD is useful in the browser for performance optimizations. In Node.js, CommonJS often makes simplistic sense while JavaScript modules still require a pre-compiler. For both, though, native JavaScript modules are a good choice. That’s because, even if you’re pre-compiling now, it’s likely that sometime in the very near future you’ll be able to whip all your pre-compilation steps out.

This doesn’t seem like the greatest of answers, I know.

But there is somewhat of a solution for software authors, and it’s called UMD (a Universal Module Definition). UMD allows a JavaScript module to be compatible across all the different module formats. If you’re curious how UMD works its magic, check out this article. You’ll see it’s done with some pretty ugly-looking if-statements but the outcome is still the same, universal module usage.

Okay, by now you’re probably thinking, Why does all this talk of different modules matter? And how does it all relate back to module.exports? Let’s get to that now!

What are module exports?

As we said, module.exports are part of the CommonJS specification. But what exactly is it?

Module exports are the instruction that tells Node.js which bits of code (functions, objects, strings, etc.) to “export” from a given file so other files are allowed to access the exported code. (Don’t worry, we’ll cover importing code in the next section.)

To understand modules in Node.js, I like to imagine all my modules written together in one file (not as modules), and then imagine what code I’d need to make that happen. The code would look like each module wrapped in a function and given an argument, which is the current module.

Spoiler alert: Modules wrapped in functions is pretty much what happens under the hood.

But why does our module wrapped in a function even matter?

Because the module’s object is simply an argument—an object, in this case—to our module that we can manipulate as we please. Below is an example of how that module object looks:

{
    id: '.',
    exports: {},
    parent: null,
    filename: '/test.js',
    loaded: false,
    children: [],
    paths:
    [
        '/Users/lbichard/Desktop/node_modules',
        '/Users/lbichard/node_modules',
        '/Users/node_modules',
        '/node_modules'
    ]
}

As you can see, the mystic modules value is just an object passed into our module. We can then push to the exports object any values we wish to export from our current module.

You can also see above how exports is a subproperty on our module object. Whatever code we now apply to the exports property will become the export of our module. When we require our module in another file, it will get the value of that exports property.

module.exports.stringProperty = "I love NodeJS";
console.log(module);
// outputs ->
{
    id: '.',
    exports: { stringProperty: 'I love NodeJS' }
    ...
}

Note: By default, exports is an object, but it can also be a function, number, string, etc.

But what about require?

To understand modules, we have to understand require, too.

There’s no real sense in exporting functionality if we’re not consuming it elsewhere.

Require is a function we can use to import other modules, and it looks like this:

let model = require('./model.js');

Require will search for modules using the following rules:

• Is there a core module with the required path? Yes, return it.
• Is there a node_modules package with the name of the path? Yes, return it.
• Is there a file (or directory!) with the name of the given path? Yes, return it.
• Otherwise, throw an error.

As you can see, require is used to pull in different packages by their names or file paths.

But what if we require a module multiple times?

Requiring a module multiple times

A question I get a lot is this: “If we import the same module in two files, will we get the same object reference?” In short, yes. But the longer answer is “It depends.” Node.js will cache requests for a given module to save time later. But, you can’t rely on this functionality, as sometimes the caching system doesn’t work as expected (for reasons we won’t go into in this article).

How to structure your module exports

So now you know that you can apply different bits of code to your module exports object. But we never said specifically how you should structure your files. It can be a little confusing, as you’ve got a lot of flexibility. Do you define your properties as you go? All at the end of the file? What’s the standard?

We’ll answer these questions now.

Exporting as you go vs. at the end of a file

Knowing we can apply properties to our exports object begs the question: When should we do this?

The answer is: It’s totally feasible to apply properties throughout your module, as follows:

module.exports.getUser = () => {
    // Code here
}

module.exports.getUsers = () => {
    // Code here
}

If you console-logged this as an import, it would return the following:

{ getUser: [Function], getUsers: [Function] }

An important point to note here is because we used the fat arrow function, our functions are anonymous (which can be problematic when trying to decipher stack traces).

For this reason, many Node.js developers favor the following pattern:

function getUser() {
    // Code here
}

function getUsers() {
    // Code here
}

module.exports = {
    getUser,
    getUsers
}

This would output:

{ getUser: [Function: getUser], getUsers: [Function: getUsers] }

This gives us function names and documents the API clearly at the end of the file.

All told, this is a common pattern for JavaScript developers and is called the revealing module pattern.

Mastering modularized Node.js

This post hopefully gave you an introduction to modules and exporting in Node.js. I also hope it cleared up some of the mysticism around module exports—it’s not really all that magical. Simply keeping your files separate and cleanly documenting your code through good structure will help you and your team be more productive when writing Node.js code.

Remember: Module.exports is simply an object that you assign properties to, and that object gets passed to your requiring file. Be sure to define your exports synchronously, and as always… keep it simple!

If you need help improving and monitoring the performance of your Node.js applications, be sure to check out Retrace, Stackify’s industry-leading APM tool.

As you know, there is no limit to perfection, therefore developers are working continuously and creating numerous frameworks for Node.js development. These frameworks will further enhance the development of web applications. Frameworks actually enable developers to grow their applications. They have the ability to automate different repetitive processes with the help of libraries, templates, and reusable components.

In this article, you will come to know about the best frameworks for Node.js development. We will provide you with a list of frameworks that are popular and considered to be the best. These frameworks include Sails.js, Hapi.js, NestJS, LoopBack, Derby.js, Mean.io, Total.js, Mojito, and Koa2.

Top Node.js frameworks

Sails.js

Sails.js can be viewed as the most popular real-time framework that is based on MVC (Model View Controller) pattern. It was released in 2012 as free and open source software under the MIT license. It is a cross-platform web application framework written in JavaScript. It was mainly developed to create custom and business-oriented Node.js applications. Some important points about Sails.js are:

• Commonly used while implementing data-driven APIs in order to create real-time chatting applications, dashboards, and games.
• Works well with other front-end development platforms like Angular, Backbone, React, Android, iOS, Windows, Java and many others. Hence developers can choose the toolsets of their choice.
• Ability to support Grunt modules such as LESS, SASS, Stylus, CoffeeScript, Pug (formerly Jade), and Dust. Therefore it is considered ideal for creating browser-based applications.
• Incorporates waterline.js, which further provides support for an object-relational mapping interface and database solutions. This helps developers in avoiding trouble while configuring several database queries.
• Implements Express.js in order to manage HTTP requests.
• Extensively used in the development of websites. For instance, the website of Verizon, which is a US-based telecommunications company, is developed using this framework. Another implementation of this framework can be viewed on the website of Detroit Lions, an American football team.

Hapi.js

Hapi.js is an open-source, lightweight, and high-performance framework for creating web applications. This framework was designed by the team of Walmart Labs and that team was led by the Eran Hammer. They designed it with the intent of directing more traffic towards their Black Friday event. Black Friday was among the busiest days for online shopping in the United States.

Initially, Hapi was developed using the Express framework, but there were so many limitations in the design due to which it was not able to deliver output regarding some particular requirements. Hence Walmart created Hapi as an individual and stand-alone framework. Some important points about Hapi.js are:

• Allows you to create static websites since it has built-in support for databases such as MySQL, MongoDB, and PostgreSQL
• Easily implemented with any of the available front-end development frameworks such as React, Angular, and Vue.js.
• Can be implemented as an API server, a website server, and an HTTP proxy.
• Can be used to design RESTful and real-time web applications as well as services.
• Still very popular and hence implemented by several websites including Disney, Concrete, PayPal, Walmart, and many others.

NestJS

NestJS is a server-side application framework that is new to the list of Node.js frameworks. It is considered as the gateway to the world of advanced engineering concepts including microservices architecture, event sourcing, and domain-driven design. It was designed with the intent to support server-side scripting and create server-side applications.

The coolest feature of this framework is that it implements TypeScript, which is a superset of JavaScript. Some important points about NestJS are:

• Modular structure through which you can easily divide your code into separate modules. Using this structure, you can simply use external libraries.
• Contains an in-built dependency injection container (DiC).
• Supports modularization according to which every logical part (module) will exist within the region of the same domain.
• Eases the process of testing due to the presence of features like DiC and mModularization.
• Allows developers to create extensible and loosely-bound software solutions.

LoopBack

LoopBack is a powerful framework that comes with a default API explorer. It enables the framework to get connected with a number of back-end resources. This framework is designed by the team of Express.js. LoopBack also provides support for several databases such as Oracle, MongoDB, and SQL.

Due to its powerful features, it is implemented by the DA-14 team while creating Cosmunity (a social media app). You can also find its implementation in the GoDaddy (US-based domain registrar and web hosting provider), and the website of Symantec company (developer of cyber-security solutions).

Some important points about this framework are:

• Ability to decode data model definition and design new end-to-end RESTful APIs that further helps developers while setting predefined roles at the user, role, and application levels.
• With the help of Node Package Manager (NPM), users can easily create dynamic APIs in their application.
• Using dynamic APIs, performance of dynamic server-based applications can be improved to a great extent.
• Offers multiple additional components for file management, 3^rd party login, OAuth2, and storage providers etc.
• Runs on-premises or in the cloud.
• With this framework, you can use Android, iOS, and Angular SDKs in order to design new client applications.
• Creates REST APIs using the CLI tool, API explorer, models based on a particular schema etc.
• Can quickly connect devices and browsers to data and services.
• Easy and simple-to-use authorization and authentication setup.

Derby.js

Derby.js can be defined as a full-stack framework that is based on the MVC pattern and is widely used for modern web applications. It has the ability to work well with the development of client-side and server-side applications. Most developers use this framework to create real-time mobile as well as web applications.

Initially it only contains a limited number of standard Node.js modules. But now you can easily add additional third-party modules in order to design and develop a good quality web application. Some important points about this framework are:

• With the help of its data synchronization engine Racer, you can facilitate real-time concurrency and data synchronization between browser, server, and database of the application (or client and server).
• Allows you to organize your code into components using designer-friendly HTML templates.
• Provides support for an online community with which people can connect and ask their queries or questions related to Derby.js.
• With the server rendering support, it ensures good support for search engine and immediate page loads.

Mean.io

Mean.io is another powerful, free, open-source and full-stack framework that is used to build dynamic websites and web applications. It incorporates all four components of the MEAN Stack i.e. MongoDB, Express.js, Angular, and Node.js. Along with these components, it also includes some other important web development tools such as Babel and GraphQL. In simple words, you can say that Mean.io provides you a complete toolset for web development.

Some important points about Mean.io framework are:

• With the help of Mean.io, you can develop applications of any size and complexity level. As it includes all the components of MEAN stack, it is very effective and well known in the entire developer community.
• There are a lot of websites and applications that are built using the Mean.io framework.
• Provides almost all the important things that are required when starting application development.

So, don’t wait anymore. Download and install it right now to start your journey of becoming a Node.js developer.

Total.js

Total.js is a server-side framework based on the MVC pattern. It is also best suited for the development of web applications. If we talk about the compatibility feature of this framework, then it is very much flexible and works well with most of the databases. For instance, MongoDB, MySQL, PostgreSQL, etc.

It is also compatible with front-end development tools including React, Ember, and Angular. Some important points about Total.js framework are:

• Capable of creating server-side and client-side applications without having any dependencies.
• Does not require high-performance CPU and huge memory blocks. It can simply work on ARM architecture.
• Provides support for events like WebSocket and Server-Sent.
• Supports SMTP mail sender, localization, media streaming, great view engine, themes etc.
• Suitable for faster development, solid stability, and higher performance in relatively lower costs compared to other development frameworks.
• Supports classic routes, dynamic routes, and regex routes. Apart from this, you can also create custom routes in order to handle dynamic content, files or WebSocket events.

Mojito

Mojito is a popular and commonly-used Node.js framework written in the JavaScript language and based on Yahoo!Cocktails, which is a well-known mobile application development platform created by Yahoo. It is designed by Ric Allinson and is based on an MVC framework, and hence has multiple powerful features such as:

• As JavaScript is used for both client and server components, it can run on both client and server sides of an application.
• Offers a very effective way for data fetching.
• Supports local development environment and tools.
• Has amazing features like unit testing.
• Huge library for simplifying internationalization and localization.
• Advantages of Mojito include single language, run-time environment, and Internationalization.

Koa2

Koa2, the latest version of Koa framework, is developed by the team of Express.js. It is also based on MVC framework. Koa2 has a modular structure and lightweight framework. It has better customization support. It implements generators that encourages it to be good at error-handling. It is widely used to create more robust web applications and APIs. It is created using the ECMAScript 6 or ECMAScript 2015 specification.

Normally while working with Node.js, programmers have to write additional code in order to stream and close a file, but Koa2 has removed this issue. It directly passes the file instead of streaming it. It can easily determine and understand the operation required by the client through HTTP methods such as GET, POST, PUT, and DELETE.

Conclusion

So far we have discussed a lot of Node.js frameworks. Let us have a look at how to select any framework and the factors that one should keep in mind while choosing a framework.

Some of the important factors are:

• Availability and completeness of documentation
• Availability and size of the community
• Open issues on GitHub
• Different types of issues it can solve
• The flexibility of the framework
• The complexity of the framework
• Compatibility of the framework with other tools you are planning to use in the future.

All these frameworks are just a way to enhance and sharpen the future of web and application development technology. There are so many frameworks that work well with Node.js but they are not as popular as Hapi.js, Sails.js, Koa.js, etc. These frameworks help in bringing the latest innovations into the modern tech-savvy world. Hence the development of more complex and function-loaded applications has become possible with such powerful and amazing frameworks.

Monitor your Node.js applications with Stackify’s Application Performance Management tool, Retrace.  Gain code level insights into your application with server health metrics, error-log integration, APM.  Start your free, two week Retrace trial today.  

Software development is continuously evolving with the emergence of new technologies, trends, and programming languages. But with the implementation of Node.js and its modules, the development of applications has simplified a lot. The best thing about Node.js is that it allows developers to create an application on both the client and server at the same time.

Today we will introduce you to some of the popular and commonly used developer tools for Node.js.

1. Express.js
2. Socket.io
3. Meteor
4. Keystone
5. Koa.js
6. PM2
7. Electrode.js
8. Babel
9. Broccoli
10. Webpack

1. Express.js

Express is a powerful and flexible Node.js web application framework that offers an effective set of features for creating mobile and web applications. It also enables users to create a robust API in a much simpler and easier manner. With the combination of Node.js and Express.js, you can easily design an entire website. Node.js will help you to develop the server part, while the applications can be published over the website using Express.js. It contains several powerful features such as the ability to integrate database, simplified multiple routing, and template engines in order to develop powerful and robust applications.

2. Socket.io

Socket.io has the ability to facilitate bi-directional and event-based communication in real-time. It is among the quickest and most reliable real-time engines. It provides real-time analytics along with counters, logs, and charts. It is also suited for most chatting applications and widely implemented by companies like Microsoft, Zendesk, Trello, and some small start-ups as well. It offers much better debugging, scalability, integration, and binary support. It simply speeds up everyday work and is easy to use for both novices as well as experienced programmers.

3. Meteor

Meteor can be defined as a framework that is based on Node.js. It has the potential to script cross-platform code including Android, iOS, and web. It is integrated with MongoDB and can be easily implemented with any JavaScript UI widget library. This tool has the ability to shorten 1000 lines of code into just 10. You can develop faster and easy-to-use applications with this platform as compared to any other. You can do your work seamlessly on this Node.js tool including accessing database to server business logic to rendering to the client.

4. Keystone

If you are looking for the easiest ways to learn and start developing applications with Node.js, then Keystone is the perfect place for you. Keystone, based on Express, is an open source and full stack framework. It uses MongoDB as the database. It is a better option for creating database-driven websites, applications, and APIs in Node.js. The coolest feature of this tool is its auto-generated user interface with which you can easily handle your website. Both Express and MongoDB together provide a robust CMS framework. So, download this tool now to start learning how to code in Node.js.

5. Koa.js

Koa.js is a next generation web framework for Node.js. It is designed by the team of Express. Within a few years, it has proved to be more expressive, smaller in size, and robust especially for creating web applications and APIs. It requires Node v7.6.0 or higher for ES2015 and async function support.

It does not depend on middleware, unlike other similar frameworks. It has built-in plugin packages that provide support for operations like routing, compression, caching etc. It also has the ability to remove the callbacks and reduces the errors.

6. PM2

Whenever we talk about the easiest and simplest developer tools that are used in Node.js, PM2, one of the well-known names, comes in mind. It actually serves as a process manager, especially for Node.js applications. It comes with a set of features that are ideal for a production environment. It also has support for the community of developers and enterprises from all over the world. Its list of features includes the following:

• Behavior configuration
• Source map support
• Container integration
• Watch & reload
• Log management
• Monitoring
• Max memory reload
• Cluster mode
• Hot reload
• Development workflow
• Startup scripts
• Deployment workflow
• PaaS-compatible
• Key metrics monitoring

It has the ability to monitor and reload the application without any downtime in case of a sudden crash. The finance software companies like Intuit, and the online payment gateway PayPal use PM2.

7. Electrode.js

Electrode.js is a powerful developer tool created by WalmartLab. This tool is widely popular and suitable for React.js and Node.js applications. It’s not only a set of best practices, standardized structure, and modern technologies – it also includes Electrode Explorer and Electrify. This tool will ensure the reusability of the components, good performance, and deployment of the applications to the cloud. The user of any skill level can easily learn and perform coding practices. Try installing and working on it.

8. Babel

Babel can be viewed as a toolchain that is widely implemented in order to transform ECMAScript 2015+ code into a backward compatible version of JavaScript. It is commonly used as a front-end development tool. It also provides support for JavaScript latest version.

Let us have a look at some of the interesting and powerful features of Babel. The main features of Babel are listed below:

• Ability to transform the syntax. It also tries to use the least code as possible.
• Supports features like polyfill and source code transformations.
• Offers support map so that you can debug the code easily.
• Does not contain any built-in plugin. You can create your own plugin and then use it.

9. Broccoli

Broccoli can be termed a Node.js development tool that is based on the ES6 module. It is a fast, reliable asset, supporting constant-time rebuilds and compact build definitions. The build specification lies in the Brocfile.js file in the project root. You can easily use this tool. Click on the link below the image to download it from the GitHub.

10. Webpack

Webpack is widely used along with Node.js as it has the ability to bundle and serve assets much easier and faster than other development tools. It actually simplifies the overall process of deployment of applications and makes the development process easy.

However, it is also used to bundle the JavaScript pages to get further implemented in a browser. As a result of this, the overall initial loading time is minimized.

Stackify’s Application Performance Management Tool, Retrace, helps Node.js developers continually improve their applications with APM, server health metrics, and error log integration.

Additional Node.js Resources:

Node.js Tutorials for Programmers of All Levels

The 3 Types of Node.js Profilers You Should Know About

Err—not quite.

Whilst this tweet is painfully relatable, it also saddens me. This goes to show there are so many Node.js developers out there who are debugging their applications the caveman way. But debugging Node.js needn’t be this hard.

The more you relate to this tweet, the more you must read on. Your sanity begs you.

Today we’re going beyond just logging everywhere in your application. Many resources on Node.js debugging go through only one single method, but in this article, we’re going to cover ten unique tools you can use to debug your Node.js application like a pro.

Tip 1: Test

Testing shouldn’t be controversial. Yet spending the past few years as a consultant developer, I’ve now seen so many teams hand-wave at test-driven development and opt instead to put themselves into a world of pain. The tests you skip writing today will short-change your future developers’ debugging abilities.

Tests are so useful during debugging because you can use them as documentation of your code’s behavior and APIs. When you’re rifling through code searching for a bug and stop to ask yourself, “Hold up, why are they using a .forEach, not a .map?” it is immeasurably helpful to see the creator’s thoughts encapsulated in test case descriptions and example code.

If you want to get up and running with tests, I can highly recommend Jest as a unit testing library. Not only is Jest super fast, but it comes with lots of goodies as well, such as the ability to create coverage reports by passing a coverage flag to your testing reports. But one of my absolute favorite features for Jest is how you can mock required dependencies simply.

If you’re building APIs, SuperTest is a great testing library for API endpoints. SuperTest is particularly cool because you can pass it an Express app object directly. This means you don’t have to have the app running separately, and it makes mocking dependencies such as database connections easy.

But wait, there’s more!

Combine your Jest unit tests with your SuperTest ones with Husky (a Git hook utility) pre-commit hook, and you can run all your unit and integration tests before your code even leaves your machine. I absolutely love this.

Tip 2: Explore alternative console methods

Ah, the humble console.log.

Most JavaScript developers are familiar with the console log. If you’re not, it simply takes a string or an object and prints it. But what most developers don’t know is that the console object itself has many more useful methods that are often left underutilized. Let me show you a couple of my favorites.

console.group

By running console.group, you create a new collection of JavaScript console logs. In the browser, this would nest all your logs together. However in Node.js, since you only have the console to log to, each group is indented like so:

I am a console log indented by a single level
    I am a multilevel nested console log

console.table

Next up is console.table. Console.table does what you’d expect it to: it takes an array or an object and outputs an ASCII table. This is particularly useful for long or large objects with many properties, as it gives us more structure which can help with readability, like so:

┌─────────┬────────┐
│ (index) │ Values │
├─────────┼────────┤
│    0    │    1   │
│    1    │    2   │
│    2    │    3   │
└─────────┴────────┘

console.dir

Last up, console.dir.

The reason I’m giving this a shoutout is because it takes two arguments, the last of which is the important one.

The first takes an object; the second takes an object of options. In this options object, you can specify the depth of your console log. If you have ever tried to console log a native Node.js object and gotten a HUGE output, you’ll know how hard it is to read.

But instead, with console.dir and a depth property, you get the following:

process {
    title: 'node',
    version: 'v10.8.0',
    versions: [Object]
    ...

Instead of showing all the child properties (note the versions property) you get:

process {
    title: 'node',
    version: 'v10.8.0',
    versions: {
        http_parser: '2.8.0',
        node: '10.8.0',
        v8: '6.7.288.49-node.19',
        ...

Play around with console

If you’re keen to play with the different methods, simply copy the following code file:

// Example 1: console.log
// ======================
console.log('I am a regular console log.');
console.group();
console.log('I am a console log indented by a single level');
console.group();
console.log('I am a multilevel nested console log');
console.groupEnd();
console.groupEnd();

// Example 2: console.table
// ========================
const people = [["John", "Smith"], ["Jane", "Doe"], ["Emily", "Jones"]]
console.table(people);

// Example 3: console.dir
// ======================
const object = {
    name: "Lou",
    likes: ['JavaScript', 'Node.js']
};
console.dir(process, {colors: true, depth: 0 })

Save the file as app.js and run with the command:

node app.js

Now you’ll see the output of all the three different console commands, and you can experiment with them to get a better feel for how they change the debugging experience. Rather than just having plain console logs, now you’ll have structured entries, that should be easier to make sense of, and more suited to the debugging style that you’re performing.

Tip 3: Experiment with the humble debugger

Okay, now that you’re a master of the console log, it’s time to take it up a notch.

Enter: the debugger statement.

For those coming straight to Node.js who haven’t developed in the browser, the debugger statement is one of the simplest ways to get started with debugging. In the browser, a debugger statement simply pauses the execution of your code when the statement is reached…but only if you have the developer tools open.

If you want to quickly try this out, open up your dev tools and paste the following into the console.

(() => debugger;)()

You’ll see the browser stops executing on this line, which allows you to see all the scoped variables at this point in time and experiment with executing code.

In Node.js, however, there is no developer console, which means that we have to do things a little differently. We have to do the equivalent of opening up the developer tools, but this time inside of Node.js. And we do that by using Node.js’ inspect.

For instance, take the following example app:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
    debugger;
    res.send('Hello World!');
});

app.listen(3000, () => console.info('Example app listening on port 3000!'));

Now instead of starting your app as you usually would:

node app.js

You can start your app with the following command:

node inspect app.js

And you’ll be dropped into an interactive debugger. In the command line, this allows you to step through code execution.

So I must admit, this is a very primitive method of debugging.

However, I intentionally wanted to show you all the different ways to debug in Node.js so that in the future if you come across this method, you know how it works. While this method works for small Node.js scripts and apps, for more serious debugging, you might need something more powerful.

So let’s take a look at what these methods are.

Tip 4: Debugging in Chrome with the inspect flag

For debugging Node.js apps, this is by far my favorite method.

When Node.js was created, it felt like we lost all of the debugging capabilities of the browser. But with the inspect flag, you get most (though not all) of these capabilities back.

The way this works is: you pass a flag to your node process before you start the Node application. This tells Node.js that you want to run in debugging mode. Node.js will then start a WebSocket connection that will allow you to remote debug from your browser.

node --inspect app.js

Hold up for one second; you want to be careful to not confuse the—inspect flag with the inspect command (from tip three). The former launches the CLI debugger, whereas the latter launches the browser-based debugger.

Now if you’re using Chrome, you can head over to the chrome://inspect#devices page and you’ll see a section called remote target. This will show all of your running node processes that you are using that have been executed with the inspect flag.

Click your app in the list and you’ll be sent into a debugging terminal in Chrome!

There’s not too much more we need to say about debugging with the inspect flag. If you’re trying to catch small-ish bugs, this is the best method.

But it’s not the only method.

Tip 5: Debug in your IDE (VS Code)

If you thought stepping through your code in your browser was cool, you might like this even more: some IDEs make use of the inspect flag and allow you to do remote debugging without even leaving your IDE.

These IDE tools work in much the same way as before. You’ll need to attach an inspector to your node process and then listen on the WebSocket that is created for your debugging purposes.

I’m a big fan of VS Code, and since it’s the most popular JS IDE, let me walk you through how to set up debugging in VS Code. Note that the same can be done in WebStorm, if that’s what you’re into.

To start, copy the following Express app (and save the file as app.js):

const express = require('express');
const app = express();

app.get('/', (req, res) => {
    res.send('Hello World!');
});

app.listen(3000, () => console.info('Example app listening on port 3000!'));

Then, run your app with the following command:

node app.js

And you should see the output:

Example app listening on port 3000!

You may notice that (unlike before) we’re not passing the—inspect flag. There are two ways to set up your node process with inspect mode, either by passing the flag from within your IDE or through your IDE. So let’s explore the new approach, via your IDE.

Now that your app is running, go to VS Code and open the command palette, either with the view tab or by pressing:

Shift + Cmd + p

Select Attach to Node Process.

You should now have another menu (shown below) of the running node processes.

Select the top option to attach the debugger.

Now your running node process is accessible for debugging.

Your console should now show:

Debugger listening on ws://127.0.0.1:9229/d5efc834-41ae-4758-a9e6-4d8767c5752a

Lastly, reopen the command palette and select the debug option.

Your console should now say:

Debugger attached.

And your IDE will show the active orange bottom bar.

And you’re up and debugging! You can add breakpoints to your code right in your IDE, plus see the scoping of variables and the call stack.

Tip 6: Check out Postman

The debugging tools we’ve talked through so far will only work if you’re also executing your software as your users would. A common use case for Node.js is to build RESTful APIs. If you’re building APIs and you’re not familiar with Postman, you’re in for a treat.

Postman is a small application that allows you to set up, save, and run API commands. While running commands such as GET can be easily simulated by navigating through the browser, POST requests aren’t as straightforward. In Postman, you can set up the API requests you want, and fire them off at the click of a button.

Postman has gotten quite advanced recently, adding ability to do things like pre- and post-scripting. These scripts allow you to dynamically update your requests before they’re sent (for instance, updating a timestamp), or save values from your response to use in subsequent requests. Simply put: you can run a list of chained commands, and pass through the returned values. So if you’re making advanced RESTful APIs with Node.js, Postman is your holy grail.

Tip 7: Hook up logging/APM tooling

As much fun as it is to intercept your container requests with inspect and step through your code, you won’t have this option in production. This is why it makes a lot of sense to try and debug your application locally in the same way as you would in production.

In production, one of your tools would be to login to your remote server to view the console logs, just as you would on local. But this can be a tedious approach. Luckily, there are tools out there that perform what is called log aggregation, such as Stackify.

These tools send your logs from your running application into a single location. They often come with high-powered search and query utilities so that you can easily parse your logs and visualize them.

Source: Stackify’s log management tooling

In order to get your logs output, you may also want to use a logging library, such as Winston or Bunyan. These libraries help you format your logs and help with streaming them to your centralized log aggregator systems.

You can also apply logs with a log level. This is an environment-specific configuration that allows you to toggle how fine-grained your log entries are. This can help you to not drown in log entries. It’s not always beneficial to log absolutely everything.

Another tool for remote debugging Node.js is APM (Application Performance Monitoring). APM works by extracting your stack traces inside your code and sending them off to a central location for further analysis, such as with Stackify’s Retrace tooling.  Try Retrace’s free, two week trial today.

If you’re serious about building Node.js applications, you’ll want to think about how you’re going to observe and monitor your system from the start, which will likely mean instrumenting your code with logs. The sooner you learn how you need to visualize your Node.js application, the better.

Tip 8: Test performance

When many think debugging, they think your typical stepping-through-the-debugger-type interactions. However, some issues only show their face during high load. In these cases, you’ll need some way to performance test.

My favorite tool for performance testing Node.js is Artillery.

Artillery allows you to create a YAML configuration file that defines the type of performance tests you want to run. For instance, you might want to simulate how your system behaves during peak load, so you can define a profile that hits your application with low traffic before all of a sudden flooding it with requests.

By using tools like Artillery, you can get a much better picture of how your system behaves and help with your debugging.

Tip 9: Use flame graphing

In JavaScript, it’s helpful to understand how your functions are executed, and flame graphs are a great way to visualize how your function execution happens.

A flame graph models your call stack. When a function is executed, it might call another, and another, and another. Eventually at the end of this chain of functions, one will return, which will return to the subsequent function, which will return to the function that called it, and so on until the call stack becomes free again.

This is useful because you will want to see how your application is behaving with respect to your call stack. You might want to see how long functions are running or what other functions they are calling. This is something that simply can’t be done with console.log alone…but it can be done with a flame graph such as flamebearer.

Tip 10: Remember to debug memory leaks

Last up: debugging memory leaks.

A memory leak occurs when there is memory that is not properly freed up, which can lead to increasing amounts of memory being taken up by your application. If never attended to, this can lead to your application running out of memory and potentially crashing. It also means that you might need to provision bigger servers in order to run your leaky application—not good! In JavaScript, memory leaks can be created by (among other things) global variables, closures, or callback functions.

To debug memory leaks, repeat the inspect step from tip four to open up Chrome. Once it’s opened, you will see a memory tab. This allows you to profile your memory usage within your Node.js application and find those pesky leaks!

That’s a wrap!

That’s all we’ve got time for today. Hopefully, we’ve given you some good inspiration and some jumping off points to improve the way you’re debugging in your Node.js applications. Next time you find yourself pulling your hair out throwing console.log statements all over your code, just remember: there are better ways to debug!

So use them—your sanity will thank you!

What is Node.js?

Node.js can be defined as a dynamic, cross-platform and open-source JavaScript framework or runtime environment that is built on the Google Chrome JavaScript V8 engine. Developed by Ryan Dahl in 2009, Node.js was initially implemented as a client-side scripting language. Nowadays, it is used to execute JavaScript code and scripts that run server-side to create dynamic web pages. The latest version of Node.js is 10.10.0.

Node.js Features and Benefits

Most web developers implement Node.js due to its amazing and powerful features. Some of the features of Node.js are:

• Faster code execution
• Highly scalable
• Non-blocking APIs
• No buffering

With such wonderful features, Node.js is widely used for creating server-side and networking applications. The following are the key areas where Node.js is widely used:

• I/O-bound applications
• Data streaming applications
• Data-intensive real-time applications (DIRT)
• JSON API-based applications
• Single-page applications

There are many companies currently using Node.js such as eBay, General Electric, GoDaddy, Microsoft, PayPal, Uber, Wikipins, Yahoo!, IBM, Groupon, LinkedIn, Netflix and many others.

Top 30 Node.js Tutorials

Let’s begin this journey of exploring how to learn Node.js.

1. Guru99
2. CodeBurst
3. Tutorials Teacher
4. RisingStack: Advanced Node.js tutorial
5. JavaTpoint
6. Sitepoint
7. W3schools.com
8. Tutorials Point
9. Lynda.com
10. Codeship
11. Udemy
12. Mozilla: MDN web docs
13. Code for Geek
14. Airpair
15. Ilovecoding
16. Nodetuts
17. CodeSchool
18. NodeSchool
19. GangBoard
20. Mosh: Coding Made Simple
21. Stack Abuse
22. GeeksForGeeks
23. Coursera
24. The Node Beginner Book
25. edX
26. Toptal
27. JavaScript Is Sexy
28. LiveEdu.tv
29. Learn Node.js
30. ChalkStreet

1. Guru99

Source: https://www.guru99.com/node-js-tutorial.html

Whenever we talk about creating server-based applications, the Node.js framework comes into the picture. Guru99 provides a free online tutorial suitable for all skill levels. It also enables you to check the entire syllabus of the tutorial. Each topic is well-explained with the help of examples.

This tutorial introduces you to the different aspects of Node.js including modules, Express, promises, and MongoDB.

Some key topics included in this tutorial are:

• Download & Install: Step by Step Guide
• Modules: Create, Publish, Extend & Manage
• Generators & Compare with Callbacks

2. CodeBurst

Source: https://codeburst.io/25-node-js-tutorials-1db3b1da0260

Codeburst offers 25 free online tutorials to learn and explore the depth of Node.js framework. These tutorials are best-suited to all learners whether new to Node.js or an experienced developer. You can easily learn Node.js with the help of these tutorials. These tutorials are designed and brought to you by Brandon Morelli.

Some key topics included in this tutorial are:

• Learn and understand
• Creating applications
• Fundamentals

3. Tutorials Teacher

Source: http://www.tutorialsteacher.com/nodejs/nodejs-tutorials

This tutorial will help you to learn all the basic and advanced concepts of the Node.js framework. The complete course is divided into different sections, where each section covers a specific topic and is explained with the help of real-world examples, useful tips, and information.

In case, you want to test your coding skills in Node.js, then you can do that too. This tutorial consists of a builtin Node.js test, which helps you to understand the practical implementation of the concepts.

Before getting started with Node.js, you are required to have some introductory knowledge of languages like HTML and JavaScript.

Some key topics included in this tutorial are:

• Basics
• Modules
• File system

4. RisingStack: Advanced Node.js tutorial

Source: https://blog.risingstack.com/tag/node-hero-getting-started-with-node-js/

RisingStack provides full support to learn the Node.js framework. It has a good collection of Node.js articles. Based on your understanding, you can choose to begin with either the beginner or advanced tutorial.

Some key topics included in this tutorial are:

• Getting started
• Core modules
• Microservices

5. JavaTpoint

Source: https://www.javatpoint.com/nodejs-tutorial

This tutorial is designed by JavaTpoint especially for beginner programmers. You can learn all the concepts of JavaTpoint including Node.js installation, advanced concepts, and Node.js interview questions.

You must have some prior experience working with HTML and JavaScript before getting started with Node.js.

Some key topics included in this tutorial are:

• DNS
• Net
• Crypto
• REPL

6. Sitepoint

Source: https://learnnode.com/

Sitepoint is a hub for emerging and experienced developers from across the world to learn and look into Node.js. Here you can learn how to create applications with the help of Node.js, including other languages as well.

It offers access to books and video tutorials as well. You can also purchase the entire course along with the study material, if required. Apart from Node.js, this website also provides a tutorial about HTML, CSS, Bootstrap, JavaScript and many others.

Some key topics included in this tutorial are:

• What is Node and when should you use it
• A beginner splurge
• How to use SSL/TLS
• How to build a web server

7. W3schools.com

Source: https://www.w3schools.com/nodejs/nodejs_intro.asp

Those who want to become expert in this programming language can join here to make their dreams come true. W3schools.com is a well-known platform to learn the Node.js framework. It is a free online tutorial so you can freely access any specific topic related to the Node.js framework through these tutorials.

In addition to this, you can also learn some other programming languages on this website such as Java, Python, JavaScript and many others.

Some key topics included in this tutorial are:

• Intro
• Modules
• File system module

8. Tutorials Point

Source: https://www.tutorialspoint.com/nodejs/nodejs_introduction.htm

Like other online tutorials, Tutorials Point offers free courses to learn different programming languages and several other platforms. You can also learn about run-time environments such as Node.js. Node.js is a powerful framework based on JavaScript language.

Tutorials point provides a step-by-step guide for all skill levels including novice, intermediate and advanced developers. After finishing this tutorial, you will be able to create applications on your own.

Some key topics included in this tutorial are:

• HTTP module
• URL module
• MySQL

9. Lynda.com

Source: https://www.lynda.com/Node-js-training-tutorials/1283-0.html

If you are searching for a place where you can start your journey of becoming an expert in Node.js, then Lynda.com is one of the best places for you. It offers premium tutorial courses to learn Node.js. You have to sign up under Lynda.com to get full access to course content.

Lynda.com provides a one-month free trial to its users during sign-up process.

Some key topics included in this tutorial are:

• Essential training
• API design
• Real-time web with socket.io

10. Codeship

Source: https://blog.codeship.com/node-js-tutorial/

It is one of the simplest Node.js tutorials that explains Node.js in detail. It also teaches you how to download and install Node.js on your local machine. Unlike other online tutorials, which cover only particular cases or topics, Codeship introduces you to all the concepts. After finishing all the concepts, you can easily build your own application in Node.js.

Apart from tutorials, it also provides free access to plenty of e-books. These e-books are available to download free.

Some key topics included in this tutorial are:

• File I/O
• Asynchronous callbacks
• Create an HTTP server

11. Udemy

Source: https://www.udemy.com/the-complete-nodejs-developer-course-2/

Udemy offers you a complete Node.js developer course to become an expert and gain more knowledge. You can learn Node.js in a very short period of time through this platform. Here you will learn to build, test and launch applications based on Node.js.

It has organized the entire curriculum into 135 lecture videos that cover almost 27 hours of learning. You will also get a certificate after completing the course.

Some key topics included in this tutorial are:

• Fundamentals
• Web servers and application deployment
• Security and authentication

12. Mozilla: MDN web docs

Source: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Express_Nodejs/Introduction

This tutorial will teach you about the Express web framework that is written in JavaScript and hosted by the Node.js run-time environment. Here, you can learn about all the advanced concepts.

Some key topics included in this tutorial are:

• Express web framework overview
• Express/Node introduction
• Setting up a Node development environment

13. Code for Geek

Source: https://codeforgeek.com/category/nodejs/

This online learning platform is created by Shahid Shaikh, who is a software engineer by profession. This tutorial offers free access to several useful blogs that cover a specific topic of Node.js. It is suitable for both beginners and experienced programmers.

Under this platform, you can learn from basic to advanced concepts very easily.

Some key topics included in this tutorial are:

• Authentication using JWT and refresh token
• Compress HTTP request and response
• How to set up Nginx to serve static files

14. Airpair

If you want to begin from scratch and want someone to guide you through the entire journey of Node.js, then Airpair is the most-suited platform for you. This is a comprehensive and step-by-step guide to learn Node.js.

It introduces you to all the topics including basic and advanced levels. This tutorial is brought to you by Alexandru Vladutu.

Some key topics included in this tutorial are:

• Installing Node.js and NPM
• Fundamentals
• Error handling

15. Ilovecoding

Source: https://ilovecoding.org/courses/nodejs

This is a free online platform that covers the full curriculum of Node.js. You will get full access to plenty of content that guides you through the entire course tutorial. This platform teaches you the key concepts that have played a major role in the success of Node.js.

You will learn to create applications, a simple HTTP server, web scraper and many more during this journey of Node.js. There are total 10 lessons in this tutorial that are explained with the help of suitable examples and code snippets.

Some key topics included in this tutorial are:

• Modules
• HTTP
• Node Package Manager (NPM)

16. Nodetuts

Source: http://nodetuts.com/

Are you fed up with the traditional methods of learning? If yes, then, we will introduce you to a new interactive platform, where you will not get bored while studying. Nodetuts provides video tutorials to learn Node.js. It provides tutorials in a much interactive way as compared to other resources.

It provides you access to several books like Database and Networking Patterns.

Some key topics included in this tutorial are:

• Asynchronous programming
• HTTP API servers
• TCP servers

17. CodeSchool

Source: https://www.pluralsight.com/courses/code-school-real-time-web-with-nodejs

This tutorial is created by Greg Pollack and Carlos Souza under pluralsight.com. CodeSchool provides courses to learn Node.js. Here you can learn how to work with the Node.js framework and to develop server-side code (or write programs).

You will be able to create applications with the help of this tutorial. CodeSchool also offers some other tutorials as well like, jQuery, Angular, Ruby on Rails, etc.

Some key topics included in this tutorial are:

• Intro
• Events
• Streams
• Modules

18. NodeSchool

Source: https://nodeschool.io/?utm_campaign=free-traffic&utm_source=solutions-softonic-com&utm_medium=referral

NodeSchool offers free online tutorials, workshops, seminars, and classes that are very useful for beginners as well as advanced programmers. These classes cover all the concepts including basic and advanced, which further helps in learning Node.js and other skills as well.

It offers free workshops which emphasis on developing new skills to train learners and aspirants. The classes are available in several languages including English, German, Italian, Spanish, French and many others.

Some key topics included in this tutorial are how to:

• Create and use NPM
• Compose streaming interfaces
• Start using Markdown

19. GangBoard

Source: https://www.gangboard.com/app-programming-scripting-training/nodejs-training

Gangboard provides online training for more than 200 courses. It offers courses suitable for new aspirants as well as experienced folks. You can easily learn Node.js with the help of this online platform.

It is a paid platform that offers one-to-one and classroom options. You can choose any of them as per your feasibility. Apart from Node.js, you can also learn about big data, AWS, web design, Java and many others.

Some key topics included in this tutorial are:

• Control structures: logical expressions
• User-defined functions
• Debugging

20. Mosh: Coding Made Simple

Source: https://codewithmosh.com/p/the-complete-node-js-course

Mosh provides a complete tutorial about Node.js. It offers video classes to teach how to work with Node.js. Mosh focuses more on providing practical rather than theoretical knowledge. It offers 15 hours and 220 lessons in order to learn Node.js.

You are required to enroll in Mosh to continue course tutorial. However, you will get a free trial video.

Some key topics included in this tutorial are:

• Module system
• Node Package Manager
• Implementing CRUD operations
• Handling logging errors

21. Stack Abuse

Source: https://stackabuse.com/learn-node-js-a-beginners-guide/

Stack Abuse is a step-by-step guide made for beginners, where you can be easily introduced with Node.js. It begins with the basics so that one can easily understand what Node.js is. The concepts are well-explained with the help of suitable examples and code snippets.

It is an open source tutorial, which means that you can freely access this resource and there is no need to sign up or enroll. You can also learn about Python and other tools as well.

Some key topics included in this tutorial are:

• What is Node.js?
• The REPL
• Your first package

22. GeeksForGeeks

Source: https://www.geeksforgeeks.org/tag/node-js/

This tutorial provides useful content about several concepts of Node.js. It has a very good collection of programming and interview questions. You can find appropriate solutions to such questions. This platform will help you to clear all your doubts regarding Node.js.

You can choose concepts and questions as per your skill level, i.e. basic, easy, medium, hard, or expert. It also teaches other languages as well such as Java, Python, SQL etc.

Some key topics included in this tutorial are:

• REPL
• MVC architecture
• NPM

23. Coursera

This online tutorial is suitable for those who have prior basic knowledge of web languages like HTML, CSS, and JavaScript. This course is specially designed to deal with server-side related concepts in Node.js.

It starts with some basic concepts like HTTP and HTTPs. Later, you will come to know about Express for creating web servers. By the end of this tutorial, you will be able to design a backend server with Node.js.

You will be provided with a 7-day free trial during the signup process. During this trial period, you will have full access to course content and video tutorials. However, you can purchase this course if you want to earn a completion certificate.

Some key topics included in this tutorial are:

• Intro to server-side development
• Backend as a Service (BaaS)
• Data storage with MongoDB

24. The Node Beginner Book

Source: https://www.nodebeginner.org/

This is an online free Node.js beginner tutorial book, provided by Manuel Kiessling. The main objective of this book is to introduce you to the world of Node.js and assist you in creating an application in Node.js. The concepts are explained with the help of code examples.

In order to begin your journey with Node.js, you are required to have prior knowledge of basic concepts like data types, variables, and control structures.

Some key topics included in this tutorial are:

• JavaScript and Node.js
• Web applications
• A basic HTTP server

25. edX

Source: https://www.edx.org/course/introduction-to-nodejs-0

In this tutorial, you will learn how to use Node.js to create an application, interact with the database, and many other things. It provides high-quality tutorial classes to teach Node.js and its related concepts. edX is one of the best online platforms to start with Node.js.

It has divided the entire course module into 5 modules, where each module covers a specific topic.

Some key topics included in this tutorial are:

• Overview
• Setting up a project and importing modules using NPM
• Using an Express framework to set up a web server

26. Toptal

Source: https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js

Toptal provides an easy-to-learn and simple online platform that helps aspirants learn Node.js. It starts from scratch to advanced levels. Hence it is widely popular among all the existing online resources.

Some key topics included in this tutorial are:

• Node Package manager
• Data streaming
• Proxy

27. JavaScript Is Sexy

Source: http://javascriptissexy.com/learn-node-js-completely-and-with-confidence/

This is a very helpful blog with a free tutorial to learn the Node.js framework. It is created by Richard Bovell, who is a founder of AI humanity and Bov academy. It provides you free access to a high–quality course content.

Some key topics included in this tutorial are:

• Control structures
• Variables
• Functions

28. LiveEdu.tv

This tutorial provides courses ideal for all skill levels including beginners, intermediate, and experienced programmers. If you are looking for a simple platform to get started with Node.js, then this resource is perfect for you. It lists all the concepts of Node.js along with the skill levels. It offers video tutorials to teach you about the Node.js. Here, you will learn to create real-time working applications.

Some key topics included in this tutorial are:

• Intro
• How to create projects
• How to create a dating web app

29. Learn Node.js

Source: https://www.youtube.com/watch?v=b8ry4Q8KeLo

This tutorial video is created by Suppoman. It teaches you how to work with the Node.js framework. It has videos that are very easy to understand, suitable for everyone from freshers and intermediates to expert professionals.

Some key topics included in this tutorial are:

• Basics
• Functions
• How to build a website

30. ChalkStreet

This video tutorial is specially designed for beginners who want to start their journey of coding in Node.js. It starts from scratch, and hence it is ideal for all skill levels. It is a paid video tutorial.

Some key topics included in this tutorial are:

• Getting started
• Variables and functions
• Building a command-line application

Stackify’s Application Performance Management tool, Retrace, offers support for Node.js applications.  Download today to improve the performance of your application. If you want to learn additional languages, browse through our tutorials that cover the most popular programming languages.

Try Stackify’s free code profiler, Prefix, to write better code on your workstation. Prefix works with .NET, Java, PHP, Node.js, Ruby, and Python.