Why Node.js?

In case you haven’t noticed, IBM’er Tim Rowe and his team have been delivering a tremendous amount of open source the past few years–sometimes through vendor relationships and sometimes directly from IBM. While frequency has increased as of late, open source has actually been a mainstay on IBM i and its predecessors for a very long time. It started with the Apache web server, then Java, then PHP and MySQL, Ruby, Node.js, Python, and even more you haven’t even heard of. Open source (in particular Node.js) will be the topic of this article. But first, let me give you some background on my history with RPG.

My primary language for 12 years was RPG. When I gave sessions at conferences I was fond of saying, “There’s very little you can’t do in RPG”. Having this mantra produced much of the open source you’ll find at mowyourlawn.com. I shared because I knew if each shop had to start at ground zero we’d make very little progress as an overall community of developers. This process was fun for a while, but I eventually realized I wasn’t meeting deadlines because I spent so much time writing plumbing code.

Around that same time I was part of a Ruby on Rails project. I came to the realization that the size of the community (and inherently the amount of open source tools available) has a fairly direct correlation to how quickly business solutions can be delivered. It isn’t the RPG language that’s the issue. Instead it’s us, the RPG community. There are too few of us producing open source for others to build upon. For every RPG open source project there are a thousand open source projects in other languages. Not having the same tools as other businesses to move forward fast puts our businesses at a disadvantage. For years I was so focused on language wars (RPG vs. everything else) that I became negligent to the greater goals of the business I worked for. I wasn’t objective.

So what does one do? I started developing a formula to determine whether a given technology should be pursued or adopted. I looked at things like the community. How do they collaborate? How often do releases occur? How long has the technology been around? What licensing does it operate under? Do they have the backing of commercial entities? Is it a “Here today, gone tomorrow” technology? In short, how do I lessen business risk by the technology I choose to align with?

That leads us into this article’s topic of “Why Node.js”? Why not PHP? Or Ruby? Or Java? Or Python? Each of those languages has significant communities and commercial players backing them. Why would one consider Node.js?

Node.js has one advantage none of the other languages have: a single language for both the client and the server.

This is significant because it correlates to our finite ability to maintain knowledge of an entire programming stack. Typically in a web application scenario you’ll have “front-end developers” and “back-end developers” because it’s rare to find a personality that operates well in both areas. That’s because there’s only so much time in a day to keep up with ever-changing languages, syntaxes, and frameworks. To put this into perspective we need to look no further than the RPG green screen programming model, where you could have a single developer coding an entire application (i.e., order entry, inventory, shipping, etc.). How was that possible? Because there wasn’t as much technology to grapple with. While I don’t believe I’ll ever be able to say web programming is as simple as RPG plus *DSPF, I will say Node.js is seemingly the closest we’ve been on a couple of fronts, because again, it lessens the amount of technology needing to be maintained by a single individual.

Node.js was born in 2009. Initial usage was fairly risky, yet “cool”. Obviously “cool” isn’t a good reason to adopt new technology in business. In 2011 a package manager (npmjs.com) was created. The Node Package Manager (npm) allowed developers to easily share their efforts with one another. That elevated Node.js from “cool” to “getting popular” and somewhat less risky. Yes, popularity lessens risk.

As Node.js gained popularity there were many opinions as to the direction it should take. In 2014 opinions became so heated that a separate project, io.js, was formed. Having a community split down the middle is obviously not good. In February of 2015 the differences were resolved and the Node.js Foundation was formed. All the while, and up to present day, there have been very big names that have adopted Node.js as a key technology for furthering their businesses. In particular GoDaddy, Groupon, IBM, LinkedIn, Microsoft, Netflix, PayPal, Rakuten, SAP, Voxer, Walmart, and Yahoo!. Those are some big entities. With their embrace of Node.js, risk was further lessened. But that’s not even the most interesting thing to me. What I find fantabulous is the fact that IBM and Microsoft, both creators of programming languages, are both now working on furthering a common language–Node.js. (Or Javascript for the purist. Or ECMA for the purest purist).

Some sightings of this confluence include Microsoft’s submission of its Chakra JavaScript engine to Node.js. Microsoft is also creating a next generation of Visual Studio using (you guessed it), Node.js. Then IBM recently purchased StrongLoop, one of the prominent players in the Node.js space. Suffice to say, Node.js has far surpassed being just cool. It now has significant foundation and probably, most importantly, incredible momentum.

All my commentary leads up to this personal assessment: Node.js has shed its risk enough for IBM i shops to embrace it within business.

To this point of the article, I’ve spoken largely to the IT manager who’s assessing Node.js as a potential technology to adopt. Now it’s time to dig deeper look under the covers of Node.js.

Node.js is essentially a collection of Javascript APIs that are geared toward server-side network programming, usually web browser type applications. Javascript on the server was made possible by porting Google’s V8 Javascript engine. IBM made Node.js to run on Power chipsets. That means it also works on IBM i.

IBM has been delivering much more bang for your buck the past few years. Take a look at all the enhancements on the developerWorks IBM i page. IBM started delivering Node.js for IBM i in late 2014 via the 5733OPS licensed program, which is no additional cost if you’re paying maintenance. (I say this because often enough I come across people saying, “I can’t run Node.js because I am on V5R3 or V5R4”. Well, upgrade already! And pay maintenance!)

IBM has put together a decent amount of documentation for Node.js on IBM I here, including how to obtain and install, so we won’t be covering installation here.

Like any good introduction we will start with a “hello world” scenario. Node.js runs in the PASE environment on your IBM i. PASE is essentially AIX, except instead of using the AIX kernel, it uses IBM i for its kernel. This means we need to “get into” the PASE side to run Node.js programs. To do that we issue CALL QP2TERM from the green screen command line. This places us in what’s called a shell, as shown below.

A shell is a command line interface where you can enter a variety of commands. For an intro to a better shell, see Bash Is Not a Shell Game.

As you can see in the screenshot, I am presented with the dollar ($) sign. This is the prompt that waits for me to enter a command. This is very similar to how the 5250 command line works, though a shell can go much further. I typed “pwd” so you can see what directory I am currently in. In this case it’s my profile’s /home directory.

Now let’s compose our first Node.js program. Run the below command in the shell or use some other tool to create a file named “hi.js” and place “console.log(‘hi world’)” in it.

echo "console.log('hi world')" > hi.js

Now run the below command to invoke the program hi.js.

node hi.js

You should end up with something like the following.

How did that work? Well, first PASE went in search of the command named “node”. In PASE there are environment variables that hold values. One is named “PATH”. The “PATH” environment variable contains all of the directories that will be searched when commands are entered. We can display the contents of environment variables using the “echo” command, as shown below.

> echo $PATH
/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin

Above we see many paths separated by colons. But where does the “node” program exist? We can use command “which node” to learn the location, as shown below.

> which node
  /QOpenSys/usr/bin/node

As you can see the “node” program exists in /QOpenSys/usr/bin/node. However, that’s not exactly true because what we see is a shortcut to the actual program, also known as a symbolic link. To learn the exact location of any program or command we can use the “ls” (list) command, as shown below.

ls -l /QOpenSys/usr/bin/node
lrwxr-xr-x    1 qsys 0
74 Feb  2 11:07 /QOpenSys/usr/bin/node -> /QOpenSys/QIBM/ProdData/Node/bin/node

Notice the “l” at the beginning of the line denoting this is a symbolic link. Then in the latter part of the line we can see where it points, /QOpenSys/QIBM/ProdData/Node/bin/node. This is where IBM installs Node.js.

Going back to our “hi.js” program, once the “node” program has been located then the node program takes over and receives in any parameters that are passed. In this case we pass a single parameter, the Javascript program we wish to invoke. Now Google’s V8 engine, which exists in the IFS, will convert hi.js to machine code and run it.

That’s it. You’ve created your first Node.js program. Obviously that’s nothing to write home about but it gives you a foundation to build on. Press F3 to exit QP2TERM.

Next I will introduce you to what’s called the Node.js REPL, an interactive command-line programming environment for Node.js. REPL stands for Read, Eval, Print, and Loop.

Below is the Terminal application on my Mac that is using the SSH program and protocol to enter into a shell on my IBM i. A similar tool for Windows would be putty.

In the screenshot I show how to check which Node.js version is in place with node -v. Then I type “node” without any parameters. That will enter me into the REPL. I know I am in the REPL because the command prompt changes to a greater than sign (>). At this point I can either type Javascript manually or paste an entire chunk of code. Once I am done I can return to the shell by typing “.exit”. To end the shell session you can type “exit”.

I can’t emphasize enough how useful the Node.js REPL is for learning and debugging Node.js (and Javascript) on the server. For example, when I am writing Node.js to interface with a particular RPG program I will often paste it into a REPL to quickly run it and learn of any errors. If it does error then I make a change and paste the code again.

Ok, now that we’ve been exposed to the command line let’s take it to the next level by introducing a web application that does “Hello World”. Create a new file named “app.js” in the IFS using the method of your choice and paste the following code into it.

var http = require('http')

function handle_request(req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'})
  res.end('Hello Worldn')
}

var http_server = http.createServer(handle_request)
http_server.listen(8282, '192.168.0.5')

console.log('Server running')

Here’s how that breaks down:

• The first line uses the “require(…)” API to bring in outside functionality, much as we do with “/COPY” in RPG.
• Next, we define a function named “handle_request” that receives in two parameters, a request and response object. Javascript functions are similar to RPG subprocedures.
• We create an HTTP server and pass the “handle_request” function as a parameter. You read that right, we are passing a function as a parameter that is a new concept to my RPG brain. Not only that, but we also store the result of “http.createServer(…)” into a variable, which is also a Javascript function.
• Everything comes together as we start listening on port 8282 for the IP of this machine (change it to be your own).
• Finally, we output “Server running” so we know when the server has completed its startup.

There are a couple of interesting things to note about what just occurred. First, Node.js has its own web server. That’s right, I didn’t need to front it with Apache. Although I certainly can if need be. Second, the concept of “call backs” is introduced by way of how we specified “handle_request” as a parameter on the call to “http.createServer(…)”. A call back is similar to a procedure pointer in RPG. When a request comes in from the browser, processing will be handed off to whatever Javascript function is specified on “http.createServer(…)”.

To start this application we issue the following command from a PASE shell.

node app.js

Now point your browser at the IP and port you specified in your program. You should see something similar to this:

And there you have it. Your first Node.js program! You can end the server by typing “Ctrl + C” in the PASE shell.

Stay tuned for a next article showing how to access your DB2 tables from Node.js using the webix.com front-end Javascript library. Also, check out the IBM i Node.js group on LinkedIn. It is effectively a “water cooler” gathering place to discuss Node.js as it relates to IBM i.

As always, if you have any questions feel free to contact me directly at abartell@krengeltech.com.

Aaron Bartell is Director of IBM i Innovation for Krengel Technology, Inc. Aaron facilitates adoption of open source technologies on IBM i through professional services, staff training, speaking engagements, and the authoring of best practices within industry publications and www.litmis.com. With a strong background in RPG application development, Aaron covers topics that enable IBM i shops to embrace today’s leading technologies including Ruby on Rails, Node.js, Git for RPG source change management and RSpec for unit testing RPG. Aaron is a passionate advocate of vibrant technology communities and the corresponding benefits available for today’s modern application developers. Connect with Aaron via email at abartell@krengeltech.com. Aaron lives with his wife and five children in Southern Minnesota. He enjoys the vast amounts of laughter having a young family brings, along with camping and music. He believes there’s no greater purpose than to give of our life and time to help others.

RELATED STORY

Bash Is Not a Shell Game