Learning NodeJS Part 1: Understanding the Essentials

In late fall of 2020, I went on a mission to better understand Node. I wanted to improve the way I use it, how I might be able to use more of its features, and moreover grow my front end knowledge to full stack. This series includes the notes I've compiled from my learnings over at The Odin Project. The lessons also include general web concepts necessary to better work with Node.

In order to pass the potential bumps when learning Node, it's important that some of your web fundamentals are in order. For this section and the next, I'll be revisiting key topics and tying it back to Node. Let's begin!

Understanding what Node really is

Node is an open-source, cross-platform runtime environment that allows developers to create all kinds of server-side tools and applications in JavaScript.

But that's just the textbook definition - let's break down what those words mean.

What's so groundbreaking about Node?

JavaScript was originally designed to run in the browser. This means it was impossible to run it in anything that was not a website. Node brings JS out of the browser-world, so you can accomplish with it most anything other server-side languages can do. This is what is so groundbreaking about Node. It gives JavaScript backend capabilities.

To make this happen Node must have added functionality that original JS did not have, right? Indeed, Node enables JS to have abilities like:

• Create http connections
• Listen to network requests
• Generate dynamic page content
• Create/open/read/write/delete/close files on a server
• Collect form data
• Add/delete/modify data in a database

The term 'V8' comes up alongside Node. What is V8?

JS runtime environments need engines to run. As we discussed, Node is a JS runtime environment so it needs an engine as well. Node's engine is built on Chrome's open source JS engine, V8. V8 is written in C++, and allows you to write your own C++ via hooks that you can make available to JavaScript.

There are other runtime engines like SpiderMonkey by Mozilla and Chakra by Microsoft.

What would “hello world” look like in Node?

1. Create a file (name it anything) but be sure it has the extension .js.
2. Put the following in it: console.log("Hello World!");
3. Open your node terminal, cd into the directory to the folder where the file is saved and run node [name-of-file].js.

Look familiar? Since Node is a runtime environment for JS, you can power it with the JS syntax you know and love.

Key Concepts in Understanding Node

Node is asynchronous and event-driven, let's break down these terms:

Event-driven: every action on a computer is an event. It could be a network request, someone trying to access a port on a server, clicking submit on a button - the possibilities are endless. Events trigger some response to occur, which is what Node helps us to handle.

Synchronous and asynchronous describes two different ways code can be run.

Synchronous: means each operation must complete before the next operation can start.

Asynchronous: means instead of writing code in prediction of when each line will run, you write it as a collection of smaller functions that are called in response to an event.

For example, let’s say you are writing a program and you need it to do the following: It should read some text from a file, print that text to the console, query a database for a list of users and filter the users based on their age.

This is what those steps would look like if they were to be executed synchronously:

1. Read File
2. Print File Contents
3. Query Database
4. Filter Database Query results

To make these steps execute asynchronously we would instead break up the tasks:

1. Read File AND THEN Print File Contents
2. Query Database AND THEN Filter Database Query Results

In this way, Node is not waiting around. While the file is being read, it can query the database. Then depending on which one is complete first (an event!) it will move on to the next task at hand.

This process is almost exactly like the way that you would use addEventListener in front-end JavaScript to wait for a user action such as a mouse-click or keyboard press. The main difference is that the events are going to be things such as network requests and database queries. This functionality is facilitated through the use of callbacks.

What are callbacks?

Callbacks are functions that are passed into another function as an argument:

// this has no callback
// it prints "First" then "Second"
console.log('First');
console.log('Second');

// this has a callback 
// it prints "Second" then "First"
setTimeout(function() {
   console.log('First');
   }, 3000);
console.log('Second');

If you're not careful, this can result in callback hell, which you can reduce with practices like using the async module or Promises.

What about error-first callbacks?

A common convention for Node and Express is to use error-first callbacks. In this convention, the first value in the callback functions is an error value, while subsequent arguments contain success data. This ensures if you get really in the weeds with callbacks, you can be notified when a request is being held up due to a process never going through.

Explain the event loop.

This leads me to the last large concept for this section - the event loop. You can watch this excellent video explanation on the event loop. But it's on the lengthier side, so this section will be summarizing its highlights.

The event loop is the secret behind JavaScript's asynchronous programming. JS executes all operations on a single thread, but using a few smart data structures, it gives us the illusion of multi-threading.

The job of the event loop is to watch for the stack and the task queue. If the stack is empty and the task queue is not, it will push the first item from the queue to the stack, effectively running it. The 'webapis' section is what we get from whatever our environment provides us with, in this case it's the browser providing us with the ability to keep track of the setTimeout.

Ajax requests would be treated the same way - put into the webapi section, because the code for a request does not live in the JS runtime, it lives in the browser webapi.

We have one more section after this that lays down fundamentals. Onto part 2!