learn-co-curriculum / node-overview

Introduction to Node

Overview

We'll give a quick overview of Node.js and explain non-blocking I/O, and provide a bird's eye view on how it fits into web development.

Objectives

1. Describe increase in performance when using Node.js?
2. Describe the re-use of code when using Node.js?
3. Describe Node.js history (a very brief version)

Non-Blocking Input/Output

Have you ever worked with Rails and had to wait while ActiveRecord was processing some simple database join? Or maybe you remember seeing the fail whale every time Twitter was over capacity. It's happened quite often, maybe every week. Slow systems are not only frustrating to users, but also to companies. They cost companies money because users leave them for other services and products. A slow system is a system that cannot handle the traffic or load properly. The term "slow" is relative. For example. what we consider slow in 2016 is very fast compared to 2000. With Rails the slowness is due to the high-level of abstraction which means that the Object Relational Mapper (ORM) Active Record and the framework as a whole is doing too many things. It's a good thing for developers because we have to code less, but as real-life shows, it's not so good for the systems. Another reason for slowness is the architecture of the system.

Slow platforms are not just annoying to develop with but they also cost companies hundreds of thousands of dollars each month in servers and CPUs. What if we told you there is a high performing and scalable system which is extremely efficient yet fun to work with?

Node.js is one of those scalable platforms which enable engineers to build fast systems. Imagine a Starbucks coffee shop. You see 20 people standing in line and just one person working at the cafe. The single barista is also a cashier meaning this employee must first take the order, then make it. Each person has to wait for the not only for his or her drink but for the order before them... would you wait in line if you were the last person? The 20th person? As a manager of this cafe, the only way to scale is to add more registers. By adding more registers and employees we can have more than one line. Each cashier is still taking the orders and making the drinks. But this is not the most pleasant experience for customers because they would still be standing in a line. Slow systems are painful and they cost money because customers can walk away without ordering anything.

Luckily, this is not how the most Starbucks or coffee shops operate. You order your fancy choco-mocha-frappe-latte-soy-decafs, the cashier yells your order and takes your money. You step aside to check to work on some Learn.co lessons. You can now do other things while waiting for your drink. The line isn't blocked. It moves faster. The orders are taken by the cashier and the drinks are made by another employee. This is a more pleasurable experience than waiting the entire time in the line right?

The first scenario is how most platforms, including Rails, operate. The approach is called blocking input/output (I/O) in computer world because the line(s) are blocked by previous orders (or tasks in the computer lingo). The line is a metaphor for a queue of tasks while the employees can be servers. So how is Node.js different? Node.js has non-blocking I/O which as you might guess is the latter approach.

The queue moves, and the processes are executed asynchronously and without blocking the queue. Note: The real Starbucks uses blocking I/O for simple drinks like regular coffee and teas since they take very little time to make. However, the chain uses a non-blocking I/O system for more complicated, hand-crafted drinks like lattes, frappes, Cappuccino and others that take longer to make.

Therefore, Node.js systems can serve more traffic because they are not idle or blocked. They can process other tasks while waiting on the input/output operations (usually the most time consuming). For example, a Node.js server can process a request from client B while it waits for a response from a database to serve a response to client A. Most other systems will do nothing while they wait for a reply from a database to serve client A's request.

Full Stack JavaScript

When you develop applications in Rails, you might use Haml to render server-side templates and then on the client-side you might use another framework and another template engine like Angular. Those libraries are great, but consider that you have hundreds of pages with duplicate templates: one file for server-side rendering and another for browser rendering. To add complexity, this is an enterprise application that was developed many years ago, and you have 20+ people working on the project. How are you going to make changes to 200+ files? You need to make similar changes to two files and then change the tests as well. What if they are different languages? Imagine the nightmare. Sadly this is the case in most systems.

Node is different because it has this concept called full stack, isomorphic or universal JavaScript. No matter what you call it, the idea is that you can re-use files, libraries and modules between the server and the browser seamlessly. This is huge because as web developers, we've amassed boatloads of great utilities and tools for browser JavaScript. Most of them are ready-to-go in the Node environment with very minor modifications, e.g., using Browserify. Same thing applies to books, blogs, and screencasts. JavaScript is continually being improved, (ES6, ES7, etc.) which puts Node in a unique position.

Node History

We know that you probably want to learn how to's and not so much about Node history so feel free to skip this part. Nevertheless, knowing Node history will make you a star at developer happy hours. So how did Node start?

1. 2009: Ryan Dahl invents Node to make file uploads easier. JavaScript is the third language of choice, and it sticks. Ryan joins Joyent.
2. 2011: Isaac Schlueter writes npm (package manager); Windows version of Node.js is released. Versions 0.1 to 0.6 released.
3. 2012: Isaac Schlueter replaces Ryan Dahl as "head" of Node at Joyent. Versions 0.6 to 0.9 released
4. 2013: Versions 0.10 and 0.11 are released.
5. 2014: Timothy J. Fontaine becomes the Node project lead; Node.js is forked by open source community to speed up releases. Version 0.12 released.
6. 2015: Node.js Foundation is created, and io.js becomes Node.js. Versions 1.x through 5.x are released.

Here's a five-minute video that explains the past, present and the future of Node.js and Joyent.

Resources

1. The Story of the Fail Whale
2. Ryan Dahl: Original Node.js presentation
3. The past, present and the future of Node.js and Joyent
4. Node.js Foundation

---

View Node Overview on Learn.co and start learning to code for free.

node-overview's Issues

Broken image on the page

The first image in the body of the page is broken:

Better explanations

1. Explaining that rails is slow because of ORMS can be more detailed. Why is this a problem? One sentence will do.
2. Explaining the queue - a picture would go a long way.
3. The fullstack javascript section could be better - wouldn't we be separating backend and front end into multiple files anyway?

Feedback

Hi Azat,
For some reason I tried to make a PR to master and add comments in there, but was unable to. @jmburges can probably figure it out, but for now I added some of my comments to the Readme as an issue. (Going forward though can you make PRs for your branches. That way we can easily add comments in the PR itself).

Overall there's a lot of great info in the Readme, but I think much of it needs to be introduced very slowly and should always start with what the student already knows, and then should move into what they don't know. Really explaining the specifics and the difficulties of doing something with the tools that they already are aware of will give them a much better context for all the new information that's about to be presented. Any time you introduce something new you should always ground it in something that students will already be familiar with. More detailed comments below- thanks!

• Change title to just Introduction to Node.js

Overview:

• some grammar issues. for example, change sentence to
  • We'll give a quick overview of Node.js and explain non-blocking I/O, and provide a bird's eye view on how it fits into web development.

Objectives:

• in number 3, Ruby, Java, and Python aren't platforms so can you be a little bit more explicit with that objective?
• Remove or rephrsa objective of "get the sense of how node fits into web development". It's not very measurable or observable so not very benficial to students.
• Reword last objective as this is very content focused and doesn't give much on what students will be able to do.

What is Node.js

• I like that you introduce Node by bringing in other things a student might have encountered. But for now, we can only assume that students only know Rails so mentioning Wordpress, Drupal, and PHP can be confusing for students. If you can expand the Rails example, that would be great. Talk more about the time and performance issues of this. The other reason for this is that you mention "high performant and scalable system" but students wouldn't really know at this point what that means and so you have to explain first what it isn't (using and extending the Rails example is good) before you can get to what it is. Again, show or explain the pain of something before explaining the reason why you're introducing this.
  -Actually the first two sentences of the second paragraph might be explaining this pain already. Moving that up and expanding on it would be great.

• "Node.js is a non-blocking platform for building web applications" This is a very big sentence along with the rest of the paragraph and the rest of the paragraphs in the section. Students won't know what a nonblocking platform, and though you describe it later on, they shouldn't be confronted with concepts they don't understand without any context. Also for now, there's no need to mention that Node is used outside of web applications because it's not relevant to the student's learning.

  Describing Node as "a bunch of C++ modules from Google Chrome V8 engine" will be very confusing to students because they have no idea what that is. Also the following sentence- "an actual file called node.js which takes your..." is also too confusing to students because these are all new words and concepts that they haven't been introduced to yet. Well we can assume they know about Events because they've covered Angular already, but discussing the very specific mechanics of Node again is overwhelming for students.

  In general, don't introduce concepts without having explained them thoroughly. Always move from the known to the unknown. You want to make students understand before they even learn about non-blocking I/O why non-blocking I/O matters. Really go in detail with how things in Rails (becuase this is the only back-end framework students will know up to now) work, explain the pain points with that, and then introduce non-blocking I/O. Then actually describe it.

  Non-blocking I/O

  • I like that you start with the Starbucks analogy. This is great, and you can even remove the first sentence ("One of the bigggest advantages of using Node...") and just go right into the metaphor. One thing is to be a little bit more clear at times with the metaphor. For example, in the second paragraph, you can change it to "Of course we know that making a coffee or tea is easy; just the liquid and its done. But what about those fancy..."
  • The second to last paragraph that starts with "This is not good, right?" is a little confusing in that I still don't understand what's going on with ordering a drink and leaving the queue. It's also confusing because the analogy starts off with Starbucks being an example of something that's not like non-block I/O and then moves later to an example of one that is non/block I/O. If you can be more clear and explain all the parts of the metaphor, that would be great.
  • After the metaphor then you can actually introduce non/blocking I/O and this should be the first time its mentioned at all in the reading, because the students have been primed for it. You don't need an elaborate description, but I think so far what we have here in the Readme doesn't really define or describe what it is.

  Node vs Others
  I think you can take out the first paragraph. It's a nice-to-have but doesn't really help students with their learning and instead is simply just content. (One of the reasons why we really emphasize starting off with learning objectives)

  When you tak about isomorphic or full-stack JS, again start with a metaphor or a concept that students already know. Again, we can assume that students know using Rails for a back-end framework and a JS front-end framework. Discuss what the limitations or difficulties of that are and its effects. Be very specific, and then introduce the idefa of a isomorphic/full-stack JS as the solution.

  Node History
  I like that you mention this isn't something that students need to know, but you make it very easy and quick and a good reference for students.

  Node in Web Development
  I think you can remove the first paragraph. Instead substitute it for actually discussing web servers and how other frameworks typically work with them. Then you can jump into how Node works. I think the second paragraph isn't concrete enough; can you flush it out more?

  The last two paragraphs here are also a bit vague and not very detailed enough. I'm not sure if they're necessary, but I'll leave that for Joe to decide.

  Node in Other Development Environments
  I think we can take this paragraph out, and can just stay with web development.

  Node Ecosystem
  This is also the first stime students are learning about package management. So the sentences that you ave especially in the beginning is foreign and students will be lost. It's better to start with Ruby and tie package management to gems and then cover npm. Again always introduce what the student would know before what they don't know. I think this section can be expanded a bit to be more clear to students.