You can listen to the Podcast and read the show notes here
Michael: Welcome back to the show. I'm here with Ray Camden and he is the developer advocate for IBM and he does an amazing amount of stuff. He works on Loopback, API Connect, Servilus, hybrid mobile development, HTML 5, web standards, and Node JS which is what we're hear to talk about today. Fortunately, Ray has his army of storm troopers with him in the room, just in case there are any difficult questions that have to be handled. I take it you're a great fan of Star Wars, I think I've known that for a long time.
Ray Camden: Just a little bit.
Michael: Just a little. In today's episode, Node JS for Cfers, we're gonna look at what Node JS really is, why you should be programming in it, and what the hardest thing for a Cfer learning node is. We'll also look at deployment tips, how you can test your node applications, and also Ray is going to be talking on the subject of CF objectives, so we will be looking at that as well. Welcome, Ray.
Ray Camden: Thank you. Thank you so much.
Michael: For those few people who've been isolated in the universe and don't know what Node JS is, what exactly is it?
Ray Camden: The super simple way of thinking about it is being able to write java script on the server. So take in the java script that you would normally only use on the browser to do front end enter activity but actually to be able to use it to write your back end codes. For many, many years I did cold fusion on the server outputting HTML but also making it work with java scripts on the front end. Again it's extremely simplistic when you think about it but that's one way of thinking about it. It's also a pretty different way to build in your back end applications as well. One of the issues I had was thinking about it just as java script on the server and I immediately ran into … I would do this so and so way in cold fusion to do a contact form, for example, and it wasn't that direct in Node JS. It wasn't that it was harder, it's just that I had to think about it in a different way from my typical cold fusion development.
That's really what I'm focusing on at my presentation at CF objective, is those mental, not hurdles per se, but different ways of thinking about building your apps in terms of working with Node JS vs cold fusion. One of the things I want to do is a soup to nuts, in terms of, when I was doing this in cold fusion, this is how I would start just to test something. When I was building an app, this is what I would do. When I was working with sessions when I was working with forms, you know, all these very typical things in cold fusion, they're all pretty easy, in Node JS they're just different. Knowing how to approach that and again very much based on this is how I did things in CF, this is how I do it in Node, that's going to be the core of my talk. I only have an hour I definitely can't get super deep, but again that's why I'm focusing on all those things that kind of tripped me up that I wished people had told me when I was learning Node. That was a very long answer. Sorry.
Michael: No. Long answers are good on this show. Technical detail is what gets people excited. Node JS is basically a java script framework and I guess, is that true?
Ray Camden: I think all frameworks [inaudible 00:03:53] loaded term. [crosstalk 00:03:56] which again is not the best way of saying it, but I wouldn't say framework, it's not like [inaudible 00:04:02] of framework one. It's essentially a java script engine that's running on your server and allows it to run java script code on the server. It's highly optimized, it's really fast, it can do a lot more than java script in the client, so you have file, read write access, low level binary type stuff that honestly I never touch. But, yes, not a framework.
Michael: Okay. An engine, not a framework, and it's running on the server, unlike most java script which runs on the client?
Ray Camden: Yeah.
Michael: Here's the 64 thousand dollar question, why would someone want to program in Node?
Ray Camden: I do a lot of front end development anyway, so being able to use the same language in both sides, I guess. In a totally different context per se, I'm not having to think about having to write an if condition or how to do so and so. I know the syntax, I may be doing things differently, but I know the syntax of java script. So to me, that's the big advantage. One of the other things that I really like about Node is that typically what you're creating has a much smaller footprint than cold fusion. I know Lucy is a lot more lightweight, that's my impression, than adobe cold fusion, but node can be even smaller. Very, very small footprint. I like that I could write something and get something up and running and being able to put it on a server with very minimal resources.
Michael: So you could deploy it on a digital ocean droplet and it would run just fine?
Ray Camden: You could deploy [inaudible 00:05:59] a thousand places to put it up. IBM, we have blue makes, that's our commercial offering. Certainly there's a bunch more out there. I was just looking at Now by Zeit and I'm probably saying their name wrong, but they also have a simple command line to put Node JS apps up. There's a lot of options out there. I would say probably a lot more than cold fusion. So where you can deploy stuff is greater. Also, I think, another reason to learn Node is I think the market is going to be significantly bigger with that. To be clear, I'm not positioning my talk as you should stop using cf and cf is bad and all that. My assumption is that you want to learn Node just to expand your own skills. It's not about bashing CF at all. I do think, in terms of where you can put your code and certainly the amount of people that you can interact with, there's going to be a larger audience as well.
Michael: Okay. So if you're a Cfer and you want to learn node, what's the hardest thing?
Ray Camden: I kind of want to say, “Attend my session,” but, I'll speak in general. I've had CF installed and tied to apache for probably near 20 years. In that model you could just drop the CF into the web server and it's Cold Fusion 13 added the foo function. I could a CF in there that said CF output foo close CF output, and it would just run that in my browser and I could see, “Oh, that's how this function works.”
In terms of doing that with Node, it is still pretty easy but I went into the context of thinking I need to build a web server every time, and I don't like building web servers, so I'm never good with cold fusion. So that was totally my mistake, you know, I did this in cf, I gotta do it in node as well. One of the things I'll talk about is the difference between writing a node script to test one particular function which I think is a valid use case while you're learning. Versus building an application or building and API. There's a difference in how you approach that and I really wish I had known that on day one.
Michael: You can put this on any OS? Windows, Mac, Linux?
Ray Camden: Yeah, so I'm on Windows now but I'm using the ubuntu bash shell on Windows, so that's about as hybrid as you can get probably.
Michael: I'm assuming you can even run it in a container like docker if you really wanted to?
Ray Camden: Yeah, I don't use docker, I know all the cool kids do, but I don't. Also, because I don't do a lot of production work, I do a lot of demos and stuff like that so my use case is more a lot of small quick demos to illustrate something or to do something for a blog or a presentation vs a project that I'm going to work on for six months and then deploy and work with others. In that regard, I'm a bit different. I will try to touch on that in my presentation to make people aware of that.
Michael: I'm assuming there's no cost to using Node JS? It's open sourced, right?
Ray Camden: Free and open sourced.
Michael: Alright. Cool. If you've got your node app and you've figured out and attended your talk, and translated stuff from cold fusion paradigms to node paradigms, now you want to deploy it. Is that easy?
Ray Camden: Yeah. Again, this is something where in the cold fusion mindset, at least for me, it was in the older days, call up the host and say I want foo.com and they would send you an email with here's a login. Now hit rdpn, go on the windows box, install CF, install apache, do all that and that was relatively easy. With AWS that could be a little bit easier. I know you can do images with AWS as well. I would say it's even easier with Node. I work for a company that has an environment for that and there's other environments as well that for a lot of use cases from my command line I can just say push this up, and then a minute later, depending how big the site is, the whole thing is updated.
Michael: Wow. That sounds really efficient. And sounds pretty similar to what command box does with cold fusion apps these days.
Ray Camden: So I am definitely a bit behind in terms of deploying CF apps, because I haven't deployed a CF app in a while. I have used the command box and box server and that is freaking awesome. It almost makes me with I was doing CF more. I still do cold fusion for clients, typically small things like, “Hey make this API work for me,” and the first time I went to a folder, put a CF in, did box server start, and it grabbed all the bits and just ran, I freaking fell in love.
Michael: It is pretty amazing. I must admit I grew up with a command line instead of all this point and click stuff so there's some things that are easier to do in a command line.
Ray Camden: Yup.
Michael: You've got your node app, how would you go about testing it? Is it the same kind of tools used for a cold fusion app?
Ray Camden: It's the same kind of concept. I know cold fusion has testing frameworks where you write test and there's multiple versions of that for java script that work both client side and server side code so same concept, you write unit tests, you focus your test on one particular function or one part of your application, you can make that part of your build process, you can put into your tool chain completely a run [inaudible 00:12:35] however particular you want to be with testing, you can definitely do that with Node JS.
Michael: Okay cool. Is it easy to track down bugs in it? I know whenever I've worked with java script it was a pain in the rear end.
Ray Camden: I would say yes and no. You definitely get stat traces when you have an error. The stat trace, I would say is a bit friendlier than a java stat trace. I don't think it's hard to recognize an error when you see it. One thing I definitely miss is the cold fusion debugging output. There's definitely Node JS versions of performance tuning and stuff like that. I find it typically to be really, really hard. Really, really obtuse. Whereas I think CF's debug stuff was incredibly simple and very direct, for a given request. You know, 40% was spent on a db call and it was this query and it was super slow or you may have two queries on a page and you can immediately see that one turning real slow. So, all that type of stuff you can definitely do in Node JS and ibm has some open source projects involved in that, but definitely have to do a bit of work to get them in there as opposed to CF where it's just like, bam.
I never did the hardcore server tuning like Charlie Earhart and Mike Brunt did, most of my server tuning was turning on the debugging and just pouring over that. I would say one thing that cold fusion really wins at is just how useful that was. At least for me, I would say that 80% of the time, that was enough for me to find the problem. The other 20% I said okay I give up, go talk to Charlie.
Michael: I don't know if you know this but Gert Franz is giving a talk on custom CF debuggers at CF Objective, so [crosstalk 00:14:44].
Ray Camden: I saw that. I actually built a couple of those custom debuggers years and years ago.
Ray Camden: Adobe would pick some of those up. I don't know if they ever did. But yeah like eight years ago I remember looking at the template and it was unencrypted and I was surprised because most of the cf admin stuff is encrypted. I know I built a couple, I saw some other people built stuff as well. Even simple stuff like greater highlighting of issues, make them stand out a bit more. That was all hackable for years and years. I'm happy to see it getting some attention.
Michael: Yeah. You can write your own debugging template and do all kinds of custom things, so pretty amazing stuff. Any other advice on, is there like a mindset shift you have to go through to do Node JS? The syntax of java script sounds pretty straight forward.
Ray Camden: So, yeah, yeah. Again, it goes back to how do I test one thing in node vs how do I build an application in node. Again, I'll be talking about that. They're just frameworks that make building apps super easy. Express is probably the most well known one. That's what got me into node because before express it looked like too much work. There's stuff like that that makes it easier. Again, I'll be talking about that in the presentation.
Michael: Is node something you can have thousands of users hitting the server on? Or is it only a few who can hit it?
Ray Camden: It's definitely highly performing. That's one of its selling points. I honestly haven't pushed it hard myself. I can't say I have an app that has so many million users or whatever, but because it's so slimmed down, it's not loading up, for example, a CF PDF engine. Although to be fair, I know cold fusion laser loads that stuff nowadays, which is good. But in the old days it was loading everything CF chart, all that, but node pretty much loads only the one or two pins it needs to do. So my application is extremely slimmed down.
Michael: So that sounds similar in concept to all the stuff that we were talking about in to the box where they had that micro services architecture where you only load the bits that you're using, so it's kind of cool that you're doing that in Node JS as well.
Ray Camden: What's nice about it, so, if you have, if what you're offering is made up of five parts and you've broken that into five macro services, five separate servers, if one of those is super critical and just needs more juice and a lot of hosting providers for Node JS, you literally just go in there and bump the CPU up, bump the RAM up, give that one thing what it needs and the other four can just stay small if they need to.
Michael: Wow. So that gives you better performance without having to pay an arm and a leg for much more service?
Ray Camden: Yeah. So typically I would have one CF monolithic server doing everything and if I could have broken that up into smaller parts and made the slower parts more powerful, I could have saved money. Again, I haven't deployed CF in a couple of years so that may be something that people are doing now.
Michael: Coming back to CF, you did that for a long time, why were you proud to use it when that was your main thing?
Ray Camden: It's very practical. Very direct in terms of what you want to built. It just plain worked. I can remember when I was learning groovy, and I got the book on groovy, and they were talking about some of the impetus for why they were built. I gave the example of reading a file in java and it's all this file object, file reader object, file reader buffer, etc, etc, etc. at ibm, we realize that people like to read files so we made a shortcut for all that, and I'm like, well yeah, that's what CF has been doing for a long time as well, making a shortcut. I really appreciated how practical it was and people outside the CF community loved to call out all the bad code that was created and that was never the fault of CF. It was the fault of the person. They were getting stuff done and being productive and being successful.
If they used tags instead of script, who cares? I'll probably get thrashed for saying that but CF allowed people to get things done. I had a great dinner years ago with a guy who was not a developer at all, he was a doctor, and he just raved about how happy he was with cold fusion because it allowed him to be successful. His code was not great, it wasn't MBC, it wasn't best standards and all that, but the platform allowed him to be successful and I think that is something that CF should be proud of. Excuse me.
Michael: I would agree with that. Much more productivity, whatever language you use, I think that's important these days. So what would it take to make coldfusion even more alive this year? Some people have been saying it's been dying for 10 years or more it seems to still be going.
Ray Camden: I wouldn't even know. Adobe is being successful enough to keep working on the product, so we could comment about their marketing or lack there of, or their decisions to make CF client and all that, but for them at least, they're making enough money to keep working on it. I think for a person who makes a product that's typically what you want. I don't know what the numbers are in terms of developers working on CF, I'm sure adobe would say it's good. I'd be surprised if they said it was growing. I think it's always going to be a niche product. It's its own language. It's a language that has warts, like any other language out there, but I honestly couldn't tell you what it would take to grow significantly. I don't think it ever will. I don't say that to bad mouth CF, I just don't see that as happening. I think java script is definitely getting most of the attention. Languages like go are getting a lot more attention as well. CF, I don't think, can just magically catch the attention again.
They would almost have to rebrand and pick a new name, and I think that was actually talked about at one time.
Michael: Well I guess Lucy is a new name in some sense, right?
Ray Camden: If we talk about Lucy, then I think you may have a chance but until I see people talking about it like a medium or at major conferences outside of CF Objective, more generic web based conferences, I think it just may be one of those small languages that just sits on the sidelines and carries on okay and that might be all it does. That may be okay.
Michael: So you're speaking at CF Objective not only on Node JS but also on Serverlus. We talked about that in a podcast episode a few episodes back. What are you looking forward to at CF Objective this year?
Ray Camden: Mainly being at a conference where I know most of the people. That's quite nice. A lot of conferences I go to no one knows me, so it's nice-
Ray Camden: Yeah, I mean it's the large general web community and Node JS community is just very large. So I typically know people there but no one knows me. So it's nice to go to a place where I know people and they know me. It's very friendly. I'm also happy to see that it's in Washington. I haven't been there in a decade or more, probably, so I'm looking forward to seeing it.
Michael: Wow. Yeah, I understand there have been some changes in Washington.
Ray Camden: Yeah. I won't talk about that.
Michael: We'll keep that silent. Well great. Well wonderful talking with you Ray. If people wanted to reach you, how could they find you on the internet.
Ray Camden: Sure, my blog is RaymondCamden.com and my twitter nick is raymondcamden.
Michael: Excellent. It also looks like we can find you on gethub @ cfjedimaster?
Ray Camden: Yes.
Michael: Did you manage to keep jedimaster in your handle for your current position? It seems that was a critical negotiating point at one point.
Ray Camden: No. For IBM, I just assumed the process to get an email alias would be too much trouble. So no. I have a very boring IBM email address.
Michael: All right. Well great talking to you, have fun in Louisiana, hope you have a great time in our nation's capital, lots of things to see there.
Ray Camden: Yes.
Michael: All right, thank you.
Ray Camden: No problem.