Node.js Is Here for the Long Haul
Charlie Guarino: Hi everybody. This is Charlie Guarino. Welcome to another edition of TechTalk SMB. Today I’m very happy to have with me—well if I look at the bio, I see a software developer at IBM working on enabling open-source software packages for IBM i. But quite literally in the last 30 minutes or so there has been a change in position, and that is that this person now is now an advisory software developer at IBM. I’m speaking about none other than Mr. Mark Irish. Mark, what a treat it is to have you here today.
Mark Irish: Yeah. Thank you so much for having me, Charlie.
Charlie: All right so this new title jumps right out at me and I have to ask, first of all, how does somebody go from software developer to having a position as an advisory software developer, and secondary, what is an advisory software developer?
Mark: Well when you start out at IBM, usually as a developer, you start out what’s called Band 6, and that is just the run of the mill software developer. That’s what I started out as back in May of 2018. About a year and half after that, I was promoted to Band 7, which is where I’ve been for a little while, and that was staff software developer, staff software engineer. I’m not sure what I had on LinkedIn and yeah, just today I got another promotion and I got bumped to Band 8, which is the advisory software developer role. So yeah, it’s just a mark of IBM’s confidence in me, that they’re saying we want to invest more in your career. We think that you’re doing good things. Keep doing the good work and they’re already telling me that they’re going to give me more responsibility and more work to do. So they’ll just keep piling it on until I tell them that I’ve had enough, I think.
Charlie: So it’s a true recognition, in my view, of what you’re contributing not only to IBM but to the community at large.
Mark: Yeah absolutely, and it’s also a sign of IBM’s investment in the platform itself, right? We have only so many promotions, only so many hires that go around for things like this, and IBM is saying hey, we need to put these resources into the IBM i space, especially open-source on IBM i.
Charlie: Right, which is obviously in my view is truly one of the fastest growing areas of growth on our platform. You know Mark another thing that caught my attention just in reading the rest of your bio here was I see a Bachelor of Science in computer science, and that obviously makes sense given your role at IBM. But I was kind of struck by your Master’s degree, and that’s in anthropology—
Mark: Yup, that’s right.
Charlie: I mean I know a lot of people who start college who graduate with different degrees, but to have a Master’s degree in something that’s totally unrelated seems a little more, for lack of a better term, obscure. But I don’t mean in a bad way, just seemingly different than some—you know I would think maybe the reverse might have happened, starting on anthropology and then focusing more on CS. So how did that happen?
Mark: Yeah, so my father is an IBMer. He’s been at IBM for nearly 40 years, and so when I went to college, I did what a lot of young men do and I rebelled against what my father stood for, right? So I went and I got a Bachelor’s degree. I tripled majored in classical languages, biblical languages and anthropology.
Charlie: Triple majored.
Mark: I’m Indiana Jones growing up: wanted to be outside, wanted to do archaeology, got into a PhD program at the University of California-San Diego for anthropology, and as I was there, they had an opportunity of kind of an institution. They had a grant from the National Science Foundation, basically to do cyber archaeology, where they were trying to blend technology with archaeology, and so I kind of wanted to be part of that. I started taking some computer science classes with a bunch of undergrads. I was 26 years old with all these 18-year-olds—which at the time I felt old, but now that I’m 33, I realize I was still pretty young—and I really gravitated towards it. I really loved the work, I really loved the problem solving. I really loved just that sort of whole way of thinking. And so after I got my Master’s degree, I realized I really didn’t want to get a PhD, so I dropped out and I went back to school to get another Bachelor’s degree. As fate happens, I got hired at IBM immediately out of college and was working in the building one away from where my dad was working—
Charlie: Wow. So you’re really well-credentialed to work on the real topic of the conversation, which is Node.js. All these credentials you’re expounding here really put you in the right spot at the right time for this.
Mark: Sure, yeah.
Charlie: Okay. You mentioned problem solving and things like that, so I guess given that then, I’m not surprised because you know really in that regard, almost any major that focuses on problem solving—be it anthropology or anything else, even music composition for example—you really could make a case that it almost runs lockstep with somebody who would be working in IT.
Mark: Absolutely and you know I had a conversation recently at POWERUp in New Orleans with Steve Will, the CTO of IBM i, chief architect, and we were talking about how some of the best developers aren’t the people who go in with their big math pedigrees and computer science pedigrees. They’re the people that do other things—liberal arts degrees—and then they just have a passion for computer science on the side, right? It’s those people that kind of have a broad perspective of the world around them that tend to be the best problem-solvers and have the best perspective.
Charlie: I agree. I mean I do recall somebody who was working at IBM in the 1960s. I wasn’t working at IBM in the 60s—or working in the 60s at all quite frankly—but they told me there really wasn’t even a CS degree, but they were hiring language and math majors. So anyway enough about that. The real reason why you’re here is because of Node.js, and that’s where there seems to be—or not seems to be. I know there’s a high degree of interest in this technology, the interest is there certainly—but there’s also perhaps even for lack of a better term, a shroud of mystery about what Node is. While it’s been out for quite some time, it is still in my view one of the newer kids on the block and a lot of people aren’t really exposed to it that often. So there are still a lot of questions that are surrounding it, which I think you could be very helpful now to fill in the blanks for us.
Mark: Absolutely.
Charlie: So my very first question is what exactly is Node.js, and where do we—you know, let’s start from start.
Mark: Let’s start from the beginning. What is Node.js, right? So Node.js is nothing more than a JavaScript runtime. So it runs on your computer. For most of the people listening, that will be an IBM i system, and basically it just allows you to run JavaScript code. And that JavaScript code can do things with the computer like interact with the file system or make I/O calls to system devices, talk to the database, make network requests, things like that. So for a long time JavaScript was kind of isolated to just the browser, right? You’re talking about JavaScript, you’re thinking about people running these things on their browser. Maybe they’re making ajax calls, which are these asynchronous calls in the browser. Maybe they’re validating some form data, stuff like that. But somebody had the bright idea—well hey, what if we could take that same language but make it do the types of work that PHP would do or that Java web server would do, or even something like C or C++ code could do, right? So it’s the same language that’s been around for a long time, but now it’s in a new environment doing different types of work.
Charlie: So is it fair then to say—because one definition I’ve heard that I’ve kind of stuck with through the years is that Node is essentially kind of like JavaScript, or almost is JavaScript, I suppose, in a browser, whereas Node is that same technology it’s running on. So it’s service side vs. browser side. Is that a fair definition?
Mark: That’s a very fair definition. A lot of times you’ll hear people say that Node.js is a JavaScript service. They’ll say it’s the service and JavaScript I would say—or sorry, Node.js I would say—80%-90% of the time people are using it as a service, right? They’re using it as a web service to serve up content to the back end of some sort of web service, REST API, something like that. But it really is agnostic to what you do with it. I have personal projects where I do stuff and it’s not really communicating with a network at all. It’s just doing some piece of computational work for me.
Charlie: So it’s a pure batch language at that point. It’s a computation—
Mark: Yeah, pretty much. It’s just a scripting language if you want, yeah.
Charlie: Right, right. So is there a real distinction then that you can make between Node and JavaScript?
Mark: Node is just kind of the environment that JavaScript is running. So when you go to a website and your browser is running some sort of JavaScript code, usually if you’re using something like Chrome or Microsoft Edge it’s probably using Google’s V8 JavaScript engine. That’s what interpreting the JavaScript and doing the actual work. Node.js actually runs with that exact same engine, and then it’s just built to have hooks into the operating system. You don’t want your browser to have those same hooks because then people could do sort of all sorts of malicious things, but if you have some sort of back-end service, now Node.js as that back-end service can do those things I talked about, like talking directly to the file system or making network calls.
Charlie: All right, that’s interesting. I guess my next question then would be so how and where it is used? I mean I get it’s running on a server, I understand that, but where is its place in a modern technology stack?
Mark: Sure. So if you’re talking about the technology stacks that you and I interact with most frequently, people running RPG programs and then they probably have some sort of front-end web service running maybe Apache with PHP or some Java web server. Node.js usually takes the place of that kind of Apache and PHP part of the equation or the Java web server part of the equation, right? It’s sitting there. It can talk down to have a negative connotation, but it can talk into RPG and COBOL and other IBM i resources. And then it can really easily and natively talk to the wider World Wide Web, the internet, making those types of HTTP calls serving up your content.
Charlie: Well the good news is RPG and COBOL, they have very thick skins.
Mark: Yeah, they better. They get enough flack.
Charlie: Right. They’re still standing—doing quite well in fact—and being enhanced. So this is good. Okay, I’ve been to some of your sessions, Mark, and one thing that really comes through to me is just your passion for Node. I mean people tend to gravitate towards that passion because they see how excited you are about it and how committed you are to this technology. But what do you—speak to that for a minute. What do you attribute all that passion from, or how did you develop such a passion for Node? Was there something that was so unique about it that you really said, oh my gosh, this is where I want to be playing right now?
Mark: Well back when I was a grad student, taking those undergrad classes, I had a class where I had to develop some sort of web application, and we were told we had to use Node.js. I resisted it and I resisted it and I resisted it, and in my mind I was thinking why would I ever want to use this? I have an Apache server, I have PHP. I know how to use them. I can do the same stuff with them. But probably not during that class but sometime afterwards I started playing with Node again, and it clicked with me: the simplicity of it, the ease of use. It just became so clear to me that if I have an idea for something I want to do, something I want to program, I can start up a Node.js project and go from zero to some sort of minimal viable product within a much smaller amount of time than I would with something like Apache or PHP. It’s a really simple technology to use, and one of the reasons that it is really simple is there is a lot of code reuse that goes on out there, right? There’s this website called NPMJS.com, part of NPM, which used to be called the Node Package Manager. Now it doesn’t really stand for anything, but basically you can go out there and you can find packages that other people have written that implement a lot of the functionality of things you want to do. People have written entire web services. People have written frameworks for doing REST APIs, so you don’t have to reinvent the wheel. You can just focus on your business logic, the application, you know the fun stuff that you want to implement yourself.
Charlie: You know it’s interesting, Mark. My very next question actually—in my research in preparing for this podcast, the term that I kept bumping into was in fact NPM, and it seems to me that you cannot have a Node discussion without at some point mentioning those three letters. So what are they? I mean again, you said Node Package Manager, but what exactly is a package for those who may not even be aware of that, and how does NPM play into this conversation?
Mark: Sure. So Node.js comes pre-shipped with a number of APIs, and those APIs are very simple, right? They are things like talking to the file system, they are things like throwing errors. They are things like making HTTP requests, but making HTTP requests—you have to build it yourself. So what people have done is they have written these packages, which are kind of small to large chunks of reusable code that you can go and download and plug into your own application that wrap all of that API functionality and expose some new APIs that do much higher level types of work. So if you wanted to make some sort of REST API service, you don’t want to have implement all the HTTP calls yourself. Somebody has gone and written very simple REST API services where you can just reuse their libraries. You just have to go and download their package and read their documentation and integrate it into your application and you’re off to the races. Now you have a REST API service.
Charlie: So you push now the next button of mine, and I know a button of concern or topic of concern I should say from a lot of people—CIOs and the like—and now we’re using other people’s packages. You said it. Those are the words you just used and that clearly in my mind begs the question: How can I trust other people’s packages? You know how secure is it and how can I know that it’s quality code and it’s not going to corrupt my existing application or database or whatever the case happens to be?
Mark: Sure. It’s definitely a paradigm shift to be able to trust somebody out there, to download some code, to use it in your business-critical application, right? There are a number of things that kind of can waylay those fears. So first, it’s open-source, right? All of the code that’s up on NPM, the code for those packages is open-source, so you can go and you can pick through it and you can see okay, this is exactly what the code does, right? Other people can look at it as well and if they find bugs, if they find security vulnerabilities, they will notify not only the package managers but NPM itself—the package maintainers and NPM itself—and then there will like a security advisory for that package. Every once in a while you’re supposed to go and run a command called npm-audit, and it will say there are some security vulnerabilities for your packages. Make sure you download the latest version. So there’s safeguards that are out there. I like to think of some of the kind of the smell tests that people should do. If you go and you find a package that hasn’t been updated in six years and that has 30 downloads every week—this is data that you can see directly on NPM—you probably don’t want to download that package, right? Even if it's not a malicious package, there’s probably not a high level of maintenance with that package, so there might be undiscovered vulnerabilities in it. But a lot of these NPM packages, a lot of the big ones that you’ll hear about, big web services like Express or Happy.js, they have probably 50 million downloads a week. They probably have thousands or tens of thousands of contributors, people looking at every line of code that’s being delivered. So there’s a lot of eyeballs on this stuff and though it may seem scary that it’s open-source, it actually produces a much higher level quality of code than something that’s developed kind of in a black box that you don’t have purview to see.
Charlie: By one or a small group of developers.
Mark: Exactly.
Charlie: Just so we’re clear. I heard 50 million, and you said a week. Are those words meant to go together?
Mark: Yeah, we can go look. I’m going to go look right now. NPMJS. So I know that a package that I maintain gets 7,000 downloads a week, and it’s not a very big package. So let’s see Express. Oh, I’m sorry. It was only 25 million, but still.
Charlie: You know I expect a man of your integrity and your title to have [laughs]—
Mark: To get it right on, within a million at least.
Charlie: 25 million is paltry compared to that 50 million now.
Mark: So there are over 2 million packages on NPM and there is some dashboard where you can go and see how many downloads there are every week, but it’s in the like, 400 million something I want to say.
Charlie: Wow. That’s a real number.
Mark: It’s a real number. It’s the largest repository of software you can probably say in the universe, because nobody can prove me wrong. I don’t know if there exists any outside of earth—
Charlie: Sure, why not? I’ll bite. Why not? So within the context of IBM i, what packages are there that are specific to our universe, to reuse one of your words. What packages should we be looking at—or we should be working with I should say? What are they named and where do we get them, for example?
Mark: Sure. So just the same way that everybody delivers their packages on NPM, IBM also delivers the packages directly there on NPM. So we have, I think, four packages, four main packages, that we maintain, the IBM i open-source software team. Probably the oldest one—the one with the oldest pedigree—is called idb-connector, [IBM i] dash connector. The idb stands for [IBM] i database, and it is a database connector based on what is called the CLI interface. I think that’s redundant, like ATM machine, but call level interface basically, and that’s a way to call into Db2, right? The thing about these packages is it only works on IBM i itself, so if you’re developing on a Linux machine, it won’t work on your Linux machine. It needs to be run on IBM i in PASE, the Portal Application Solutions Environment. There is another package that kind of sits on top of that package, called IDBP-connector. This connector reuses a lot of the same functionality-in fact, it requires the idb-connector, but it adds pooling support for your connections and it also adds promise support for your connections—which is a very deep kind of Node.js concept that I won’t get into too much here—but it’s just a little more modern way of programming of Node.js. You can think of it kind of as RPG vs. RPG free [format]. It’s kind of the more modern way of doing things. So those are the two main what we call CLI connectors. Both only run on IBM i.
Charlie: And would use one or the other?
Mark: If you use idb-connector, it downloads idb-connector for you. It knows that it requires it as a dependency. It will download it as part of it. It requires it.
Charlie: But not vice versa?
Mark: But not vice versa.
Charlie: Okay. I just want to clarify that. Okay.
Mark: As far as database connectors go, there is also our ODBC connector. So ODBC is this database connectivity API that’s existed for 30 years, right? It’s maintained by Microsoft. It’s bigger than just IBM i, right? It’s a kind of database agnostic API that database vendors can implement drivers for. Anyway, all of that’s to say it’s very universal; lots of people use it. We have an ODBC driver for IBM i and we maintain this ODBC package on NPM. What all that means is you can download that on your Linux machine, you can download it on your Windows machines, your macOS machine, or your IBM i machine. You can run your same application in all those places. It will run the same in every spot, so if you have a non-IBM i server that you want to communicate with IBM i, you can do that with this package. If you want to develop on your local workstation—that’s how I usually develop. I run the Node process on my Linux workstation, works great and then if you want to go and in production, plop it on your IBM i system, you just drag and drop the application and everything works.
Charlie: All right. So for those who are listening so far up until this point and they’re sold on the concept of using this in some capacity in their shops, where do they go next? How do they get Node loaded on IBM i?
Mark: Well I’m going to just butt in one second because I did mention there were four packages, but I only mentioned three of them. The other one is called iTool Kit, and it wraps around what’s called XMLSERVICE, which is part of the HTTP license program that IBM delivers. It’s basically just a way to communicate with your IBM i system through these big XML payloads. The iTool Kit basically generates those payloads for you and then parses those payloads for you on the Node.js side. So it’s just kind of a wraparound, that XMLSERVICE.
Charlie: Okay—then let me interrupt myself, then. So is there a preference? Is there a reason to use a non-platform-specific driver like this, or is there a real benefit to using one that’s developed for i itself?
Mark: I mean—oh man. This is such an in the weeds question—
Charlie: Or is this a religious question maybe?
Mark: It might be a bit of a religious question.
Charlie: Okay.
Mark: The nice thing about the idb-connector and IDBP-connector is they’ll just work. You don’t need to install any other software. For the ODBC connector, you need to make sure you have an ODBC driver manager and the ODBC driver, but other than that, they work great. There’s like 70 different connection string options, so you can really tailor your database connections to how you want it and then XMLSERVICE. XMLSERVICE is kind of showing it’s age a little bit; it’s a little rusty around the edges. There is a replacement hopefully coming sometime for it and when that gets there, hopefully the toolkit that we deliver will also be updated to wrap around that.
Charlie: Yeah, that may not have been an entirely fair question to ask because I know even in different technologies—I mean here we’re talking about individual drivers—but even technologies themselves, people will gravitate towards one or the other. That’s their whole world and any problem they have gets solved with that one tool that they use.
Mark: Yeah, and I should mention that ODBC package; I am the chief maintainer of it. It’s my brainchild, my brain baby, so of course I’m going to say that that’s the one that I think more people should use.
Charlie: Well fine, then that’s a fair response too. Thank you for that. So let’s back up a little bit to my follow-up question with you before. And that’s so if I’m committed to this, if I’m committed to the notion of getting started on this, I want to load it now on my IBM i system, where do I go? What’s the process?
Mark: Sure. If you’re completely new to Node.js, what I would recommend is not installing it on IBM i right away. Install it on your Windows system or your Mac system or your Linux system, whatever you use to develop, and any sort of skills that you gain playing with it on that environment will transfer to IBM i, right? Most of the things that you need to learn is just kind of wrapping your head around the NPM ecosystem and how to import packages into your application, and then just how to develop JavaScript code. If you do those things and must make tiny little sample applications, those skills will transfer to IBM i.
Charlie: And they’ll transfer identically?
Mark: They should. Yeah, they will. Node.js on IBM i is the same as Node.js on Windows, Node.js on Mac. It’s kind of like the Java virtual machine, right? It kind of runs all of its code above the processor, and then it translates it down into what the processor can understand.
Charlie: Terrific. So there’s no dialect, per se.
Mark: There’s no dialect.
Charlie: Okay, got it.
Mark: But going to your next question there, right? How do you get it on IBM i? So we have a package manager, our open-source package manager called YUM. The easiest way to get it on your system is to install Access Client Solutions, ACS, and if it’s a more recent version, it will be on the left-hand pane under System Management, I think. It will say Open Source Package Manager or something. You click on that and it will pop up and it will say hey, I notice that you don’t have the open-source environment installed on your system. Do you want to install it? You say yeah, that sounds great to me, and within two minutes, you’ll have the open-source environment on your system configured to talk to the IBM server where we deliver the open-source packages, including Node.js. Then you click that button again, the Open Source Package Manager button, it pops up a little GUI for you. You select Node.js and download it onto your system. I should mention that you do need to be *ALL object authority in order to run this script and to download the software onto your system.
Charlie: Well, that’s fair.
Mark: Yeah. It’s not something that any Joe Schmo developer can do, right?
Charlie: That’s a fair expectation, I think. And what about updates and patches? Is it a similar process with ACS?
Mark: Yup, exactly. So in ACS there are three tabs. I think it’s Available, Installed, and Updates, or something like that. I should just go right now and look, but basically you go to the tab for the software that you have installed, the software that updates are available for, and it shows you everything has a pending update. You just tell it exactly what you want to update and it will download the software for you. We try to be very, very agile and responsive to the updates that occur in the wider community, so what will happen is usually there will be some update to Node.js, whether that’s because it’s adding functionality or as a response to some vulnerability. They’ll push it. They’ll push the code and then we try to as quickly as possible, pull that code down, build it for IBM i and get you an update for your system so that you’re not exposed for longer than you have to be.
Charlie: So I have one more question about the updates and that is on the cadence. I mean there’s no predictable cadence as there might be with, let’s say technology refreshes. This is its own independent—it’s in its own ecosystem.
Mark: So the Node.js, we’re talking about things like patch updates that add maybe minor functionality or do CDEs. Those just come out kind of as needed, but Node.js is a very, very consistently delivered technology that’s backed by very big enterprises. So they have a very consistent release schedule where every—I want to say 18 months—they deliver a new major version of Node.js that becomes the long-term support version. So it’s very similar to how IBM delivers major releases. [IBM i] 7.3 is going to be in support for so long. 7.4 will be in support for so long. We’ll get you a new version every three years, things like that. The same promises that IBM makes, the Node.js community makes as well. I should mention that Node.js is not backed by any one organization. It’s backed by what’s called the Open Linux Foundation—I think owns it now—no, no, sorry: the open JavaScript [OpenJS] Foundation. They keep changing governance, but this foundation is supported by like Microsoft, Google, IBM. They all pay over a million dollars a year to be on the foundation board to ensure that this technology remains enterprise viable, that it remains performant, that it remains secure. So it’s not just some small group of developers in their basement; it’s backed by some of the biggest technology companies in the world.
Charlie: Again, and that not only instills confidence, but it maintains confidence—you know that I can commit to running an enterprise strength application using this technology for sure.
Mark: Absolutely and I’ve seen claims—and I don’t know the veracity of these claims—but I’ve seen claims like every Fortune 500 company uses Node.js somewhere in their technology stack. I have no way of confirming or denying that, but it wouldn’t surprise if at least 80% of them did.
Charlie: Well we’ve been talking about Node, Mark, and one thing we haven’t discussed at all how are people using it? So now we know that we can run it on IBM i and it’s a viable technology, but what have you seen in the field? How are people actually deploying this and what applications are they using it for?
Mark: Yeah so the world is really moving and has been moving for the last few years into this sort of microservice kind of space. So having these small applications that do kind of one small piece of what you need to do, and maybe each microservice has one or two API endpoints, and so they do a small bit of work: talk to the database, get some data back and send it back, right? I’ve seen a lot of people use Node.js processes as just those microservices. You write a small application, you expose, maybe like I said, one or two API endpoints. Those APIs do a little bit of—they get data in through the network. They do some, maybe, data manipulation. They talk to the database, the data layer down in your IBM i system. Maybe they call a procedure that calls an RPG program. That RPG program runs some business process that you’ve had in your business for 30 years. It returns some sort of result, spits it back out to whoever called the API, and that API doesn’t need to be a public API, right? It doesn’t need to be something that’s exposed to the whole internet, the whole world. It can be a private API that’s inside your business. I think that’s how Amazon is designed, where every single thing that people develop and deliver has to be consumable as an API somehow.
Charlie: So what you’re describing to me is a very powerful tool, or a language I would even say, but it’s not intended as far as I can tell to supplant RPG and SQL, things like that. I mean they play well together and you’ve seen applications where they do peacefully coexist, right?
Mark: They absolutely peacefully coexist. So Node.js is definitely a technology that kind of sits above that normal RPG kind of space right? RPG is really great for doing data manipulations and implementing your business processes. You have all your data in the database, taking that data out, doing some business process, delivering data back, that sort of thing. Node.js is really good at taking the results of those and doing a lot of kind of 21st century things with them: sending them to other APIs, making them consumable by websites really easily. There are NPM packages for doing things like sending SMS text messages that in three lines of code, you can call an RPG program and return the result and send it to somebody’s phone if there’s an alert or something like that. But I think that Node.js is really the perfect kind of partner for RPG and SQL. It’s really a technology that can very easily take RPG code—code that people have written for the last 30 years, code that businesses have invested millions of dollars into maintaining and that is the backbone of their entire infrastructure—and allow them to do kind of more agile things with it in the Web 2.0 sphere.
Charlie: With partner being the operative word here.
Mark: Yeah. They should definitely not try to fight with one another. You could write entire applications in Node.js where it takes data and it does all the processing inside the node runtime itself, but Node.js/JavaScript is not strongly typed, so it’s very kind of slow at figuring out okay, what kind of data is this? What kind of manipulations do I need to do? RPG in comparison can run circles around it, so there’s really no need to rewrite your code in something if you already have all of these working workflows that have been around for so long.
Charlie: Right, which only once again reinforces the adage, use the best tool for the best requirement, whatever it happens to be.
Mark: Absolutely.
Charlie: Yeah. All right so if I’m really convinced and I want to get started with this, I need to look at framework to get started with this. Is that true?
Mark: Sure. That’s a great place to start. A lot of the examples out there will have—you use some sort of framework to do something like create a simple web server. Yup.
Charlie: And so the ones that I’ve been reading about—to be fair I’m not today a Node guru by any sort, by anybody’s measure. So I am exploring it more and more and reading more about it, but the things that I have encountered so far are sales and partial, and I think the one that I see most often is Express.
Mark: Yup.
Charlie: So is that the 800-pound gorilla?
Mark: Express—if you look up a Hello, World! example in Node.js, I can almost guarantee you that it will be written in Express. Express has kind of been around for the longest amount of time. It was written probably ten years ago. A lot of people that have a lot of strong opinions about Express, but it’s still a very viable framework. So you go and look up "how do I write a Node.js application to serve up a Hello, World! web page?" It will probably be written in Express—and maybe you play around with Express for a few weeks—and then you say okay, I want to do something a little more, something that’s been developed since then that maybe is less opinionated, and you go and find another framework to work with.
Charlie: Okay. So, if we make the decision or if a shop makes a decision that they want to go this direction and they have no prior experience at all, what might they expect as a learning curve before they can start becoming truly productive?
Mark: Yeah, that’s a great question. I would say that the learning curve for Node.js is definitely less than other languages like PHP or Java that you might use on the back end. JavaScript is a very easy language to understand, a very easy language to pick up and learn. The hardest part is just understanding how JavaScript kind of plays in a wider kind of Node.js runtime. There’s a few gotchas that you have to aware of, but I would say within a month you could be doing something really impressive with Node.js. We have resources out there for people if they want to go and learn. We have a repository called ibmi-oss-examples. It’s on Git Hub. We have lots and lots of Node.js examples on there that they can go and download and run themselves and pick through the code. We have a number of tutorials on there that they can read through. So there’s resources out there not just for IBM i users, but if you go out there and just Google or whatever your favorite search engine is, look for Node.js tutorials. Like I said anything that you read there will be equally applicable to IBM i development, so don’t be too concerned about finding IBM i-specific examples right off the bat.
Charlie: You say one month, and that to me is not a long time at all—
Mark: For a developer, no.
Charlie: Right, for a developer. But you also said earlier that you need to get your head wrapped around that. For a traditional RPG/COBOL developer, is the paradigm shift that great that they need some time to wrap their head around this, or is there a natural progression towards this?
Mark: I think it is a little bit of a difference from what they’re used to. So there’s this concept of asynchronous code in Node.js, which is a very big concept. Basically it means something is going to run and it’s going to run in the background, and you need to tell Node.js what to do in the meantime. And there are ways that you can write your code where you think you’re telling it, I want you to run this bit of code, and when it returns make a database call—let’s say when it returns I want you to handle the result. But what you’re really telling it is I want you to run this database call, okay now while that’s running, I want you to handle the result. But it hasn’t returned yet, so you can end up shooting yourself in the foot that way. You can also shoot yourself in the foot by telling it I want you to run this database call and in the meantime, I don’t want you to do anything. I just want you to sit there and wait. And your whole application is going to seem like it’s frozen, right? So there’s a few gotchas where you have to wrap your mind around things. In reality once you know what to look for, it’s second nature. But it will take a little while to kind of work themselves into that paradigm.
Charlie: Well to me some of the big takeaways that I’ve gotten from this discussion, Mark, is first of all, Node is certainly here to stay. Its popularity is unsurprising to me, and it’s certainly secure. Anything that you’re going to use in your shop you can use with confidence, which is a very big thing. But the other thing I want to just throw out there, which you’ve illustrated in this discussion, is that you’re not alone. There are many resources available to somebody who is just starting out, and you said within a month or so, and I think that’s all part of the community supporting itself.
Mark: Yeah, absolutely. So two great points. Node.js is definitely not going anywhere. There are people, even including the original developer of Node.js, who say Node.js—there’s all these things I hate about it. I want to create something different, and they’ve created replacements, drop-in replacements for Node.js. But Node.js is the 800-pound gorilla, to use a term that you used before on our podcast here. It has so much momentum, it has so many developers that it’s not going anywhere. It’s not a technology that’s going to be abandoned in the next ten years, I can guarantee that. There are tons and tons of resources out there for you, right? There are so many new people interested in learning Node.js, there are so many people that understand Node.js and that want to teach you. So really there’s no excuse not to learn it other than you don’t want to learn it.
Charlie: Got it. Well Mark, this has been quite the education for me certainly, and I think for anybody who’s listening to this podcast. It’s really chocked full of a lot of good information and I want to just thank you so much for taking the time with me today and hopefully shining a light into some of the dark shadows that seem to be surrounding this technology for not only the traditional RPG programmer—and Node is this mysterious thing. I guess you need not be afraid is the final word on this, right?
Mark: Absolutely. And honestly, like I said, just download it onto your workstation, your Windows workstation, play with it, create a little service, serve up a Hello, World! and see how easy it is to go from absolutely nothing to something really cool in three minutes' time with development.
Charlie: Wow. Well thank you. I guess we’ll leave it there, but I don’t want to end this discussion without once again congratulating you on your new position at IBM as advisory software developer. That just speaks to IBM’s commitment to you and Node and your career and all these things. So it’s goodness all around. How does that sound?
Mark: Perfect. Well Charlie, you can buy me a drink in St. Louis and then we’ll call it even.
Charlie: I will take you up. I will take myself up on that and make sure that we get that done for sure.
Mark: Perfect.
Charlie: Mark, it’s always a pleasure. Thank you so much and we’ll see you down the road. Thanks again.
Mark: Perfect.