#20 6. Why Should I Use Node.js?

In the last video we answer to the question what is no J.S. in this video.

We’re going to turn our attention towards the why behind No J So why is no J as a tool you should spend your time learning.

And why is no J ust a good tool for the job of building out applications now as you know based off of

the fact that you’re here taking this class more and more when people want to learn a new back end technology they are choosing node js as their tool of choice the node J.S. skillset is in hot demand with companies like Netflix Uber and Wal-Mart all using Node in production. Nodes also useful for developers anywhere on the stack.

So we have front end developers you might need to use a little node here and there to compile their apps or maybe serve up a Web site they’re working with and obviously back and engineers are using no J.S. extensively to build out their

web app back ends API eyes and command line applications.

Now in the last video we broke down this first sentence we talked about how no J.S. is a javascript

runtime built on Chrome’s V8 JavaScript engine and this one we’re gonna break down the other two sentences.

There’s only three total.

We got the second one and the third one.

Now you’ll notice that you don’t have those second two sentences on your screen.

If I were to load up No j s dot org I just get that first sentence.

We already discussed in the past this was the complete summary on the Web site and I’ve cached it so

we can talk about it.

In my opinion I think it’s a shame they took it down because it concisely summed up why no JSA is an

ecosystem worth getting into.

Let’s go ahead and start with that second sentence.

No J.S. uses an event driven non blocking I O model that makes it lightweight and efficient.

Now let’s just focus on non blocking I O.

What exactly is I O I O stands for input output and your node application is gonna use I O anytime it’s

trying to communicate with the outside world.

So if you’re node app it needs to communicate with the machine it’s running on.

That’s I O for example reading some data from a file on the file system.

If you’re node app needs to communicate with some other server that’s I O as well.

For example querying a database to fetch some records for a given user that’s gonna be an I O operation

and I O operations take time now with no J S we get non blocking I O.

That means that well your node application is waiting for a response.

Let’s say a response from that database.

It can do other things.

It can continue to process other code and make other requests.

Now non blocking is actually from the browser so non blocking I O started in the browser because otherwise

the browser would completely freeze up whenever an IO operation was happening.

So if I was trying to fetch some data to render it to a user well that data was being fetched the user

wouldn’t be able to do anything they wouldn’t be able to click links or buttons and obviously that’s

a bad experience with non blocking I O it frees up the browser to allow the user to interact with the

user interface.

Well those Io operations are running in the background and the same thing is true with node.

We can continue to do other things while we’re waiting for those long running Io operations to complete

and this is a critical feature of what makes node so great.

And I put together a quick visualization so we can compare non blocking to blocking I O in this quick

visualization.

We’re going to work through two code examples now both code examples aim to get the exact same thing

done.

They just do it in slightly different ways.

On the left hand side we have a blocking example on the right hand side.

We have a non blocking example and there’s no need to write any of this out as we’re just going to explore

how these programs would execute using these timelines down below.

That’s going to allow us to visualize the differences between blocking and non blocking ie.

Now what do we have here.

We have a bunch of regular javascript code.

The only thing specific to know J.S. is this require a function which is called on the first line of

each little snippet.

You’ll learn all about require in the next section.

For now all you need to know is that it’s a way to get functionality from another file.

So in this case both of these scripts.

They load in a function defined elsewhere and they call them a couple of times to perform some I O operations

the I O operation for both.

It’s attempting to do the same thing so over here for the blocking example.

The goal is to take in a user I.D. and then go off to a database and actually fetch that user’s profile

information and we do the same thing over here in the non blocking example.

So to start we try to fetch the user with an idea of one.

Then we print it to the console.

We do the same thing over here using a slightly different pattern which we’ll get into shortly.

Then over here we try to fetch the user with the idea of two and we print that to the console.

And we do the same thing over here.

Finally both snippets attempt to add up to numbers and print that sum to the console as well.

And that’s all they do.

Now down below I have some units for each timeline that’s gonna help us compare the relative operating

speeds.

They’re not exactly seconds but for the sake of this example you can definitely think of them as seconds

and now we’re actually going to run through each seeing how they execute.

We’re going to start with the blocking example and for both examples we’re going to ignore that first

line.

The first line is the same for both.

And it’s not part of this whole blocking verse non blocking discussion.

So the first thing we really do over here is we pass one into get user sync.

The goal here is to go off to the database and get the user profile for the user whose idea is one.

Now what does that look like while down below.

It looks a bit like this.

Here I have a block representing the time this entire operation takes to complete.

And in this case I’ve chosen to make the length of our IO operation two seconds and that’s going to

be the exact same length of all Io operations in these examples regardless of whether it’s blocking

or non blocking.

So this includes everything.

It includes initiating their request and actually waiting for the database to fetch the data and send

it back to our node application.

So once that’s done what do we do.

We go ahead and just print user 1 to the console.

That is not an I O operation.

And it runs really quickly from there we continue working through our program.

One line at a time.

We go one after the previous.

So right here what do we have.

We have user 2 and we get the second user by passing two into get user sync.

Once again we wait two seconds to actually get that second user right here.

These two blocks are the exact same length.

The next thing we do is we go ahead and print that second user that happens on line 7.

Once again not an IO operation it runs really quickly and the same thing is true of the last thing we

do which is we calculate and print the sum.

So this is the order of operations and this is the entire time it takes to run.

In this case let’s say it’s basically four and a half seconds.

Now you notice the bulk of this four and a half seconds is taken up by fetching second user and fetching

first user.

And well that’s happening.

Our app isn’t doing anything.

It’s waiting for the database to send the data back.

It’s not actually doing any work on its own.

Now let’s go ahead and run through the example on the right to see how this differs even when the IO

operations still take two seconds.

The first thing that happens over here is the same thing that happened over here we are attempting to

flash the user with the idea of one.

So what does that look like.

Well you’ll notice that over here we’re actually passing a function in as our second argument to get

user.

This is using the callback pattern and if it’s something you’re not familiar with.

If this code looks really foreign that is a ok for the moment we’re actually going to cover all of this

in detail in the class.

For now we’re just using it to illustrate at a high level the differences between the two patterns.

So over here what do we do.

We start to fetch the first user.

Now the first thing you’re going to notice is that this is not a two second operation.

It happens basically instantly.

That’s because we’re not waiting for the response from the database.

That’s the long running.

Oh.

Instead we are just starting that process allowing it to run in the background.

So right here we are essentially registering our Iowa event with no J.S. telling it to call this callback

when at some point in the future we get the response we were hoping for.

Now the same thing is true down below.

So the next thing we do is we actually start the process of fetching the second user exactly like we

did up above.

So at this point node is actually waiting for too long running Io operations to complete and they’re

both happening in the background it’s not taking up our applications time preventing it from doing other

things.

So we can prove that by talking about the next step the next thing that happens is we actually calculate

and print out some these two lines down below.

They do not care about the user response for either User 1 or user 2 they should be able to operate

completely independently and that’s what we’re seeing right here.

There’s no need to wait for those two responses before calculating and printing the sum.

Now what happens.

Well I mentioned that regardless of which example we’re working with the IO operation doesn’t get shorter

it still takes those two second so right here I have a box of the exact same width as our two boxes

over here and it’s a dashed box and it represents the time our node app has to wait for a response to

come back.

Now the nice thing is that while it’s waiting.

It can still do other things.

So while it was waiting for a user one it was able to start up a another request and it was able to

calculate and print the sum.

Now after those two seconds we still get the user data back.

This is when node j s calls our callback function and we are able to print the user and that’s what

I see right here.

Next up we wait for that second request.

This starts just a little bit later than the first and it finishes a little bit later and once we get

that data back we are able to print the second user to the console.

If we look at the total operating time I can see that the non blocking example was able to finish in

just over two seconds while the blocking example was able to finish in just over four seconds.

A difference of 50 percent making the non blocking example twice as fast.

Now obviously that’s because we were able to overlap the part of our application that took the longest

which was waiting for the I O to finish down below we were able to wait for both at the same time and

well we were waiting.

Our app could even perform other things like firing off another request or calculating and printing

the sum that just is not possible using a blocking model.

So in this course we’re gonna be working with non blocking code throughout the class and that’s what

makes node so ideal for things like server side development where we’re making web servers and application

back ends it’s going to allow your node app to process multiple requests at the exact same time for

different users.

So you could be fetching some data for a user 1 while processing a new request from user 2.

Now let’s go ahead and run some node code to actually see these two examples in action right here.

I’m gonna put on a quick demonstration actually running the two files we just had over in that visualization.

On the left I have my blocking example character for character what I had in the other file and the

same thing is true on the right with the non blocking example.

Once again you don’t have to worry about opening this project up or writing this code.

This is just for demonstration purposes.

We’ll start diving into coding together in the next video for now.

What we’re gonna do is run these two scripts to see how they execute which is gonna be exactly how we

describe them in the visualization on the left hand side.

I’m going to use one terminal for the blocking example on the right hand side.

I have a second tiny terminal for the non blocking example now to actually run a file.

We still use that node command followed by a space and the file name.

So here node space blocking dot J S is the file I’m trying to run now to make things easier to see.

I’ve delayed the IO operations to take five seconds so it’s a bit easier to talk about things as they’re

happening.

Let’s go ahead and kick off the blocking example.

So what happens.

Nothing.

We are sitting here and we’re waiting and we are waiting for a full five seconds before that first user

comes back.

There it is.

We have their I.D. and their name.

Then we wait a another 5 seconds to get the second user.

Finally these some prints exactly as we saw over in the visualization.

So five seconds for just five more seconds for Mark.

Then basically instantly after Mark printed we got 30 for printing.

So this is the blocking example for a total runtime of just over 10 seconds.

Now let’s try the non blocking example in this case getting the user still takes a full five seconds.

So right here node space the file non blocking dot J.

S I’m gonna go ahead and run it.

And once again we get the number printing right away.

It started up the two Io operations it printed the number then five seconds later both basically printed

at the exact same time.

That’s because we were able to overlap the process of our node app waiting.

So the total runtime here for our non blocking example was just over five seconds.

Once again running twice as fast as the blocking example over here.

So that is it for our little illustration of blocking verse non blocking.

We’re gonna talk a lot more about this a bit later in the class when we start to get into some more

advanced know J.S. application code.

For now though we have done a pretty decent job at exploring this second sentence.

No J.S. uses an event driven non blocking I O model that makes it lightweight and efficient.

So we now know what non blocking I O is.

And we’ve seen that it definitely creates a more lightweight and efficient application and event driven

is just that process of registering those callbacks and having them call when the IO operation is done

and it’s something we will talk about in detail later on in the class.

The last sentence we have here no J S’s package ecosystem NPM is the largest ecosystem of open source

libraries in the world.

Now NPM is a tool that was actually installed on your machine when a node was installed and you can

find the Web site at NPM J S dot com.

Here a Web site we’ll be spending plenty of time in in the class.

You can search for all sorts of pre written packages that you can use inside of your application.

So if you want to validate emails there’s a package for that.

If you want to send emails off or communicate with a database or create a web server or pretty much

do anything else you can do with node.

There are libraries and packages that make your life much easier.

We’re gonna make heavy use of NPM packages throughout this class which is exactly what real developers

do when they’re building out node applications.

This is something we’ll start to explore in the very next section so we know a little bit about what

node is and why it’s a tool worth learning in the next video.

We’re going to wrap up this little introductory section by actually creating and running a script on our own.

I’m very excited to get to that.

So let’s go ahead and jump right in to the next video.