Node.js Crash Course (for .NET Developers)
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Neal, David
Node.js is a compelling platform that is quickly spreading from startups to the enterprise. Node.js strategically unites developers of all backgrounds through the common language of JavaScript. Why should you learn Node.js and where do you start? You will come away from this talk with the evidence to support Node.js, and tools you need to be productive. We will walk through a typical workflow of creating and debugging a web application. You will learn how easy it is to deploy, including Microsoft Azure. We'll also look at popular frameworks and modules, and other learning resources to give you the best start.
 I'm excited to be here and in case you didn't recognize, I am from the US. I'm from the deep south of the US. I speak fluent redneck. So I hope that you can understand my southern draw. My name is David Neal. I blog at reverendgeek.com and you can follow me on the Twitter's at reverendgeek. I'm pretty active on Twitter and that's probably one of the best ways to get in contact with me after the talk. So if I don't get to answer some of your questions or there's other things that come up after the talk that you think about, Twitter is probably the best way to get a hold of me. And you can trust me because I do have a beard and I like to ride motorcycles and I consume copious amounts of bacon and caffeine. And the bacon here is a little bit different than what I'm used to. I've been told that it's called streaky bacon is what I'm used to eating. Maybe it's just not enough and some of the bigger, thicker bacon here is better. I'm also finding other strange things about differences between the US and the UK. I'm wearing my lucky chemaflige suspenders, which I've been told is I'm not supposed to call them suspenders. I'm supposed to call them something else. I just don't get it. Bracers or braces, that's what kids put on their teeth. Right? It's braces. So we're talking about Node.js and JavaScript. JavaScript, as you may have heard, I'm not sure if Scott Hanselman said this earlier today or not, but JavaScript has won the web. And there's also this thing called Atwood's Law. It's a very genuine law. Any application that can be written in JavaScript will eventually be written in JavaScript. Just in point, if you search for JS Linux, you can find an entire Linux operating system running in the browser, all written in JavaScript. Crazy stuff. And Douglas Crockford, a well-known author and one of the main guys in JavaScript community, was on a panel a few years ago at another conference and someone asked him the question about how important JavaScript was. And he said that JavaScript is tragically important. You may know Douglas Crockford from his book, JavaScript, the Good Parts, which is suspiciously smaller than most other books on the subject of JavaScript. And so up ahead, what we're talking about is why Node.js, why do we want to consider using Node.js in our development stack, a quick crash course on how to get started. We'll look at some of the popular tools and frameworks, and we'll look at some integration strategies, perhaps from a.NET perspective. And I'll try to map some.NET information over to Node.js as we go. So you're here because Node.js has just exploded in popularity over the last few years. And it's in due part to the fact that it is JavaScript. Node.js is a JavaScript host execution engine that runs on the server, so that it's an alternative to writing server-side applications so that you can, as a web developer, it's kind of a nice thing to have is being able to focus on a single language of JavaScript. So we're already writing JavaScript on the web for the client-side. It's very nice to be able to use JavaScript on the server as well. How many would consider themselves web developers? Right? Good. So you all understand the importance of JavaScript and how convenient it might be to use JavaScript on the server. Another thing about Node.js is it uses the Chrome V8 engine. You might think that JavaScript being an interpretive language would not be very fast or efficient. You may have heard some of the claims of scalability and performance. How can you do that with something like a dynamic language like JavaScript? Well, the Chrome V8 engine, it compiles JavaScript at runtime to machine code, so whatever platform it's running on, similar to.NET..NET is not a binary language. It uses IEL and compiles that at runtime to run on whatever platform it's running on. So it's very similar in that regards. So once it's compiled at runtime, it's cached and all those kind of benefits, so you get real good performance from your JavaScript at runtime. Now JavaScript has a different runtime model than most other platforms. JavaScript and Node.js is a single-threaded asynchronous event loop. And it seems counterintuitive that a single-thread application would be able to perform very well, but because it's not having to do thread context switching and so forth from an IO perspective, Node.js on that single-threaded event loop model can handle thousands, tens of thousands of concurrent connections and scale very well because of the asynchronous event model that you're kind of forced into to fall into the pit of success. The patterns that you write your JavaScript with callbacks or promises and so forth, those things allow your application to scale as far as concurrency goes. The community for Node.js has also embraced this whole idea of JavaScript on the server. So JavaScript being kind of a ubiquitous language for the web has attracted folks from all different platforms from PHP.net, Java, just everything. So if you're a web developer, regardless of what platform you come from, it makes sense to also focus on JavaScript. And the packages and modules that are available for Node.js, I think last time I checked, were well over 200,000 modules available. So it's like the App Store. If there's a whatever you can think of, there's probably a module for that. The downside is there may be five or six modules that are for whatever you want to solve. And so choosing which one is right for your solution might be a challenge. Compare that to say Nougat on the.NET platform, somewhere around 40,000 to 50,000 packages, I think. Another reason that Node.js is interesting is that Microsoft themselves have recognized the importance of JavaScript on the server. When Node.js was first launched, it only ran on Linux. Microsoft in 2011 invested the time and resources into making Node.js available on the Windows platform. And Node.js is a first class citizen in Azure. You can spin up Node.js applications in Azure just as easily as you can in.NET. And Microsoft also has recently made roads into using the Chakra JavaScript engine from Edge, being able to shim that into Node.js to replace V8. The reason that they're doing that work is so that you can run Node.js on ARM-based IoT and the Windows Core type devices. That opens up some interesting scenarios there. So let me tell you a little bit about my story. I worked for this company called Linkit. You can see it on my shirt. We have traditionally been a Microsoft shop. We do ASP.NET NBC and C Sharp, SQL Server and Hibernate, and a whole lot of JavaScript and jQuery. We're our web application, so we have a lot of client-side work that we do. And we've been around for many years, and we've gone from, we've got a lot of, I guess you would call it technical debt, and a lot of, you know, we've grown as a company, and we're scaling our applications, and we've found that scaling the solutions that we've built over the last few years has led to a lot of frustration around, you know, do, and we even do what we're doing with our current stack of technologies. And so we've started to look at, you know, what are the best solutions to solve some of the problems that we're having? And because we have a web-based product and we spend a lot of time in the JavaScript world, we've decided that JavaScript is a strategically important language for us. It makes sense for us to continue to invest our time in JavaScript. From a recruiting standpoint, just like because Node.js has attracted lots of folks from other platforms, from a recruiting standpoint, Node.js makes sense to us because now we're not fighting over a limited set of.NET resources in our community. We can expand our recruiting efforts to any platform, any web developer who has JavaScript experience, who is an expert in JavaScript, we can leverage their skills. And it's a benefit to us that we bring in those kinds of folks from other platforms because now we have a polyglot environment where we're bringing in fresh ideas from those other platforms that help us to solve problems in unique ways. And we found in our experimentation and the projects that we've done in Node.js that we have become much more productive. There seems to be so much less friction from a standpoint of doing a TDD or BDD style approach of development. We're moving towards things like microservices and the clients in Node.js for technologies like RabbitMQ and RIOC and Redis. Those kinds of things get a lot more love in Node.js than they do, say, on the.NET platform. And the fact that Node.js is cross-platform, we can target Linux servers for deployment and save on the cost of just production environments. And there's been a whole lot more of this now that we've started doing Node.js. I was on a team that was one of the first teams to create some solutions in Node.js at my company. And then a few weeks into the process, I kept asking our guys, how do you feel about what we're doing so far? And the resounding response was always, huge thumbs up, let's keep going. So there's a lot of excitement and fun into adopting Node.js. There's a great article out on NearForm, why Node.js is becoming the go-to technology in the enterprise, and the highlights from that article are rapid innovation and delivery, developer happiness, those kinds of things. These are the same things that we have discovered in our company, as well as other companies that we've talked to that have gone the route of moving towards Node.js. To me, Node.js exemplifies the idea of start with the simplest solution that works and do one thing and do it well. Node.js is at its core, is just JavaScript execution engine. It's very, very, very simple to get started, and it's so easy to pull in those modules that add additional functionality. So you start with a really simple application framework, and then you can build on top of that. And it does, it is focused at doing web applications. So that use cases are things like single page apps, and API, and real-time, the ubiquitous hello world application for Node.js is a real-time chat server. Node.js makes it really, really simple to set up an HTTP service and be able to communicate between different nodes in just a few lines of code. It's very easy to do. Otherwise known as the internet. So if there's anything that you're doing that's involving the internet, Node.js is probably a good use case for it. Where Node.js seems to shine, in my opinion, is around the real-time streaming and the WebSockets technology. So if you're doing push notifications or any kind of real-time web applications, Node.js has been doing this for much, much longer, and the tooling and the modules that are available for doing streaming is much more mature. There are lots of great use case studies for companies who have adopted Node.js. Fandango is a ticket, movie ticket organization. These are some of the benefits that they have found in moving to Node.js. Another great article out on NearForm. And PayPal is another great case study. They ran an experiment. They wanted to see how Node.js compares with their current environment. They were traditionally a Java application shop, and they wanted to build a new feature, a new application, one team building it in Java and one team building it in Node.js, to see how it would compare. What they found was the Node.js team was able to build the solution two times faster with fewer developers, and they ended up with less code and less files, and they also saw some significant performance improvements over the Java application. I think what's really interesting about this case study is that they had been doing Java for years. These guys were the quote, unquote, Java experts on their team, and yet the Node.js team, who, you know, right out of the gate, first time trying Node.js, they were able to get these kinds of benefits and outperform the Java team. Walmart is another interesting case study. They ran an experiment on Black Friday in 2013. If you're not familiar with Black Friday, it's the Friday after Thanksgiving in the U.S. where it's like total chaos meltdown on the amount of retail traffic that happens. It's like the busiest, most critical day of the year for a retailer. Walmart chose to launch their new mobile platform on that Black Friday in 2013. This is the kind of things that they saw, 200 million concurrent users, the servers that they were running Node.js on, and the results were they never saw more than 1% CPU utilization across their servers, and they were able to deploy updates in real time without any hiccups or downtime. They've since moved a lot of their services over to Node.js, and they're having great success with it. Who else is using Node.js? Well, a lot of well-known companies you may have heard of. If you go to Node.js.org slash industry, you'll see a much, much larger list of companies that are now using Node.js. DevOps loves some Node.js. DevOps, as you probably know, is really hot right now. These are some of the reasons why DevOps would, in our experience, they love being able to easily deploy these small footprint applications cross-platform. It fits right in with Docker containerized applications. The fact that it's event-driven and there's OSS tools around, like telemetry and logging and so forth for Node.js, there's just a lot of benefits from a DevOps perspective as well. I don't know if you can read this chart, but it is, how long have you worked with Node.js and do you like your job? That's really exciting to me, looking at the future of my career that it seems like the longer you work with Node.js, the happier you are. That comes from what Node.js is used for the 2015 Node.js overview report from Rising Stack. Looks very promising. Let's switch gears now and take a look at how we can get started with Node.js. Installing it is really, really easy. You can go to Node.js.org and click the big fat green install button. If you're on Mac or Windows, whatever platform you're on, it will give you the appropriate download. How many here are on Windows? Have you seen, how many have used Choclity? How many are aware of Choclity? Well, I see more and more hands every time I give my talk, which is good. This is worth the price of this talk right here is getting introduced to Choclity. If you go to Choclity, it's kind of like an app get for Windows. It makes it really easy to download and install dependencies or applications on your PC. You go to Choclity.org and it is literally a one line that you can copy and paste into your command window to install it. Then after that, you can do things like Choclity. Install Node.js. I'm on a Mac, but I still use VMs for a lot of Windows things that I maintain. In Visual Studio. Every time I stand up a new VM on my Mac, I can just have a series of Choclity install scripts that I can run through and have my Windows machine set up in a matter of minutes. After you install Node.js, this is what you get. You get two command line executables. One is Node and that is the execution engine for launching your JavaScript and you literally just type Node space and then some JavaScript file to launch it. The other is MPM, which is the package manager. This makes it really easy to download and install packages or modules for your Node.js applications. Nothing too exciting there. There are two command line executables. Just so that you're aware on Windows, there may be a couple of other dependencies that you need. For the most part, the vast majority of Node.js modules are written purely in JavaScript. However, there are a few that rely on C libraries. These are cross-platform C libraries that when they come down from the MPM, they need to be compiled for your local architecture. When you're on Windows, there's a couple of things you need. You need Python 2, which you can install from Choclity using Choco install, or you can go to python.org and download. It needs to be version 2. There is a version 3, 2.7, something is probably what you need. The other thing you need is a C++ compiler. You may already have that if you have Visual Studio, but just to make your life a little bit easier, you may want to get specifically the 2010 express version of Visual C++. The reason is the modules that are available or the modules that have C code in them typically have build targets for this particular version of 2010. Just to, you know, it's pretty simple to install. There are ways to instruct your instance of Node.js to use whatever version of Visual Studio you may have. There's some flags you can use at the command line. Just to save time and frustration, this is probably what you'll want to do. There are also Node.js tools for Visual Studio. If you're already familiar with Visual Studio and that's your preferred editor, you can download this and be off and away editing and creating Node.js projects from within Visual Studio. You will need 2012 Pro or the latest versions of 2013, 2015 community editions. If you're running 2012 Pro or 2013, you'll want to make sure that you have the latest Visual Studio updates. Another alternative is that if you don't want to install the Node.js tools, or for some reason you can't install the Node.js tools, if you are an MSDN subscriber, you already have access to a lot of Azure credits, you can go to Azure and create a VM from their library that already has Visual Studio and the Node.js tools installed. You can play around with that before you do anything with your local environment. With that, I want to show you a quick demo of using Visual Studio and the Node.js tools. I have Visual Studio 2015 in a VM here and I have the Node.js tools already installed. When I click on New Project, one of the things that the Node.js tools give me is a set of project templates for Node.js. I can do things like start from a blank Node.js web application or an Express or some version of Azure. I've got a lot of templates to choose from. I'm going to choose the basic Node.js Express for application. Express is arguably the most popular NVC-style framework for Node.js. Node.js, like I said, is very, very simple. It has some libraries built in for doing networking and file IO and HTTP services. It's like real low-level stuff. You'll want to use something like Express as a starting point for building a web application. You might say this is kind of like ASP.NET for Node.js. I'm just going to click OK here. One of the reasons why it's taking a little bit longer than usual is that there's a number of dependencies for Express and the other modules that it's depending on. It's going out and fetching those things. So a little bit of this time is probably due to Wi-Fi access. So now we have a Node.js application, specifically Express. If you want to play around with this, you'll probably, if you've seen some of the demos for the ASP.NET, VNECS type of ASP, you'll see a lot of ideas, similar ideas and things that ASP.NET has borrowed from Node.js as far as the composability and plug-ins and so forth of building up an application. I'm not going to really go into the code very much, but I do want to show you just what the Node.js tools give you in Visual Studio. I can set breakpoints, like I'll set a breakpoint right here, and I can launch this in Chrome. And I've already hit my breakpoint. And if I mouse over, I can see things like, I can see all the properties and methods that are on that object. I can see things like my locals down here. I can set watch and breakpoints. And I also have a call stack. So all the debugging features that you would be familiar with from Visual Studio, you can build your Node.js applications the same way. And you can play around with, you know, in the immediate window, you can set, change, play around with different values for your variables and do things like that. And if I continue on, then it launches my application, and I got expressed, welcome to express. It's, you know, Microsoft went to a lot of trouble to make sure that it looks like a really awesome starting template, right? The other thing that Node.js tools will give you is under tools, Node.js tools, there is a Node.js interactive window. So Ctrl-K-N. And what this gives you is a bit of a repel, an interactive window where you can play around with the modules that you have installed and be able to do expressions and things like x equals one, y equals three, x plus y. And you can play around the JavaScript language and, you know, it's a good way to learn the tools and learn how to, you know, maybe you're going through a Node.js tutorial online or reading through a book or something like that. This is a way to make it really easy to play around with Node.js. I want to show you some other things. So you may, how many have heard of Visual Studio Code, right? So Microsoft has done a good job of advertising that they have this new editor called Visual Studio Code, and it makes it really easy to build web-based applications. And Node.js is a first-class citizen for Visual Studio Code. It's a really nice editor. You may, my first reaction was, well, it's cross-platform. It runs on Linux, Mac, and Windows. How did they accomplish that? My assumption was they probably used Xamarin. Xamarin is supposed to be cross-platform, and Microsoft has a good relationship with Xamarin team. Turns out this is actually a Node.js application. Visual Studio Code is now open-source, and you can go and look at it. It's an electron JS application similar to GitHub's Atom editor. And so Microsoft, again, showing that they are embracing the larger open-source community and using tools that are outside of the Microsoft normal ecosystem. Very interesting. So they're calling it a code assistance, but it does have really good debugging tools. So the kind of debugging experience I just showed you in Visual Studio, you can set break points, and you can have the locals, and you can set watch watches, and you can step through your code, and you can inspect variables. You can do all those same kind of things. You can do it in this really lightweight editor that makes it really easy to create. Now, I'll talk to you about, let's talk about a typical workflow of building a Node.js application. The two command lines you get is Node and NPM, NPM being the package manager. So if you're creating a new brand new Node.js project outside of Visual Studio, you'll probably want to start with the command line and use NPM init to initialize this special file called a package.json. The package.json is a kind of a manifest for your application. It lists things like the author and the version number of the application and any dependencies that your application has. So it's kind of both your manifest and your package, NuGet package list, if you will. So after you do NPM init and initialize your package.json file, then you'll start installing dependencies that you have, like NPM install load-. Load- is being a very popular functional utility library that may have been using in your client side applications. There's a lot of client side libraries that you can also use on the server side. And the dash-save is important because that's what it instructs NPM to save that entry into your package.json file. So when you go to distribute your application, install it on another platform for, you know, in production, it can read that package.json file and know what dependencies it needs to download and install. A typical Node.js application looks like this. You'll see at the top of the file some things like require statements. And these are similar to in.NET to the using statements. So this is how you import in your modules and reference those in your Node.js application. So there's two forms of require. One is require that just is the name of the module. And that's for built-in Node.js modules, like FS is the file system module for doing file I.O. and express would be something that you would pull down from NPM. In your own application, as you create your own modules, then you reference those by a relative path like slash app slash my service. And in some cases, you may need those, most of the time when you reference a package or a module in Node.js, it's not only creating a reference to it, but you're creating an instance of it. And you can use it right away. But there are some modules that require you to initialize kind of like using, you know, a constructor function. So in this case, my service is a constructor function that takes in a number of parameters to initialize that module, an instance of that module. And then the typical callback pattern that you'll see in Node.js is this. You'll have some method and you'll pass either one or more parameters or zero parameters as far as like arguments to that method. And then the next thing is a callback function. A callback function is a callback. It means when you're done executing this method, let me know the results of that and send it to this function. So the callback is like, it's kind of like an async and wait pattern. This is how it's able to do a lot of concurrency on that single thread event loop. You're not blocking on that method. You're saying, go do this work and when you're done, let me know. And the typical pattern is the first parameter returned on a callback is always the error object. You want to inspect that error object to see if that method did raise any errors. It can throw exceptions as well, so you need to watch for those kinds of things. But typically, instead of throwing errors, it's just going to pass error information through that error object. And then your results and there may be other parameters that are returned back from the method that you're calling. Creating your own modules, there's a couple of different ways when you're creating your own modules that you want to do this. Here's an example of a module I'm creating that has some utility functions in it. One is convert to Celsius and convert to Fahrenheit and then I've got some values. In JavaScript, you can create objects. It's a dynamic language and you can create your own objects on the fly just by saying like this plain old JSON here. I'm just saying it's got these properties, freezing Celsius, freezing Fahrenheit, boiling. These are just properties on that object. The interesting thing is this guy down here, module.exports. That's the secret sauce right there. So when you're declaring your own modules, you're exposing whatever properties and methods you want to the rest of the world through that module.exports. I can control, I'm exporting this object and this object has properties and a couple of methods. So when I require this module in somewhere else, I'm going to have the ability to call these two methods and to access these properties. Another typical module pattern that you'll see is a constructor function. So in here, I've got a config module that I'm declaring. I'm also requiring in the file system and I'm reading some config data and I've got some properties on getting and setting configuration information. The interesting thing is the return statement. These are my methods that I have and I have this one here called internal function. When I return from that constructor, that JavaScript constructor function, I'm only returning get, set and save. I'm not returning internal function so that's kind of like a private member of that module. I can still use it inside that module but it won't be exposed to the rest of the world and of course I've got module.exports and that function. I get asked a lot about SQL databases. About how do you access SQL server or some other relational database from Node.js. There are a number of modules that are available. Their MS SQL is the most popular. My favorite is called seriate. It's actually a module that sits a little bit higher than MS SQL. It has MS SQL as an appendix. But it provides a lot of nice features that are a little bit opinionated but I think it turns it into more of a micro-ORM. If you're familiar with something like dapper as being a really, really lightweight micro-ORM, you might think of this as an equivalent. Seriate allows you to, once you install it and require it in, you can set your configuration information. Your configuration information typically comes from environment variables. So instead of having like a config file like you have in.NET, you will have environment variables and that way when you go to deploy your application, like in Azure, there are places to set those environment variables and you can do it that way. But here we're just passing those values in on the default config and then I can do things like execute a query and this can be not only just inline SQL but it can be a stored procedure. It can be a reference to a SQL file that has all the SQL in it. It supports parameters and input, output parameters, all the things you would expect. And then this is an example of promises. So instead of a callback function, you're saying go execute this application or this method and when you're done, then call this promise, this then module function. The interesting thing about seriate is that you can chain, because it's promises, you can chain these together. You can say execute this SQL, then pass the results of that statement to this next SQL statement and you can chain SQL statements together, which is a typical workflow for building a data-centric application. You're typically having to go and retrieve results here and based on those results, go retrieve another set of results, that kind of thing. So any questions about the code that we've seen so far? All right. Good. So deploying Node.js is really, really easy. Usually you don't include the Node.modules folder. What I'm talking about there is when you install an NPM package, you do NPM installed and something like load-dash, those things get added to a special folder named Node underscore modules. And like I said before, those can be compiled sometimes if they include C code to your particular architecture. So if you're developing on one platform, if you're developing on a Mac or a Windows 32-bit architecture and you're deploying to a 64-bit architecture kind of thing, then you don't need to include this Node.modules folder. Everything you need to run in production is going to be listed in your package JSON file. And so when you deploy your application, you're just going to run NPM install without any parameters and it's going to read your package JSON and install all those dependencies for you. Alternatively, if you do know your specific build targets or your platforms that you're deploying to, you could set up a CI server that is the exact same architecture as your production servers and do your builds there and then package everything up into a zip file or something to move to your production environment. Building for Azure, deploying to Azure is really easy. As I've mentioned before, Node.js is a first-class citizen in Azure and they have a number of templates available for you to get started, some either starter web application or VMs. If you're deploying to Windows, regardless of if it's Azure or your own VMs or own hardware, there's a couple of options you need to be aware of. One is IIS Node. This is a way of hosting. If you're just deploying a web application, you probably want to use IIS Node. This allows you to run a Node.js application through IIS and IIS makes it efficiently, depending on, say, your server has four cores, it can spin up four copies of Node.js so that you're taking advantage of the cores that are on that server. It handles hands-off each request to kind of an around-robin fashion to whichever instance of Node.js is available. That allows you to scale easily on a single box. Windsor, if you're developing like a microservices architecture or you're creating just a service, maybe it's a worker service that's listening to a queue that's doing some commands or doing some work for a distributed application, then Windsor is probably something you want to use. It makes your Node.js application look like a native Windows service that you can pause and start, restart, stop, those kinds of things. It will make sure that your application remains running. If it does crash, it will automatically restart your application, typical Windows service behavior. On Linux, if you're deploying to Linux, you probably want to use something like forever, which does the same kind of thing. It ensures that your application is always running, if it crashes, it will restart it, so forth. I already mentioned on Azure, you can create an empty Node.js website. You can do things like connect to a repository. This is what I do for my own blog. My blog is a Node.js application, and it's hosted on GitHub. Anytime I make a push a change to my Node.js repository, Azure instantly gets that notification and will download the latest version from the repository and redeploy it. I can get a fresh new version of my blog pushed in less than a minute. There's a lot of folks that do this same kind of deployment. Here it doesn't have to be GitHub, it can be Visual Studio Online or what they're calling it now, Visual Studio Team Services, and a number of other repositories that you can connect to. I've got an article out on my website, Reverend Geek, hosting Node.js on Microsoft Azure, and I go through some of the steps of both doing a repository-based approach or setting up your own VM and using something like Windsor or hosting using IIS nodes. I go through all those options in detail, and it's really easy to do. Recommended toolbox. In my experience and with the guys that I've worked with, this is what we found to be some really useful modules, Low-dash being just general functional utilities that you're probably already aware of, similar to underscore. Then is a Promise library and makes it really easy to, callbacks can get, start to get really hairy with callbacks that have callbacks that have callbacks. Promises is a much more cleaner way of having that kind of asynchronous pattern and just having chainable calls of then, then, then, and then when you're finished. Make for parallel asynchronous and parallel execution, so maybe you have five tasks that you need to run and then let me know when all five of those are finished. You can think of as kind of like the task parallel library in.NET where you can do things like execute lots of things, either in parallel or serial, and be notified when those things are finished. Rest or rest, those are really good HTTP clients. So if you're depending on other web services in your application, you're creating a mashup and you want to be able to call into other web services or maybe you have web services already in your environment that you have dependencies on, this makes it really easy. Gulp and then there are a number of others. You've probably heard of Grunt and lots of other build systems, but we use Gulp. It's great as a build engine and test runner. Socket I.O. for sockets in real time. Node Inspector, so if you want to dive head first into the world of Node.js, you may want to use something like Adam or Sublime Text or even Visual Studio Code and break ties with big, big IDEs. It's really an awesome development experience just having lightweight editors for JavaScript. Node Inspector allows you to launch your Node applications with Chrome, the Chrome debug tools. So you get a great, if you're already familiar with the Chrome debug experience of being able to set break points and step through your code and look at all your variables and so forth, you can do the same thing with your Node.js applications using Node Inspector. This is what I use all the time. I develop my applications in Sublime Text and I launch them with Node debug and I'm able to use Chrome as my debugging tool and it's really awesome. Mocha, Chai, and Cyanon, those are really good testing frameworks. So if you want to see what it's all about in the TDD or BDD world for Node.js, those are the tools to use and really, really less friction as I mentioned before. It's so much easier to build and maintain a TDD or BDD's first approach in Node.js because of the nature of JavaScript. There are a number of popular frameworks that we talked about Express. There are things like HAPI and Meteor and Sales. HAPI is the web server open source community around Walmart. Walmart created, originally called this under the Walmart Labs. HAPI has grown. They've got tons and tons of other modules and support features that you can bolt on and it's a really, really impressive framework. There's a couple of books out on HAPI now. If you're building just straight APIs, HAPI is great too, but there's also ones that are some frameworks that are specific to APIs. Restify, Loopback, which is from Strongloop, which is now part of IBM. Loopback does things out of the box like push notifications for mobile applications. So it's a great platform for doing mobile apps. Auto host and hyped, those are good clients if you want to do a hyper media approach to APIs, if you want to support the hyper media documents with links and so forth, that platform makes it really easy. A couple other resources, if you go to nodeframework.com or nodewebmodules.com, that's kind of a curated list of the most popular frameworks for doing web applications and NBC style applications. Another thing I want to tell you about is EdgeJS. If you are a.NET developer, this may be of interest to you. EdgeJS is a bridge between.NET and NodeJS. It allows you to run.NET code in process with your NodeJS application. So you can create a NodeJS application and reference your.NET code and take advantage of those libraries that you may already have. And it's not just C sharp code, you can take advantage of F sharp or Python or PowerShell, anything that you can execute in a.NET world. You can reference, you can do inline code or you can reference CS files or assemblies. And it's a great alternative, as I mentioned before, typically you find either pure JavaScript or a mixture of JavaScript and C modules. And if you're needing to create something that's outside of what you may want to do with JavaScript or you really need to do some CPU intensive work that requires multi-threading,.NET EdgeJS could allow you to build that kind of solution instead of having to write it in C. It does require.NET 4.5 or Mono 3.1 and above. The reason for that dependency is you need to have async and await support. If you don't have async and await, then you're going to be blocking that main thread. And so you need to be able to play well in the single-threaded event loop model that Node.js has. SJS can work both ways, so you can also use SJS inside your.NET application to call into Node.js. So if there's something in Node.js that's really awesome that you just want to add that functionality into your.NET program, you can do that. So what can you do with it? You can leverage existing.NET investment. You can access, so there are modules available in Node.js for things like TFS and SharePoint Exchange, but typically they are half-baked. Maybe they're not well-supported. The Microsoft stack doesn't get quite as much love in the Node.js community as most other open-source tools do. So open-source is always the number one thing that the Node.js community wants to focus on. So if you do find a module for some Microsoft technology in Node.js, it's typically not fully featured. Even the SQL module that Microsoft created never got out of alpha and would not use that in production. So Active Directory, maybe you want to access local hardware from Node.js, maybe you want to automate some things, use a 3D printer from your Node.js application. I can't really think of a scenario why you would want to do that, but it does open up those kinds of possibilities. And again, if you're doing really CPU-intensive work that is not well-suited for JavaScript and the single-threaded event loop model, you could offload some of that work to a.NET module. And PowerShell, that opens up some interesting scenarios from a DevOps perspective. So let's talk about some Node.js integration strategies. Now you could use Node.js as a proxy. This is how a lot of companies have introduced Node.js in their organization. So PayPal, Walmart, and my company, a number of other companies, we've introduced Node.js as a proxy service. It's just a middleware layer. So incoming requests come in, they hit Node.js first, Node.js can, in that proxy scenario, can decide, well, is this something we want to handle? Can we handle this request natively using Node.js, or do we need to hand that off to some other back-end service in.NET or Java or whatever system we were using before? You could use something like SJS to access.NET code. You could use the request module or REST module to be able to call into other APIs in your architecture, in your infrastructure. And then there's things like messaging. So the clients that are available in Node.js for RabbitMQ and Azure and a number of other message buses are really, really powerful, really great. This is the approach that we're taking with being able to distribute the load of computing across our different, you know, either.NET or Node.js modules or applications and services. And it works really well. And the one more thing I want to tell you about is this awesome thing called Electron. I give a talk on this, I've given a talk on this at a number of other conferences. Electron is the desktop shell that Atom and Visual Studio code and even applications like Slack. So if you use Slack, the desktop client, you're using a Node.js, HTML and CSS application, and you wouldn't even know it. It's a web application. And Electron is now an open source, and you can use it to build your own cross-platform desktop applications. I've created a number of tools for our customers that now I don't have to worry about, you know, I'm a.NET developer, so I was kind of forced to use the.NET, you know, I was building solutions that I would hand off to clients and my clients would say, well, we don't even use Windows here. I'm like, oh, well, let me see what I can do. So I went back and tried to use Xamarin Mac to create a Mac version of my tools, and to be honest, the Xamarin Mac is not, it doesn't get nearly the amount of love that the iOS and Android tools get. So it's much harder to create a desktop app using.NET than it is to use something like Node.js and Electron. And the last thing I want to tell you is you don't need permission to be awesome. So we as developers, I truly believe we are in a unique position, a unique set of skills, and we have opportunities that we can change our environment and our world in significant ways. And so the things that you're learning here at this conference, please take those back and change your world. With that, I'd like to thank you again for coming to my talk. Here's some contact information and resources that you can get on my GitHub repo. I've got some Node.js demos and a list of everything that's in the, I've got these slides as well as a list of all kinds of resources. And if there are any questions, we've got a microphone here. Be glad to answer for the next few minutes. Well, for the recording purposes. You mentioned Electron as cross platform. Does that cover mobile or just desktop application? It's just for desktop, so you can think of it as the phone gap, Cordova equivalent. So Electron does allow you to leverage a lot of your existing JavaScript and HTML code that you may have created already for your web app or for a mobile app. So if you're doing a hybrid mobile application, you could probably use the same, a lot of the same JavaScript and HTML that you've used in those cases and be able to create a desktop version. But as of now, Electron is just for Mac, Windows, and Linux desktops. Now I think there are some interesting scenarios that will probably happen down the road with, I know I mentioned Microsoft has done work to enable Chakra as a alternative JavaScript engine and that opens up a lot of possibilities. That may open up some possibilities of going mobile with Node.js. It's a possibility. Yep. Is there any package that's like link that you can use to include? I'm sorry? Like link? Like? Oh, uh... So, I'm not so sure. I'm not so sure. I'm not so sure. But I would be really surprised or shocked to find that there weren't some type of expression language like that for Node.js. So I don't... Sorry, I don't have a direct answer for you, but I would... If I can search NPM later and we can find that answer. Yes? It's a question about IIS Node and Edge. They seem like good ideas, but are they ready for production? Have you used them in your deployments and how has the experience been? So we have never used SJS in production at my company, but I know that SJS has been used in production in a number of other companies. And if you're targeting the Windows platform, deployment is pretty easy because you already have the.NET framework available for SJS. There's not really any additional work to be done. IIS Node production systems running? Yes. Yeah, it's really easy to get IIS Node. And if you deploy to Azure, IIS Node is the mechanism for which you are deploying your Node.js applications. Microsoft uses IIS Node to host your Node.js application and to make it available as a web application. Anyone else? All right. Thank you very much. Don't forget the giveaway stuff up here. Thank you. Thank you. Thank you.
 I'm excited to be here and in case you didn't recognize, I am from the US.  I'm from the deep south of the US.  I speak fluent redneck.  So I hope that you can understand my southern draw.  My name is David Neal.  I blog at reverendgeek.com and you can follow me on the Twitter's at reverendgeek.  I'm pretty active on Twitter and that's probably one of the best ways to get in contact with  me after the talk.  So if I don't get to answer some of your questions or there's other things that come up after  the talk that you think about, Twitter is probably the best way to get a hold of me.  And you can trust me because I do have a beard and I like to ride motorcycles and I consume  copious amounts of bacon and caffeine.  And the bacon here is a little bit different than what I'm used to.  I've been told that it's called streaky bacon is what I'm used to eating.  Maybe it's just not enough and some of the bigger, thicker bacon here is better.  I'm also finding other strange things about differences between the US and the UK.  I'm wearing my lucky chemaflige suspenders, which I've been told is I'm not supposed to  call them suspenders.  I'm supposed to call them something else.  I just don't get it.  Bracers or braces, that's what kids put on their teeth.  Right?  It's braces.  So we're talking about Node.js and JavaScript.  JavaScript, as you may have heard, I'm not sure if Scott Hanselman said this earlier  today or not, but JavaScript has won the web.  And there's also this thing called Atwood's Law.  It's a very genuine law.  Any application that can be written in JavaScript will eventually be written in JavaScript.  Just in point, if you search for JS Linux, you can find an entire Linux operating system  running in the browser, all written in JavaScript.  Crazy stuff.  And Douglas Crockford, a well-known author and one of the main guys in JavaScript community,  was on a panel a few years ago at another conference and someone asked him the question  about how important JavaScript was.  And he said that JavaScript is tragically important.  You may know Douglas Crockford from his book, JavaScript, the Good Parts, which is suspiciously  smaller than most other books on the subject of JavaScript.  And so up ahead, what we're talking about is why Node.js, why do we want to consider  using Node.js in our development stack, a quick crash course on how to get started.  We'll look at some of the popular tools and frameworks, and we'll look at some integration  strategies, perhaps from a.NET perspective.  And I'll try to map some.NET information over to Node.js as we go.  So you're here because Node.js has just exploded in popularity over the last few years.  And it's in due part to the fact that it is JavaScript.  Node.js is a JavaScript host execution engine that runs on the server, so that it's an  alternative to writing server-side applications so that you can, as a web developer, it's  kind of a nice thing to have is being able to focus on a single language of JavaScript.  So we're already writing JavaScript on the web for the client-side.  It's very nice to be able to use JavaScript on the server as well.  How many would consider themselves web developers?  Right?  Good.  So you all understand the importance of JavaScript and how convenient it might be to use JavaScript  on the server.  Another thing about Node.js is it uses the Chrome V8 engine.  You might think that JavaScript being an interpretive language would not be very fast or efficient.  You may have heard some of the claims of scalability and performance.  How can you do that with something like a dynamic language like JavaScript?  Well, the Chrome V8 engine, it compiles JavaScript at runtime to machine code, so whatever platform  it's running on, similar to.NET. .NET is not a binary language.  It uses IEL and compiles that at runtime to run on whatever platform it's running on.  So it's very similar in that regards.  So once it's compiled at runtime, it's cached and all those kind of benefits, so you get  real good performance from your JavaScript at runtime.  Now JavaScript has a different runtime model than most other platforms.  JavaScript and Node.js is a single-threaded asynchronous event loop.  And it seems counterintuitive that a single-thread application would be able to perform very  well, but because it's not having to do thread context switching and so forth from an IO perspective,  Node.js on that single-threaded event loop model can handle thousands, tens of thousands  of concurrent connections and scale very well because of the asynchronous event model that  you're kind of forced into to fall into the pit of success.  The patterns that you write your JavaScript with callbacks or promises and so forth, those  things allow your application to scale as far as concurrency goes.  The community for Node.js has also embraced this whole idea of JavaScript on the server.  So JavaScript being kind of a ubiquitous language for the web has attracted folks from all different  platforms from PHP.net, Java, just everything.  So if you're a web developer, regardless of what platform you come from, it makes sense  to also focus on JavaScript.  And the packages and modules that are available for Node.js, I think last time I checked, were  well over 200,000 modules available.  So it's like the App Store.  If there's a whatever you can think of, there's probably a module for that.  The downside is there may be five or six modules that are for whatever you want to solve.  And so choosing which one is right for your solution might be a challenge.  Compare that to say Nougat on the.NET platform, somewhere around 40,000 to 50,000 packages,  I think.  Another reason that Node.js is interesting is that Microsoft themselves have recognized  the importance of JavaScript on the server.  When Node.js was first launched, it only ran on Linux.  Microsoft in 2011 invested the time and resources into making Node.js available on the Windows  platform.  And Node.js is a first class citizen in Azure.  You can spin up Node.js applications in Azure just as easily as you can in.NET.  And Microsoft also has recently made roads into using the Chakra JavaScript engine from  Edge, being able to shim that into Node.js to replace V8.  The reason that they're doing that work is so that you can run Node.js on ARM-based IoT  and the Windows Core type devices.  That opens up some interesting scenarios there.  So let me tell you a little bit about my story.  I worked for this company called Linkit.  You can see it on my shirt.  We have traditionally been a Microsoft shop.  We do ASP.NET NBC and C Sharp, SQL Server and Hibernate, and a whole lot of JavaScript  and jQuery.  We're our web application, so we have a lot of client-side work that we do.  And we've been around for many years, and we've gone from, we've got a lot of, I guess  you would call it technical debt, and a lot of, you know, we've grown as a company, and  we're scaling our applications, and we've found that scaling the solutions that we've  built over the last few years has led to a lot of frustration around, you know, do,  and we even do what we're doing with our current stack of technologies.  And so we've started to look at, you know, what are the best solutions to solve some  of the problems that we're having?  And because we have a web-based product and we spend a lot of time in the JavaScript world,  we've decided that JavaScript is a strategically important language for us.  It makes sense for us to continue to invest our time in JavaScript.  From a recruiting standpoint, just like because Node.js has attracted lots of folks from other  platforms, from a recruiting standpoint, Node.js makes sense to us because now we're not fighting  over a limited set of.NET resources in our community.  We can expand our recruiting efforts to any platform, any web developer who has JavaScript  experience, who is an expert in JavaScript, we can leverage their skills.  And it's a benefit to us that we bring in those kinds of folks from other platforms  because now we have a polyglot environment where we're bringing in fresh ideas from those  other platforms that help us to solve problems in unique ways.  And we found in our experimentation and the projects that we've done in Node.js that we  have become much more productive.  There seems to be so much less friction from a standpoint of doing a TDD or BDD style approach  of development.  We're moving towards things like microservices and the clients in Node.js for technologies  like RabbitMQ and RIOC and Redis.  Those kinds of things get a lot more love in Node.js than they do, say, on the.NET platform.  And the fact that Node.js is cross-platform, we can target Linux servers for deployment  and save on the cost of just production environments.  And there's been a whole lot more of this now that we've started doing Node.js.  I was on a team that was one of the first teams to create some solutions in Node.js at my  company.  And then a few weeks into the process, I kept asking our guys, how do you feel about what  we're doing so far?  And the resounding response was always, huge thumbs up, let's keep going.  So there's a lot of excitement and fun into adopting Node.js.  There's a great article out on NearForm, why Node.js is becoming the go-to technology in  the enterprise, and the highlights from that article are rapid innovation and delivery,  developer happiness, those kinds of things.  These are the same things that we have discovered in our company, as well as other companies  that we've talked to that have gone the route of moving towards Node.js.  To me, Node.js exemplifies the idea of start with the simplest solution that works and  do one thing and do it well.  Node.js is at its core, is just JavaScript execution engine.  It's very, very, very simple to get started, and it's so easy to pull in those modules  that add additional functionality.  So you start with a really simple application framework, and then you can build on top of  that.  And it does, it is focused at doing web applications.  So that use cases are things like single page apps, and API, and real-time, the ubiquitous  hello world application for Node.js is a real-time chat server.  Node.js makes it really, really simple to set up an HTTP service and be able to communicate  between different nodes in just a few lines of code.  It's very easy to do.  Otherwise known as the internet.  So if there's anything that you're doing that's involving the internet, Node.js is probably  a good use case for it.  Where Node.js seems to shine, in my opinion, is around the real-time streaming and the  WebSockets technology.  So if you're doing push notifications or any kind of real-time web applications, Node.js  has been doing this for much, much longer, and the tooling and the modules that are available  for doing streaming is much more mature.  There are lots of great use case studies for companies who have adopted Node.js.  Fandango is a ticket, movie ticket organization.  These are some of the benefits that they have found in moving to Node.js.  Another great article out on NearForm.  And PayPal is another great case study.  They ran an experiment.  They wanted to see how Node.js compares with their current environment.  They were traditionally a Java application shop, and they wanted to build a new feature,  a new application, one team building it in Java and one team building it in Node.js, to  see how it would compare.  What they found was the Node.js team was able to build the solution two times faster with  fewer developers, and they ended up with less code and less files, and they also saw some  significant performance improvements over the Java application.  I think what's really interesting about this case study is that they had been doing Java  for years.  These guys were the quote, unquote, Java experts on their team, and yet the Node.js team, who,  you know, right out of the gate, first time trying Node.js, they were able to get these  kinds of benefits and outperform the Java team.  Walmart is another interesting case study.  They ran an experiment on Black Friday in 2013.  If you're not familiar with Black Friday, it's the Friday after Thanksgiving in the  U.S. where it's like total chaos meltdown on the amount of retail traffic that happens.  It's like the busiest, most critical day of the year for a retailer.  Walmart chose to launch their new mobile platform on that Black Friday in 2013.  This is the kind of things that they saw, 200 million concurrent users, the servers  that they were running Node.js on, and the results were they never saw more than 1% CPU  utilization across their servers, and they were able to deploy updates in real time without  any hiccups or downtime.  They've since moved a lot of their services over to Node.js, and they're having great  success with it.  Who else is using Node.js?  Well, a lot of well-known companies you may have heard of.  If you go to Node.js.org slash industry, you'll see a much, much larger list of companies  that are now using Node.js.  DevOps loves some Node.js.  DevOps, as you probably know, is really hot right now.  These are some of the reasons why DevOps would, in our experience, they love being able to  easily deploy these small footprint applications cross-platform.  It fits right in with Docker containerized applications.  The fact that it's event-driven and there's OSS tools around, like telemetry and logging  and so forth for Node.js, there's just a lot of benefits from a DevOps perspective as well.  I don't know if you can read this chart, but it is, how long have you worked with Node.js  and do you like your job?  That's really exciting to me, looking at the future of my career that it seems like the  longer you work with Node.js, the happier you are.  That comes from what Node.js is used for the 2015 Node.js overview report from Rising Stack.  Looks very promising.  Let's switch gears now and take a look at how we can get started with Node.js.  Installing it is really, really easy.  You can go to Node.js.org and click the big fat green install button.  If you're on Mac or Windows, whatever platform you're on, it will give you the appropriate  download.  How many here are on Windows?  Have you seen, how many have used Choclity?  How many are aware of Choclity?  Well, I see more and more hands every time I give my talk, which is good.  This is worth the price of this talk right here is getting introduced to Choclity.  If you go to Choclity, it's kind of like an app get for Windows.  It makes it really easy to download and install dependencies or applications on your PC.  You go to Choclity.org and it is literally a one line that you can copy and paste into  your command window to install it.  Then after that, you can do things like Choclity.  Install Node.js.  I'm on a Mac, but I still use VMs for a lot of Windows things that I maintain.  In Visual Studio.  Every time I stand up a new VM on my Mac, I can just have a series of Choclity install  scripts that I can run through and have my Windows machine set up in a matter of minutes.  After you install Node.js, this is what you get.  You get two command line executables.  One is Node and that is the execution engine for launching your JavaScript and you literally  just type Node space and then some JavaScript file to launch it.  The other is MPM, which is the package manager.  This makes it really easy to download and install packages or modules for your Node.js  applications.  Nothing too exciting there.  There are two command line executables.  Just so that you're aware on Windows, there may be a couple of other dependencies that  you need.  For the most part, the vast majority of Node.js modules are written purely in JavaScript.  However, there are a few that rely on C libraries.  These are cross-platform C libraries that when they come down from the MPM, they need  to be compiled for your local architecture.  When you're on Windows, there's a couple of things you need.  You need Python 2, which you can install from Choclity using Choco install, or you can go  to python.org and download.  It needs to be version 2.  There is a version 3, 2.7, something is probably what you need.  The other thing you need is a C++ compiler.  You may already have that if you have Visual Studio, but just to make your life a little  bit easier, you may want to get specifically the 2010 express version of Visual C++.  The reason is the modules that are available or the modules that have C code in them typically  have build targets for this particular version of 2010.  Just to, you know, it's pretty simple to install.  There are ways to instruct your instance of Node.js to use whatever version of Visual  Studio you may have.  There's some flags you can use at the command line.  Just to save time and frustration, this is probably what you'll want to do.  There are also Node.js tools for Visual Studio.  If you're already familiar with Visual Studio and that's your preferred editor, you can  download this and be off and away editing and creating Node.js projects from within  Visual Studio.  You will need 2012 Pro or the latest versions of 2013, 2015 community editions.  If you're running 2012 Pro or 2013, you'll want to make sure that you have the latest  Visual Studio updates.  Another alternative is that if you don't want to install the Node.js tools, or for some  reason you can't install the Node.js tools, if you are an MSDN subscriber, you already  have access to a lot of Azure credits, you can go to Azure and create a VM from their  library that already has Visual Studio and the Node.js tools installed.  You can play around with that before you do anything with your local environment.  With that, I want to show you a quick demo of using Visual Studio and the Node.js tools.  I have Visual Studio 2015 in a VM here and I have the Node.js tools already installed.  When I click on New Project, one of the things that the Node.js tools give me is a set of  project templates for Node.js.  I can do things like start from a blank Node.js web application or an Express or some version  of Azure.  I've got a lot of templates to choose from.  I'm going to choose the basic Node.js Express for application.  Express is arguably the most popular NVC-style framework for Node.js.  Node.js, like I said, is very, very simple.  It has some libraries built in for doing networking and file IO and HTTP services.  It's like real low-level stuff.  You'll want to use something like Express as a starting point for building a web application.  You might say this is kind of like ASP.NET for Node.js.  I'm just going to click OK here.  One of the reasons why it's taking a little bit longer than usual is that there's a number  of dependencies for Express and the other modules that it's depending on.  It's going out and fetching those things.  So a little bit of this time is probably due to Wi-Fi access.  So now we have a Node.js application, specifically Express.  If you want to play around with this, you'll probably, if you've seen some of the demos  for the ASP.NET, VNECS type of ASP, you'll see a lot of ideas, similar ideas and things  that ASP.NET has borrowed from Node.js as far as the composability and plug-ins and so  forth of building up an application.  I'm not going to really go into the code very much, but I do want to show you just what  the Node.js tools give you in Visual Studio.  I can set breakpoints, like I'll set a breakpoint right here, and I can launch this in Chrome.  And I've already hit my breakpoint.  And if I mouse over, I can see things like, I can see all the properties and methods that  are on that object.  I can see things like my locals down here.  I can set watch and breakpoints.  And I also have a call stack.  So all the debugging features that you would be familiar with from Visual Studio, you can  build your Node.js applications the same way.  And you can play around with, you know, in the immediate window, you can set, change,  play around with different values for your variables and do things like that.  And if I continue on, then it launches my application, and I got expressed, welcome to express.  It's, you know, Microsoft went to a lot of trouble to make sure that it looks like a  really awesome starting template, right?  The other thing that Node.js tools will give you is under tools, Node.js tools, there is  a Node.js interactive window.  So Ctrl-K-N. And what this gives you is a bit of a repel, an interactive window where  you can play around with the modules that you have installed and be able to do expressions  and things like x equals one, y equals three, x plus y.  And you can play around the JavaScript language and, you know, it's a good way to learn the  tools and learn how to, you know, maybe you're going through a Node.js tutorial online or  reading through a book or something like that.  This is a way to make it really easy to play around with Node.js.  I want to show you some other things.  So you may, how many have heard of Visual Studio Code, right?  So Microsoft has done a good job of advertising that they have this new editor called Visual  Studio Code, and it makes it really easy to build web-based applications.  And Node.js is a first-class citizen for Visual Studio Code.  It's a really nice editor.  You may, my first reaction was, well, it's cross-platform.  It runs on Linux, Mac, and Windows.  How did they accomplish that?  My assumption was they probably used Xamarin.  Xamarin is supposed to be cross-platform, and Microsoft has a good relationship with  Xamarin team.  Turns out this is actually a Node.js application.  Visual Studio Code is now open-source, and you can go and look at it.  It's an electron JS application similar to GitHub's Atom editor.  And so Microsoft, again, showing that they are embracing the larger open-source community  and using tools that are outside of the Microsoft normal ecosystem.  Very interesting.  So they're calling it a code assistance, but it does have really good debugging tools.  So the kind of debugging experience I just showed you in Visual Studio, you can set break  points, and you can have the locals, and you can set watch watches, and you can step through  your code, and you can inspect variables.  You can do all those same kind of things.  You can do it in this really lightweight editor that makes it really easy to create.  Now, I'll talk to you about, let's talk about a typical workflow of building a Node.js application.  The two command lines you get is Node and NPM, NPM being the package manager.  So if you're creating a new brand new Node.js project outside of Visual Studio, you'll probably  want to start with the command line and use NPM init to initialize this special file called  a package.json.  The package.json is a kind of a manifest for your application.  It lists things like the author and the version number of the application and any dependencies  that your application has.  So it's kind of both your manifest and your package, NuGet package list, if you will.  So after you do NPM init and initialize your package.json file, then you'll start installing  dependencies that you have, like NPM install load-.  Load- is being a very popular functional utility library that may have been using in your client  side applications.  There's a lot of client side libraries that you can also use on the server side.  And the dash-save is important because that's what it instructs NPM to save that entry into  your package.json file.  So when you go to distribute your application, install it on another platform for, you know,  in production, it can read that package.json file and know what dependencies it needs to  download and install.  A typical Node.js application looks like this.  You'll see at the top of the file some things like require statements.  And these are similar to in.NET to the using statements.  So this is how you import in your modules and reference those in your Node.js application.  So there's two forms of require.  One is require that just is the name of the module.  And that's for built-in Node.js modules, like FS is the file system module for doing  file I.O. and express would be something that you would pull down from NPM.  In your own application, as you create your own modules, then you reference those by a  relative path like slash app slash my service.  And in some cases, you may need those, most of the time when you reference a package or  a module in Node.js, it's not only creating a reference to it, but you're creating an  instance of it.  And you can use it right away.  But there are some modules that require you to initialize kind of like using, you know,  a constructor function.  So in this case, my service is a constructor function that takes in a number of parameters  to initialize that module, an instance of that module.  And then the typical callback pattern that you'll see in Node.js is this.  You'll have some method and you'll pass either one or more parameters or zero parameters  as far as like arguments to that method.  And then the next thing is a callback function.  A callback function is a callback.  It means when you're done executing this method, let me know the results of that and send it  to this function.  So the callback is like, it's kind of like an async and wait pattern.  This is how it's able to do a lot of concurrency on that single thread event loop.  You're not blocking on that method.  You're saying, go do this work and when you're done, let me know.  And the typical pattern is the first parameter returned on a callback is always the error  object.  You want to inspect that error object to see if that method did raise any errors.  It can throw exceptions as well, so you need to watch for those kinds of things.  But typically, instead of throwing errors, it's just going to pass error information  through that error object.  And then your results and there may be other parameters that are returned back from the  method that you're calling.  Creating your own modules, there's a couple of different ways when you're creating your  own modules that you want to do this.  Here's an example of a module I'm creating that has some utility functions in it.  One is convert to Celsius and convert to Fahrenheit and then I've got some values.  In JavaScript, you can create objects.  It's a dynamic language and you can create your own objects on the fly just by saying  like this plain old JSON here.  I'm just saying it's got these properties, freezing Celsius, freezing Fahrenheit, boiling.  These are just properties on that object.  The interesting thing is this guy down here, module.exports.  That's the secret sauce right there.  So when you're declaring your own modules, you're exposing whatever properties and methods  you want to the rest of the world through that module.exports.  I can control, I'm exporting this object and this object has properties and a couple of  methods.  So when I require this module in somewhere else, I'm going to have the ability to call  these two methods and to access these properties.  Another typical module pattern that you'll see is a constructor function.  So in here, I've got a config module that I'm declaring.  I'm also requiring in the file system and I'm reading some config data and I've got  some properties on getting and setting configuration information.  The interesting thing is the return statement.  These are my methods that I have and I have this one here called internal function.  When I return from that constructor, that JavaScript constructor function, I'm only returning  get, set and save.  I'm not returning internal function so that's kind of like a private member of that module.  I can still use it inside that module but it won't be exposed to the rest of the world  and of course I've got module.exports and that function.  I get asked a lot about SQL databases.  About how do you access SQL server or some other relational database from Node.js.  There are a number of modules that are available.  Their MS SQL is the most popular.  My favorite is called seriate.  It's actually a module that sits a little bit higher than MS SQL.  It has MS SQL as an appendix.  But it provides a lot of nice features that are a little bit opinionated but I think it  turns it into more of a micro-ORM.  If you're familiar with something like dapper as being a really, really lightweight micro-ORM,  you might think of this as an equivalent.  Seriate allows you to, once you install it and require it in, you can set your configuration  information.  Your configuration information typically comes from environment variables.  So instead of having like a config file like you have in.NET, you will have environment  variables and that way when you go to deploy your application, like in Azure, there are  places to set those environment variables and you can do it that way.  But here we're just passing those values in on the default config and then I can do things  like execute a query and this can be not only just inline SQL but it can be a stored  procedure.  It can be a reference to a SQL file that has all the SQL in it.  It supports parameters and input, output parameters, all the things you would expect.  And then this is an example of promises.  So instead of a callback function, you're saying go execute this application or this  method and when you're done, then call this promise, this then module function.  The interesting thing about seriate is that you can chain, because it's promises, you  can chain these together.  You can say execute this SQL, then pass the results of that statement to this next SQL  statement and you can chain SQL statements together, which is a typical workflow for  building a data-centric application.  You're typically having to go and retrieve results here and based on those results, go  retrieve another set of results, that kind of thing.  So any questions about the code that we've seen so far?  All right.  Good.  So deploying Node.js is really, really easy.  Usually you don't include the Node.modules folder.  What I'm talking about there is when you install an NPM package, you do NPM installed and something  like load-dash, those things get added to a special folder named Node underscore modules.  And like I said before, those can be compiled sometimes if they include C code to your particular  architecture.  So if you're developing on one platform, if you're developing on a Mac or a Windows 32-bit  architecture and you're deploying to a 64-bit architecture kind of thing, then you don't  need to include this Node.modules folder.  Everything you need to run in production is going to be listed in your package JSON file.  And so when you deploy your application, you're just going to run NPM install without any  parameters and it's going to read your package JSON and install all those dependencies for  you.  Alternatively, if you do know your specific build targets or your platforms that you're  deploying to, you could set up a CI server that is the exact same architecture as your  production servers and do your builds there and then package everything up into a zip  file or something to move to your production environment.  Building for Azure, deploying to Azure is really easy.  As I've mentioned before, Node.js is a first-class citizen in Azure and they have a number of  templates available for you to get started, some either starter web application or VMs.  If you're deploying to Windows, regardless of if it's Azure or your own VMs or own hardware,  there's a couple of options you need to be aware of.  One is IIS Node.  This is a way of hosting.  If you're just deploying a web application, you probably want to use IIS Node.  This allows you to run a Node.js application through IIS and IIS makes it efficiently,  depending on, say, your server has four cores, it can spin up four copies of Node.js so that  you're taking advantage of the cores that are on that server.  It handles hands-off each request to kind of an around-robin fashion to whichever instance  of Node.js is available.  That allows you to scale easily on a single box.  Windsor, if you're developing like a microservices architecture or you're creating just a service,  maybe it's a worker service that's listening to a queue that's doing some commands or doing  some work for a distributed application, then Windsor is probably something you want to  use.  It makes your Node.js application look like a native Windows service that you can pause  and start, restart, stop, those kinds of things.  It will make sure that your application remains running.  If it does crash, it will automatically restart your application, typical Windows service  behavior.  On Linux, if you're deploying to Linux, you probably want to use something like forever,  which does the same kind of thing.  It ensures that your application is always running, if it crashes, it will restart it,  so forth.  I already mentioned on Azure, you can create an empty Node.js website.  You can do things like connect to a repository.  This is what I do for my own blog.  My blog is a Node.js application, and it's hosted on GitHub.  Anytime I make a push a change to my Node.js repository, Azure instantly gets that notification  and will download the latest version from the repository and redeploy it.  I can get a fresh new version of my blog pushed in less than a minute.  There's a lot of folks that do this same kind of deployment.  Here it doesn't have to be GitHub, it can be Visual Studio Online or what they're calling  it now, Visual Studio Team Services, and a number of other repositories that you can  connect to.  I've got an article out on my website, Reverend Geek, hosting Node.js on Microsoft Azure,  and I go through some of the steps of both doing a repository-based approach or setting  up your own VM and using something like Windsor or hosting using IIS nodes.  I go through all those options in detail, and it's really easy to do.  Recommended toolbox.  In my experience and with the guys that I've worked with, this is what we found to be some  really useful modules, Low-dash being just general functional utilities that you're probably  already aware of, similar to underscore.  Then is a Promise library and makes it really easy to, callbacks can get, start to get really  hairy with callbacks that have callbacks that have callbacks.  Promises is a much more cleaner way of having that kind of asynchronous pattern and just  having chainable calls of then, then, then, and then when you're finished.  Make for parallel asynchronous and parallel execution, so maybe you have five tasks that  you need to run and then let me know when all five of those are finished.  You can think of as kind of like the task parallel library in.NET where you can do  things like execute lots of things, either in parallel or serial, and be notified when  those things are finished.  Rest or rest, those are really good HTTP clients.  So if you're depending on other web services in your application, you're creating a mashup  and you want to be able to call into other web services or maybe you have web services  already in your environment that you have dependencies on, this makes it really easy.  Gulp and then there are a number of others.  You've probably heard of Grunt and lots of other build systems, but we use Gulp.  It's great as a build engine and test runner.  Socket I.O. for sockets in real time.  Node Inspector, so if you want to dive head first into the world of Node.js, you may want  to use something like Adam or Sublime Text or even Visual Studio Code and break ties with  big, big IDEs.  It's really an awesome development experience just having lightweight editors for JavaScript.  Node Inspector allows you to launch your Node applications with Chrome, the Chrome debug  tools.  So you get a great, if you're already familiar with the Chrome debug experience of being able  to set break points and step through your code and look at all your variables and so  forth, you can do the same thing with your Node.js applications using Node Inspector.  This is what I use all the time.  I develop my applications in Sublime Text and I launch them with Node debug and I'm  able to use Chrome as my debugging tool and it's really awesome.  Mocha, Chai, and Cyanon, those are really good testing frameworks.  So if you want to see what it's all about in the TDD or BDD world for Node.js, those  are the tools to use and really, really less friction as I mentioned before.  It's so much easier to build and maintain a TDD or BDD's first approach in Node.js because  of the nature of JavaScript.  There are a number of popular frameworks that we talked about Express.  There are things like HAPI and Meteor and Sales.  HAPI is the web server open source community around Walmart.  Walmart created, originally called this under the Walmart Labs.  HAPI has grown.  They've got tons and tons of other modules and support features that you can bolt on  and it's a really, really impressive framework.  There's a couple of books out on HAPI now.  If you're building just straight APIs, HAPI is great too, but there's also ones that  are some frameworks that are specific to APIs.  Restify, Loopback, which is from Strongloop, which is now part of IBM.  Loopback does things out of the box like push notifications for mobile applications.  So it's a great platform for doing mobile apps.  Auto host and hyped, those are good clients if you want to do a hyper media approach to  APIs, if you want to support the hyper media documents with links and so forth, that platform  makes it really easy.  A couple other resources, if you go to nodeframework.com or nodewebmodules.com, that's kind of a  curated list of the most popular frameworks for doing web applications and NBC style applications.  Another thing I want to tell you about is EdgeJS.  If you are a.NET developer, this may be of interest to you.  EdgeJS is a bridge between.NET and NodeJS.  It allows you to run.NET code in process with your NodeJS application.  So you can create a NodeJS application and reference your.NET code and take advantage  of those libraries that you may already have.  And it's not just C sharp code, you can take advantage of F sharp or Python or PowerShell,  anything that you can execute in a.NET world.  You can reference, you can do inline code or you can reference CS files or assemblies.  And it's a great alternative, as I mentioned before, typically you find either pure JavaScript  or a mixture of JavaScript and C modules.  And if you're needing to create something that's outside of what you may want to do  with JavaScript or you really need to do some CPU intensive work that requires multi-threading, .NET EdgeJS could allow you to build that kind of solution instead of having to write  it in C. It does require.NET 4.5 or Mono 3.1 and above.  The reason for that dependency is you need to have async and await support.  If you don't have async and await, then you're going to be blocking that main thread.  And so you need to be able to play well in the single-threaded event loop model that  Node.js has.  SJS can work both ways, so you can also use SJS inside your.NET application to call  into Node.js.  So if there's something in Node.js that's really awesome that you just want to add that  functionality into your.NET program, you can do that.  So what can you do with it?  You can leverage existing.NET investment.  You can access, so there are modules available in Node.js for things like TFS and SharePoint  Exchange, but typically they are half-baked.  Maybe they're not well-supported.  The Microsoft stack doesn't get quite as much love in the Node.js community as most  other open-source tools do.  So open-source is always the number one thing that the Node.js community wants to focus  on.  So if you do find a module for some Microsoft technology in Node.js, it's typically not  fully featured.  Even the SQL module that Microsoft created never got out of alpha and would not use that  in production.  So Active Directory, maybe you want to access local hardware from Node.js, maybe you want  to automate some things, use a 3D printer from your Node.js application.  I can't really think of a scenario why you would want to do that, but it does open up  those kinds of possibilities.  And again, if you're doing really CPU-intensive work that is not well-suited for JavaScript  and the single-threaded event loop model, you could offload some of that work to a.NET  module.  And PowerShell, that opens up some interesting scenarios from a DevOps perspective.  So let's talk about some Node.js integration strategies.  Now you could use Node.js as a proxy.  This is how a lot of companies have introduced Node.js in their organization.  So PayPal, Walmart, and my company, a number of other companies, we've introduced Node.js  as a proxy service.  It's just a middleware layer.  So incoming requests come in, they hit Node.js first, Node.js can, in that proxy scenario,  can decide, well, is this something we want to handle?  Can we handle this request natively using Node.js, or do we need to hand that off to  some other back-end service in.NET or Java or whatever system we were using before?  You could use something like SJS to access.NET code.  You could use the request module or REST module to be able to call into other APIs in your  architecture, in your infrastructure.  And then there's things like messaging.  So the clients that are available in Node.js for RabbitMQ and Azure and a number of other  message buses are really, really powerful, really great.  This is the approach that we're taking with being able to distribute the load of computing  across our different, you know, either.NET or Node.js modules or applications and services.  And it works really well.  And the one more thing I want to tell you about is this awesome thing called Electron.  I give a talk on this, I've given a talk on this at a number of other conferences.  Electron is the desktop shell that Atom and Visual Studio code and even applications like  Slack.  So if you use Slack, the desktop client, you're using a Node.js, HTML and CSS application,  and you wouldn't even know it.  It's a web application.  And Electron is now an open source, and you can use it to build your own cross-platform  desktop applications.  I've created a number of tools for our customers that now I don't have to worry about, you  know, I'm a.NET developer, so I was kind of forced to use the.NET, you know, I was  building solutions that I would hand off to clients and my clients would say, well, we  don't even use Windows here.  I'm like, oh, well, let me see what I can do.  So I went back and tried to use Xamarin Mac to create a Mac version of my tools, and to  be honest, the Xamarin Mac is not, it doesn't get nearly the amount of love that the iOS  and Android tools get.  So it's much harder to create a desktop app using.NET than it is to use something like  Node.js and Electron.  And the last thing I want to tell you is you don't need permission to be awesome.  So we as developers, I truly believe we are in a unique position, a unique set of skills,  and we have opportunities that we can change our environment and our world in significant  ways.  And so the things that you're learning here at this conference, please take those back  and change your world.  With that, I'd like to thank you again for coming to my talk.  Here's some contact information and resources that you can get on my GitHub repo.  I've got some Node.js demos and a list of everything that's in the, I've got these slides  as well as a list of all kinds of resources.  And if there are any questions, we've got a microphone here.  Be glad to answer for the next few minutes.  Well, for the recording purposes.  You mentioned Electron as cross platform.  Does that cover mobile or just desktop application?  It's just for desktop, so you can think of it as the phone gap, Cordova equivalent.  So Electron does allow you to leverage a lot of your existing JavaScript and HTML code  that you may have created already for your web app or for a mobile app.  So if you're doing a hybrid mobile application, you could probably use the same, a lot of  the same JavaScript and HTML that you've used in those cases and be able to create a desktop  version.  But as of now, Electron is just for Mac, Windows, and Linux desktops.  Now I think there are some interesting scenarios that will probably happen down the road with,  I know I mentioned Microsoft has done work to enable Chakra as a alternative JavaScript  engine and that opens up a lot of possibilities.  That may open up some possibilities of going mobile with Node.js.  It's a possibility.  Yep.  Is there any package that's like link that you can use to include?  I'm sorry?  Like link?  Like?  Oh, uh...  So, I'm not so sure.  I'm not so sure.  I'm not so sure.  But I would be really surprised or shocked to find that there weren't some type of expression  language like that for Node.js.  So I don't...  Sorry, I don't have a direct answer for you, but I would...  If I can search NPM later and we can find that answer.  Yes?  It's a question about IIS Node and Edge.  They seem like good ideas, but are they ready for production?  Have you used them in your deployments and how has the experience been?  So we have never used SJS in production at my company, but I know that SJS has been used  in production in a number of other companies.  And if you're targeting the Windows platform, deployment is pretty easy because you already  have the.NET framework available for SJS.  There's not really any additional work to be done.  IIS Node production systems running?  Yes.  Yeah, it's really easy to get IIS Node.  And if you deploy to Azure, IIS Node is the mechanism for which you are deploying your  Node.js applications.  Microsoft uses IIS Node to host your Node.js application and to make it available as a  web application.  Anyone else?  All right.  Thank you very much.  Don't forget the giveaway stuff up here.  Thank you.  Thank you.  Thank you.
Node_0_2711.png Node_2712_3707.png Node_3708_4331.png Node_4332_4595.png Node_4596_5327.png Node_5328_12947.png Node_12948_13907.png Node_13908_14063.png Node_14064_14195.png Node_14196_14519.png Node_14520_15359.png Node_15360_17399.png Node_17400_18227.png Node_18228_18779.png Node_18780_20267.png Node_20268_21263.png Node_21264_21851.png Node_21852_22931.png Node_22932_23675.png Node_23676_25415.png Node_25416_26003.png Node_26004_26927.png Node_26928_27755.png Node_27756_29951.png Node_29952_30875.png Node_30876_31247.png Node_31248_31931.png Node_31932_32207.png Node_32208_33539.png Node_33540_35171.png Node_35172_35399.png Node_35400_35519.png Node_35520_35807.png Node_35808_35939.png Node_35940_37307.png Node_37308_37391.png Node_37392_39215.png Node_39216_39563.png Node_39564_39635.png Node_39636_39695.png Node_39696_39899.png Node_39900_40499.png Node_40500_40679.png Node_40680_40763.png Node_40764_40847.png Node_40848_41531.png Node_41532_41615.png Node_41616_41675.png Node_41676_41747.png Node_41748_42587.png Node_42588_42731.png Node_42732_42791.png Node_42792_42839.png Node_42840_45191.png Node_45192_45347.png Node_45348_45743.png Node_45744_45815.png Node_45816_46139.png Node_46140_46343.png Node_46344_47687.png Node_47688_49847.png Node_49848_51959.png Node_51960_53039.png Node_53040_53183.png Node_53184_53255.png Node_53256_54095.png Node_54096_55595.png Node_55596_57767.png Node_57768_59699.png Node_59700_59807.png Node_59808_59987.png Node_59988_60563.png Node_60564_60719.png Node_60720_65531.png Node_65532_65579.png Node_65580_66407.png Node_66408_67199.png Node_67200_67511.png Node_67512_72911.png Node_72912_78539.png Node_78540_80891.png Node_80892_83075.png Node_83076_84395.png Node_84396_85391.png Node_85392_86159.png Node_86160_86363.png Node_86364_92433.png