Write Web Applications Using JavaScript With Node.js

Gimme sugar, baby! You may have heard about Node.js, a recently released platform that’s a means to write Web applications using JavaScript on the server. When I’m learning about a new technology, I always like to get something working in as short a time as possible, so let’s do that with this article and subsequently dive into details.

First, head to the IBM i Node.js developerWorks site to learn now to install the free IBM licensed program 5733OPS. Not an option to install Node.js on your IBM i? Check out runnable.com for now.

Once the install of 5733OPS is complete, you can run the following commands in PASE to set up your environment. Setting these variables lets you invoke Node.js from any directory while in PASE. To run the commands in PASE you can either CALL QP2TERM from the 5250 command line or SSH into your machine using a terminal client (I like this Chrome plugin). If you’d like more info on SSH config for your IBM i then please check out this page I’ve set up.

$ export PATH=/QOpenSys/QIBM/ProdData/Node/bin:$PATH
$ export LIBPATH=/QOpenSys/QIBM/ProdData/Node/bin:$LIBPATH

This is similar to how a library list works: The PATH environment variable declares what directories should be searched when commands are run. Similarly the LIBPATH environment variable declares where to look for shared libraries that the node binary requires. Note a “shared library” is completely different than a QSYS.LIB library.

Now we can test to see if we have access to the node binary by typing the node -v command, as shown:

$ node -v
v0.10.29

Success! Next simply type “node” at the command prompt to start up what’s called the Node.js REPL. The Node.js REPL is an interactive environment that lets you enter Node.js statements for immediate invocation. Figure 1 is a screenshot of an SSH session into my IBM i using the Chrome plugin I mentioned. The first thing you see is the addition of 2 + 2, which results in, obviously, 4. This is REPL in action—read, evaluate, print and loop. Most anything you’d write in a Node.js program can be placed into the REPL. I’ve become a big fan of REPLs (Ruby has one also) for the purposes of not only learning a new technology but also as a means to quickly test code. To return to your PASE shell, type .exit.


Figure 1

Now let’s take things a step further by creating our first Node.js Web application. Create a file in the IFS named server.js (i.e., put it in /home/aaron/server.js, replacing “aaron” with your own profile). Place the following code into the server.js file and save it:

var http = require('http');
http.createServer(function (req, res) {
 res.writeHead(200, {'Content-Type': 'text/plain'});
 res.end('Hello World\n');
}).listen(1337, '0.0.0.0');
console.log('Server running at http://0.0.0.0:1337/');

Now go back to your PASE shell session and run the following two commands:

$ cd /home/aaron/
$ node server.js

Note that your PASE shell session will now be tied up and you won’t be able to enter commands, as shown in Figure 2. Use Ctrl+C to end the server.

Figure 2

So what happened? Running node server.js is like calling an RPG program. In this case, the server.js program contains not only a small hello world application but also an entire Web server! That’s right; you now have a Web application up and running on your IBM i. You can test this by loading URL http://ibmi_ip:1337 in your browser (replace “ibmi_ip” with your IBM i IP address), as shown in Figure 3. This is admittedly significantly simpler than my first RPG-CGI application.

Figure 3

The first line of the program with require is similar to a /copy in RPG—bringing functionality into the program, in this case HTTP capabilities necessary for running a Web server. The next line, http.createServer, is setting up the HTTP server to listen on port 1337. Specifying 0.0.0.0 for the IP simply means it will listen on the local machine’s IP address (i.e., localhost). The parameter passed into it is what’s called an anonymous function. The code within the anonymous function will be invoked whenever a request comes into port 1337. In this case, the code is simply outputting an HTTP header and with “Hello World” as content.

Now that we’ve had a bit of sugar, let’s go back and discuss some facts about what Node.js is and isn't. First a wikipedia.org definition:

Node.js is an open source, cross-platform runtime environment for server-side and networking applications. Node.js applications are written in JavaScript, and can be run within the Node.js runtime on OS X, Microsoft Windows, Linux, FreeBSD, and IBM i.

OK, guilty. I’m the one who added the IBM i reference in the Wikipedia page. I found the easiest approach to convey thoughts on Node.js was to give a list, so here we go:

• Started in early 2009 by Ryan Dahl of Joyent, but is now driven by the community.
• Node.js is built on JavaScript, which is not in any way, other than name, related to Java.
• Uses Google’s V8 JavaScript runtime under the covers, which IBM also ported.
• Runtime is written in C (doesn’t run atop the JVM, if that’s what you were thinking)
• Primary goal is to build scalable network applications with JavaScript on server-side.
• Not a Web framework, though many Web frameworks have been written on top of it.
• Hasn’t reached version 1.0 (currently at version 0.10.35 as of this writing). This means some APIs are subject to change. The good thing is they give a “stability” rating for each API.
• Has its own package manager named npm, which makes it much simpler to resolve and download dependencies. Note some packages require compiling and you must load Python and possibly gcc.
• Has its own module system for code organization. This initially threw me for a loop because I couldn’t find it in my normal JavaScript resources.
• Not all JavaScript you’ve used in the browser will work on the server-side in Node.js. For example, document.write() will fail.
• JavaScript, and inherently Node.js, attains concurrency more through events where other models do this more through separate processes (aka, IBM i jobs) or threads within the same process. That’s not to say Node.js is single-thread-bound. This article describing Node.js for .NET developers actually does a good job of explaining why Node.js is considered single-threaded, yet can still use multiple threads.
• It’s considered “non-blocking,” which basically means it can continue on with other statements in the program without waiting for longer processes (like interacting with the file system). The non-blocking nature of Node.js is an article in itself so we won’t be digressing into it here, though I will offer up this YouTube video from codeschool.com that gives a great explanation.
• One of the most intriguing aspects of Node.js for me is that you’re now using the same language on both the client and server. This will inevitably make a Web developer more efficient because not only is there less syntax to be mindful of but also there’s a lot of code sharing that can happen between client and server.

Hopefully that gives you a high-level understanding of Node.js. If you haven’t done so already, you’ll need to learn JavaScript. One of the most different things I had to learn in JavaScript was the various ways functions worked. Go here to learn more about the ways JavaScript functions are different than other languages. In particular take a peek at “Anonymous,” “Self-Invoking” and “Closure” functions.

If you’re at the very beginning of your JavaScript journey, I'd encourage you to start with W3Schools (free), which have some of the most concise, yet still helpful and relevant, training around. Another helpful resource is Guru99, which offers a C programming tutorial. The codeacademy.com (free) site is also a good place to start your JavaScript journey. Once you’ve got JavaScript under your belt, you can check out some of the other hands-on Node.js training like nodeschool.io (free) or codeschool.com ($29/month).

Stay tuned for a next article showing how to access your DB2 tables and RPG programs from Node.js. This is great because it lets you capitalize on your existing investment. Also, check out the IBM i Node.js group on LinkedIn—effectively a “water cooler” gathering place to discuss Node.js as it relates to IBM i.