 Hi everyone. Hello. Hi guys and girls. Welcome to the Node.js Hack Night. I am Vishal Parpia. I am supposed to be your mentor but frankly I have been using Node for a while now. We have used it in production in a couple of places. I run a company called ActiveElevent and we run also a small cloud consultancy called Cloud Cover. We write applications for a few companies over here in Pune as well as a few companies in America. We are a very small group of folks so we like to work on cutting edge technology. Node.js turned into one of my favourite programming languages almost instantly. I want to have a quick show of hands over here. How many of you have done Node.js before? Have you used it before? Alright cool. Can you guys hear me? Yes? At the back? All good? I can project my voice. So I am going to jump straight in. Since a lot of you guys have never used Node before I am going to give you, alright so firstly this, whatever I am going to talk about today everything is just like blatantly stolen from a talk that was done a while ago by the guy who made Node.js like it was in 2011. He presented to the PHP users group in San Francisco back then and yeah it went out pretty well and he touches upon some very key aspects of Node and why it is cool and what is different about it which is why I thought it was perfect for this. What I am hoping to do is to give you guys an idea of why I use Node personally and then go through just basically a little demo of what you can do with Node and what makes it different from other languages that you might have used and hopefully then we will start hacking. Alright so Node is basically a bunch of libraries that are written on top of Google's V8 JavaScript engine so that is the stuff that is running under the hood in Chrome. It is because it is running in Chrome and because Google has very smart people working on it it is crazy fast as far as a JavaScript engine is concerned. In fact it is so fast that it rivals your PHP Ruby and the Python guys, the Ruby guys, the PHP guys all jump down your throat and say that is not true but benchmarks and stuff will prove that fact, have proved that fact all over the web. You can go check it out. The reason for that is because of the competition in the browser space so because browsers are so cutthroat and everyone is vying for market share and it is such a huge aspect of computing today in general big companies throw a lot of resources at the problem and that means that JavaScript compilation, pre-compilation, all the stuff that happens now happens really really fast and turns into something that works a lot better and a lot faster because the projects themselves are well funded. There are people that do this for a living working on it all the time and that obviously improves the product. That's the V8 engine. Alright so I'm just quickly going to step through a few reasons why you should use Node. Firstly, presumably everybody over here works with web technology at some level. You already know JavaScript because there is no way that you are writing a web page that doesn't use JavaScript today. Someone is using jQuery for something. It is really very fast. I said that before but it bears repeating. It's what is called event driven or non-blocking or asynchronous. The thing is that a lot of new languages and a lot of even older languages like .NET says that you can do async with .NET and technically speaking it is true but the reality is that if you just picked up .NET and took like a hello world example it's not asynchronous out the box. You have to do stuff. You have to change the way that it operates in order for that to happen. Node.js is asynchronous out of the box. You turn it on that's all you get. In fact you have to try really hard and you have to be a really bad programmer to make it synchronous. You don't have to do anything and out the box it just works. It does the job that it's supposed to do. So what's good about that? It makes a lot of sense for things like when you're doing networking for instance, go fetch a URL. Go to Google.com and get it back. If you do that in something like PHP you have to wait for that call request to complete for you to get the contents of Google.com and then you can start messing with it. That doesn't happen with Node.js. The thread keeps executing other things and that works really great for things like database queries as well because after you fire the query what are you doing? You're just waiting over there for the database to return some values. It does not happen in Node. So that's not going to block your execution. It's not going to make your web server slow. It's not going to do all the things that we hate about all the stuff that we do on a daily basis. All the performance bottlenecks that you tend to see in web applications come from stuff that you're waiting for. If you're for instance, building something on top of somebody else's API like let's say a travel site and you're waiting for the response from somebody else's server if you do that in PHP after you hit a certain number of threads your server is going to fall over. You're going to need a scale. You're going to need to have another server. That does not happen with Node. It just keeps going. I'll show you how that works. JavaScript also is actually a pretty cool language. A lot of people say no, JavaScript is a crap language. It doesn't have a lot of the things that people that come from a more strongly typed world will say. But it does have some pretty cool things like closures, anonymous functions and prototypes. Which if you've been using JavaScript, you're already using these things. You might not know what they're called but you're definitely using them. Some of the syntax and examples that you get off of jquery.com use anonymous functions. And prototypes are used extensively throughout your major libraries that I use on the internet. So all these things work really well at the server side as well as the client side. So you're already used to using it on the client. It works great on the server as well. Alright, so in order to install Node, I'm just going to tell you to read the manual. Read the FL manual at Node.js.org. It's actually really, really simple to do. There's all kinds of labels over here. You can download it for Windows, download it for Mac. There are binaries. You can compile it if you feel like it. It's going to be a prerequisite for tonight. So it will be great if you guys can go to Node.js.org and start downloading it. It's not a very big executable but if you're going to compile it on your computer, then it's going to take a little bit of time. If you're on a Mac, I recommend using homebrew. You probably already have brew. Then you can just do a brew install node and it'll work. Alright, so I'm going to jump straight into demos over here and start writing some code. You can use any old text editor. Basically, once you've installed Node, you can just run Node from the command line and you get that and that's the JavaScript prompt. So that's just like your console inside Chrome or Firefox or whatever. So you can write code over here and it'll execute. Is this better for you guys? Yeah, awesome. I don't know how I'm going to be able to type and use this but I'll try my best. So this is a full JavaScript console. You can use it to do all the usual stuff. You can create variables, you can create arrays, whatever. And that's pretty cool and it's useful. I often take raw JSON data and just paste it in here and create objects out of it so I can manipulate it. It's not really something you're supposed to use in production or whatever but it helps me for the minor tasks and if I want to verify like syntax, JavaScript syntax, which I'm about to use in the program, I'll drop to this and start messing with it. So Node accepts the argument can be the file that you want it to run which is basically how you would normally use it. So what I'm going to do is I'm going to write a small program just to demonstrate the asynchronous nature of Node and then run it using the command line. Does everyone know what setTimeout does? Hands up if you know. Yeah, okay, cool. So I'm going to write a quick little setTimeout function over here. Super easy, right? What this is going to try and do is write hello world. The only difference over here is obviously we've put word inside a setTimeout function which means that it'll happen after one second, right? So you run that over here and that will work great, right? Super easy. The major thing that you've got to realize over here is that other programming languages will let you do things like sleep. There is no sleep in JavaScript. In Node.js for sure, there's absolutely no sleep which means that you can't suspend the thread. You can't say don't do anything, don't execute anything for another one second and then come back and do something, right? What's happening over here is Node is still processing stuff. It's just that it's idling. So Node will idle but it will never ever sleep. So if you were to do this in PHP and you wrote like, you know, you want to write echo, you write echo hello and then you write sleep and then you write echo world, that's not the same thing. We are writing, it's basically when I execute this, it's blazing straight past setTimeout and it's writing hello to the console and then after a second that callback executes and it's firing console.log world, right? The critical aspect over here is the fact that Node does not wait at all. You have to understand that and that's going to make things hard for you later because you can't just keep writing functions over here and expect the previous function to have completed by the time the next one executes, right? So when they say asynchronous, they weren't joking. It's actually completely asynchronous, right? What I'm going to do now is I'm just going to change Timeout to interval. Do you guys know what interval does? Yeah? So intervals basically going to execute the world statement over and over again without stopping, right? And so you notice that it didn't exit. It's just staying inside Node, right? Previously when we ran hello world, it spat me back to the command prompt. Node's still executing over here and it's going to keep executing as long as there's an event that can happen. So this is another critical aspect of Node. Node will only stay alive. The script will keep running only if it knows there is another event. There is another callback that can be executed, right? Otherwise it's just going to quit. The application is going to leave. Why is this important? Usually a script reaches the end and that's the end of it. But you want to think about this from the perspective of this is basically was created for browsers and stuff, right? So there's an event loop running over there trying to track your keyboard actions and your mouse movements and stuff like that. We take advantage of that because what happens over here is the second that your program is done, it automatically and basically without you doing anything extra will exit gracefully and you don't have to worry about it staying open. Node's very good at counting how many callbacks are there and when it comes down to zero, it just quits, right? So that's the easy stuff. What I've done is I've also written a couple of programs over here that are super easy. So if you... Yes it is. It's not coming on. Thanks. Did the battery is dead? Can you read that? All good? So should I keep going? I think they need it. Those guys are going to have a hard time. Just go ahead. Sorry guys, I don't think that we're going to get a mic that works. Alright, so what's happening over here is firstly we're creating... So this little require statement at the very top. This is very important for you to understand. What's happening there is I am requiring an external library and I am importing that module into my current namespace, right? So what's happening is there is a separate module that's built into Node called HTTP and it allows you to create HTTP servers and also allows you to perform client actions like gets and posts and stuff like that. So the full HTTP implementation lives inside that HTTP library and you can add any number of libraries to your project simply by using that force line. So as long as you require it, you set it to a local variable then you can access that variable directly. Awesome. Alright, so... Immediately after that we're firing Create Server which is effectively creating an HTTP server within Node and I'm binding it to port 8888. So it's going to listen on port 8888. And what it does is hello world again. So not very complicated at all. Alright, and it's running. You'll notice that it has not exited because when I create the server it's basically listening on that port so it knows that there's events that can occur and therefore there are callbacks that can execute and therefore Node will stay active as long as that HTTP server doesn't crack. So I want to hit it so I'm going to just curl it to it and there you go. Hello world. So that's being served from Node. Not very exciting. What I want to show you here though is a couple of things. This is the header. Alright. What's important for you to see over here is two things, connection and transfer encoding. And both these things are possible now because you're running on HTTP 1.1. Not all web servers can do that which might seem crazy because 1.0 is a long time ago but 1.1 allows you to do these two other things. So the first thing is Keep Alive. What Keep Alive does is it tells whatever's receiving the content that connection is going to stay open which means that all that TCP IP overhead of creating the connection to the socket all that stuff is done once at the beginning and then it doesn't happen again. So every time that you make subsequent requests to this web server it doesn't have to set it up again which is what you want. Want it to be as fast as possible. As you're browsing around on different pages that browser doesn't need to keep closing the connection and opening it again. This is something that wasn't possible with 1.0. And the second thing is transfer encoding chunk. What that allows you to do is it doesn't require you to know the length of the content before you start sending. That might seem trivial but it's really important because for instance let's say that you were doing some kind of a database query on the server and you didn't know how much data you were going to get back from that query. You don't know how many bytes are coming back because everyone's using variable length. But when that data comes back you can just start sending it. You can just start streaming it straight back to the client and you don't have to worry about buffering it at the web server. Otherwise what happens is every single time that you fire a query or you read a file from the disk or anything of that sort you usually have to create a buffer. You have to have a variable in memory which is going to sit over there and collect the whole file and then push that whole file down the HTTP tunnel. That's not happening over here at all. What's happening is the second that that data comes into node it's pushing it straight down that socket and it's reaching your web browser. So there's nothing, there's no additional memory overhead at the server level. So you can imagine what that does when you're dealing with thousands and thousands of concurrent requests it becomes really, really fast. Both these things happen by default. You can change them, but by default this is the way that it works. That kind of makes the web server at least kind of special. The web server is actually built on top of the standard TCP IP stuff and what that means is that you can also write a plain old socket server like an old-fashioned telnet connect to me and start sending data kind of server. And that's what this thing is. So in this case we're acquiring a different module called Net and Net is kind of the underlying library that is being used by HTTP as well. And what you can do over here is you can create another server and you can say, okay, this is an Echo server and whatever comes in send that back over the socket. So this is really, really simple. It's basically just sending the same stuff that I've received whatever you type out, it's sending it back to the client. So just to demo this, I'm going to just quickly telnet to it. Whoops. So my old HTTP server is still running. I'm going to have to change it and write the TCP server. So it says Echo server and whatever I type over here, this keeps coming back to me. It would be cool if I could get other people to connect to this and start typing. Maybe we'll mess with it later. Yeah, I've got to change the code and stuff too. I don't know how much time we have. Are you okay? Maybe I'll do that offline. So you can telnet. Alright, so what we'd have to do is effectively create an array of everybody that connects to this socket and then I'd be able to broadcast it. But I don't feel like doing that right now, so I'm going to skip over that. So there's all kinds of good stuff and there's a couple of reasons why people think that Node is not such an awesome language and while this is the Node.js hack night and we're all stuck with it today, I just want to address one specific issue which everyone keeps bringing up about callbacks. So everyone says that, oh, Node gets into callback really quickly and what they mean when they say that is almost all your functions because of the asynchronous nature of the language require a callback. So for instance, in the case of even our easy-peasy demo, this function over here, that's a callback because it says when I'm done with waiting for a thousand milliseconds, call this function. Well, when you do stuff like database access, for instance, if I include MySQL library and then access a select statement, there would be a callback when that select statement got done and if I wanted to get a web page and then act upon it, there would be a callback there and so on and so forth. What tends to happen is you tend to start nesting your callbacks deeper and deeper and deeper. Well, that's true and there are many, many different ways to solve that. But I think that the callbacks are actually a great design pattern so it's not something that's a negative, it really requires you to exercise some kind of... You can do it with callback hell nested all the way in and keep tabbing and tabbing and tabbing your code but you can also create functions instead of having them be anonymous. So for instance, in this case, rather than just having the function name over here, I mean the asynchronous... the anonymous function over here, you could just have it be... and this will work just as well. So now suddenly you've moved your... what used to be a callback and what would have been deeper in the stack, you've moved it out and it gets called just the same and it works just the same and it allows your code to be quite elegant. You can even create modules with functions attached and have them be completely separate. So that particular problem of it being callback hell, I'm not so convinced about it. There's also things like promises that you can use if you guys have ever dealt with promises in jQuery. That was something that was introduced fairly recently. Those work in Node as well and it's a very cool design pattern. So effectively I don't buy that argument. Another very, very cool thing about Node and I think this is the last thing that I'm going to stress on is the package manager. So Node comes with NPM. NPM is the Node package manager and what it allows you to do is install and manage all sorts of separate libraries and packages from the command line really, really easily. So I'm just going to quickly do a little demo here. So I wanted a MySQL driver and I just did NPM install MySQL and it went ahead and downloaded all the appropriate stuff. That's the version that we're using and MySQL has two dependencies. It's a dependency on require all and on big number.js. Both those were downloaded automatically and now inside my program I can go require MySQL and I'll have access to MySQL. Just like that, there are literally like hundreds of thousands if not millions of modules out there that can do pretty much everything that you're looking for. And we're going to use them all a lot tonight because you can have to be consuming a whole bunch of external APIs and presumably we're not going to be able to reinvent the wheel in one night. So just one more thing that I want you to see over here when you download this, when you run a NPM install what happens is so this folder Node.js so this is Node modules that folder gets created automatically by NPM and anything that's in there can be used in your require statements. That includes modules that you yourself have written. So as you can see there's a folder called MySQL in here and that contains the code for the MySQL driver. You'll notice that this folder also has a Node modules folder. I quickly go in there. You'll see that the dependencies of MySQL live inside that folder. Why is that interesting? It's interesting because these dependencies have specific version numbers. Version numbers that are compatible with the MySQL driver. When say big number.js gets updated by the person that runs that it's not going to impact you. Meaning even if you're using big number.js and the latest version outside this folder MySQL will still use the one in here which if you've ever had to deal with dependencies and packages and having to worry about which version is with which module this is like a godsend. This is fantastic. This actually allows you to do something else which is something that we do at Act Development. You can commit these inside your Git repo because the versions and everything will get pushed to the server correctly and since everything lives inside the Node modules folder your dependencies and making sure that the version numbers are right on the server happens automatically. So that's like a huge deal for me. I've had a whole bunch of problems in the past and this just kind of fixes that for me. So like I said, amazing version and dependency segregation and many, many modules. So you can do a quick GitHub search and you can probably find literally hundreds of thousands of different NPM repos and Node modules that you can just plug and play. Start working. That's it. If you guys have any questions I'm going to be here all night. So feel free to come and ask and I think that we're going to take a break. We're going to be talking about the proposals that were up on hacknight.in and then we're going to take a chai break and then start hacking. Awesome. Looking forward to it.