If you are a PHP Developer maybe you are used to write your server-side code in PHP and then you make run your code on a web server like Apache. Javascript, from your point of view, it’s simply a client-side scripting language and you use it to handle the front-end client business logic on a web page. A front-end developer might argue that with javascript is possible to manipulate the DOM via a library such as JQuery. You can do more than this. With one language you could code client-side and server side of a web application. Your brain context-switching will say “Thank you”. This is actually a benefit, for both developers and other company’s stakeholders (Search on google “the cost of context-switching for developers”).
So, it may sound strange to hear “Write your server-side code in Javascript using Node.js techonology“.
Anyway, you are here because you don’t understand why you should use Node.js to develop web applications.
Take a rest, drink a coffee and continue to read this article.
What is Node.js?
Node.js is an event-driven I/O server side Javascript Enviroment based on Google’s V8 Javascript Engine. Node applications are created with JavaScript.
You have to use Node.js if you want to build fast, scalable network applications with a huge number of simultaneous connections. Node.js fits well in building real-time web applications with push technology over websockets (Finally we have two-way connections, where both the client and server can initiate communication).
You don’t have to use Node.js if you want to build a CPU-intensive application. Web applications are computationally simple.
Node has a built-in support for package management using the NPM tool (https://npmjs.org), set of publicly available, reusable components, available through easy installation via an online repository, with version and dependency management.
Node under-the-hood: event-driven programming VS thread based programming
Node.js lives on a single-thread, using non-blocking I/O calls, allowing it to support support tens of thousands of concurrent connection. All events are stored in the event-loop and are handled asynchronously using callback functions as event handlers. This means that applications don’t wait for an input/output process to finish before going on to the next step in the application code.
Therefore the key concept is that Node is single-threaded, but event-based.
How does Node process a new request?
Just for the sake of this example, let’s say that there is a Node’s app receiving a new database access request. Node sets up the request properly, attaching a callback to the request and then it continues to do something else. When whatever has been requested is ready (or finished), an event is emitted to that effect, triggering the associated callback function to do something with either the results of the requested action or the resources requested.
Of course, on the backend, there are threads and processes for DB access and process execution.
however, these are not explicitly exposed to your code, so you can’t worry about them other than by knowing that I/O interactions e.g. with the database, or with other processes will be asynchronous from the perspective of each request since the results from those threads are returned via the event loop to your code. Compared to the Apache model, there are a lot less threads and thread overhead, since threads aren’t needed for each connection; just when you absolutely positively must have something else running in parallel and even then the management is handled by Node.js.
PHP itself does not respond to the actual HTTP requests – this is the job of the web server.
So what we do, is configure the web server to forward requests to PHP for processing, then receive the result and send it back to the user.
Typically a web server such as Apache when it receives a new connection request, either it spawns a new thread (called the Worker MPM) to serve it or it forks a new process (see Prefork MPM which uses Processes), it depends on configuration. Creating a new thread/process is not a free operation. You have to pay in terms of system resources, especially the RAM. A popular web application could have serious performance issues. Consider also that spawing a new thread require that all applications shall be thread-safe (PHP is thred-safe but other libraries?) and what about controlling access to shared resources? This’s a big headache!
Unlike with other single-threaded applications, when you make a request to a Node application and it must, in turn, make some request of resources (such as a database request or file access), Node initiates the request, but doesn’t wait around until the request receives a response. Instead, it attaches a callback function to the request. When whatever has been requested is ready (or finished), an event is emitted to that effect, triggering the associated callback function to do something with either the results of the requested action or the resources requested.
If five people access a Node application at the exact same time, and the application needs to access a resource from a file, Node attaches a callback function to a response event for each request. As the resource becomes available for each, the callback function is called, and each person’s request is satisfied in turn. In the meantime, the Node application can be handling other requests, either for the same applications or a different application.
Though the application doesn’t process the requests in parallel, depending on how busy it is and how it’s designed, most people usually won’t perceive any delay in the response. Best of all, the application is very frugal with memory and other limited resources.
Take a glance to this video
References
- http://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js
- http://www.toptal.com/javascript/guide-to-full-stack-javascript-initjs
- http://webapplog.com/php-vs-node-js/
- https://code.google.com/p/v8/
- http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
- http://stackoverflow.com/questions/3629784/how-is-node-js-inherently-faster-when-it-still-relies-on-threads-internally
- http://codehenge.net/blog/2014/01/what-is-node-js/