Book Image

Deploying Node.js

By : Sandro Pasquali
Book Image

Deploying Node.js

By: Sandro Pasquali

Overview of this book

Table of Contents (14 chapters)
Deploying Node.js
About the Author
About the Reviewers

Using full-stack JavaScript to maximum effect

JavaScript has become a full-stack language. A native JavaScript runtime exists in all browsers. V8, the JavaScript interpreter used by Node, is the same engine powering Google's Chrome browser. And the language has gone even further than covering both the client and server layers of the software stack. JavaScript is used to query the CouchDB database, do map/reduce with MongoDB, and find data in ElasticSearch collections. The wildly popular JavaScript Object Notation (JSON) data format simply represents data as a JavaScript object.

When different languages are used within the same application, the cost of context switching goes up. If a system is composed of parts described in different languages, the system architecture becomes more difficult to describe, understand, and extend. If different parts of a system speak differently, every cross-dialect conversation will require expensive translation.

Inefficiencies in comprehension lead to larger costs and more brittle systems. The members of the engineering team for this system must each be fluent in these many languages or be grouped by different skill sets; engineers are expensive to find and/or train. When the inner workings of significant parts of a system become opaque to all but a few engineers, it is likely that cross-team collaboration will decrease, making product upgrades and additions more difficult and likely leading to more errors.

What new opportunities open up when these difficulties are reduced or eliminated?

Hot code

Because your clients and servers will speak the same language, each can pass code to be natively executed on the other. If you are building a web application, this opens up very interesting (and unique) opportunities.

For example, consider an application that allows one client to make changes to another's environment. This tool allows a software developer to make changes to the JavaScript powering a website and allows their clients to see those changes in real time in their browsers. What this application must do is transform live code in many browsers so that it reflects changes. One way to do this would be to capture a change set into a transform function, pass that function across to all connected clients, and have that function executed in their local environment, updating it to reflect the canonical view. One application evolves, it emits a genetic update in the code of JavaScript, and the rest of its species similarly evolves. We will use one such technology in Chapter 7, Deploying and Maintaining.

Since Node shares the same JavaScript code base, a Node server, on its own initiative, can take this action. The network itself can broadcast code for its clients to execute. Similarly, clients can send code to the server for execution. It is easy to see how this allows hot code pushes, where a Node process sends a unique packet of raw JavaScript to specific clients for execution.

When Remote Procedure Calls (RPC) no longer require a broker layer to translate between communicating contexts, code can exist anywhere in the network for as long or as brief a period as necessary and can execute in multiple contexts, which are chosen for reasons of load balancing, data awareness, computational power, geographic precision, and so on.


JavaScript is the language common to Node and the browser. However, Node significantly extends the JavaScript language, adding many commands and other constructs that are not available to the client-side developer. For example, there is no equivalent of the core Node Stream module in JavaScript.

Additionally, the npm repository is rapidly growing, and, at the time of writing, contains more than 80,000 Node packages. Many of these packages are equally useful on the client as well as within Node. The spread of JavaScript to the server has, in effect, created two cooperating threads producing enterprise-grade JavaScript libraries and modules.

Browserify was developed to make it easy to share npm modules and core Node modules seamlessly with the client. Once a package has been browserified, it is easily imported into a browser environment using the standard <script> tag. Installing Browserify is simple:

npm install -g browserify

Let's build an example. Create a file, math.js, written as you would write an npm module:

module.exports = function() {
  this.add = function(a, b) {
    return a + b;
  this.subtract = function(a, b) {
    return a - b;

Next, create a program file, add.js, that uses this module:

var Math = require('./math.js');
var math = new Math;

console.log(math.add(1,3)); // 4

Executing this program using Node on the command line (> node add.js ) will result in 4 being printed to your terminal. What if we wanted to use our math module in the browser? Client-side JavaScript doesn't have a require statement, so we browserify it:

browserify math.js -o bundle.js

Browserify walks through your code, finding require statements and automatically bundling those dependencies (and the dependencies of those dependencies) into one file that you load into your client application:

<script src="bundle.js"></script>

As an added bonus, this bundle automatically introduces some useful Node globals to your browser environment: __filename, __dirname, process, Buffer, and global. This means you have, for example, process.nextTick available in the browser.


The creator of Browserify, James Halliday, is a prolific contributor to the Node community. Visit him at Also, there exists an online service for testing out browserified npm modules at The full documentation can be found at

Another exciting project that, like Browserify, leverages Node to enhance the JavaScript available to browser-based JavaScript is Component. The authors describe it this way: Component is currently a stopgap for ES6 modules and Web Components. When all modern browsers start supporting these features, Component will begin focusing more on semantic versioning and server-side bundling as browsers would be able to handle the rest. The project is still in flux but worth a look. Here's the link: