 Right, I've got to 20. Let's go ahead and get started. Thanks everybody for showing up. I hope you're enjoying the Conference so far. I hope you're not as jet lagged as I am. It's a bit of a journey from from the US So this is getting started with with Node.js and this really is a beginner Introduction doesn't really assume that you have any existing knowledge of Node.js Maybe a little bit of JavaScript would be helpful, but we're not going to get into too much complex code We're mostly going to kind of focus on the architecture and show sort of what it takes to get started right now using Node.js So who is this nerd? I'm Justin Riok. I'm the chief architect at Rogue Wave Software. I focus mostly on our emerging open-source technologies that we like to focus on as a company we provide Services and support for community additions of open-source packages. So we do not Branch we do not proprietorize we allow you to get the software from the community and we can provide you with support In fact this presentation comes out of a three-day Comprehensive training that we do on Node.js So please feel free to get in touch with me if you're at all Interested in anything like that and I promise that is the last sales pitch you will hear from me So what are we going to solve today? Hold on. No, just kidding Nobody likes the spinning wheel of doom or the spinning wheel of hope So we're going to talk about how we can use asynchronous processing to be able to return requests back to our users faster And node is inherently asynchronous and for anybody who hasn't worked in a language that is inherently asynchronous It's it's difficult. It's going to be a bit of a shift in the way that you think about the way that you're writing your code But this really is ideal for the way that things are done now, right? We're living in a world of distributed computing more's law is no longer being maintained by clock speeds, right? We're not seeing huge increases in clock speeds We are seeing major increases in the number of cores that we can shove into a system And we've taken that a step further and abstracted it all out and now we're looking at microservices Running in parallel inside of containers. Maybe we're spawning 5,000 replicas of a small Machine learning process to spin up for 20 seconds and read some data and spin back down And when we're doing all of that work in parallel We really need a way to Distribute that code and make that code very atomic Anybody who is familiar with the concept of a 12-factor app Probably if you're working with containers, you're starting to learn some of those fundamentals Node is actually an ideal language for doing something like this because it is inherently asynchronous and it's very small and very lightweight And is built on the industry standards and it's been vetted against thousands of production systems It's an extremely popular language right now So what else are we going to solve? this is probably the more valuable part of Working with Node.js. So in the past, this is what a development Processor team would look like right. We'll have back-end servers These are exposing data or services to front-end applications or front-end servers, right? And maybe we're writing these front-end apps in HTML and JavaScript and CSS And so we have our UI developers who are familiar with JavaScript who are writing this part of the code Meanwhile, we have another silo right our back-end servers. These are our back-end APIs and Back-end systems and maybe these are getting coded in PHP or Pearl or Java, right? So this should look pretty familiar for anybody who's done any type of development over the last say 15 years But now we can do this now we can have a DevOps team Only code in Node.js We have an app farm and our app is served up from both the back-end and the front-end using JavaScript using Node.js Okay, that's an important concept here, right? So people who have been good at doing JavaScript development for a while can now be more useful at doing back-end development We can do back-end and server-side development in JavaScript Which is very useful for the way that we're sort of converging our development teams these days So this allows us to code our front-end and our back-end using a single language, okay Which if you think about this in terms of agile methodologies and scrum It's a lot better when we're having a scrum meeting or something like that and The technical folks in that meeting are all capable of understanding and speaking the same language So a little bit of an overview of the language by the way stop me at any point if you have a question I'll do my best It was created by a guy named Ryan Dahl in 2009 and really was just created mostly to deal with these concurrency issues That we were talking about before right so when we start thinking about distributed compute and parallel compute We have to start rethinking the way that we write code We need that code to be useful when it's concurrent, right a single JavaScript process is Single-threaded by default right we we have one engine in this case the v8 chrome engine Which is our JavaScript interpreter and that is a single-threaded process, but as we'll see in a moment Ryan Dahl sort of famously over the weekend Built a layer between the v8 engine and the JavaScript interpreter and we'll see a picture of that in a minute But it's built on chromes v8 JavaScript engine So again, this is important when no JS does not use its own JavaScript engine, right? It uses an industry standard engine, but what it really does is layer Some tools in front of that engine that allow us to do concurrent coding and if that doesn't make sense right now Don't worry it will in a minute. We'll see a picture It is single-threaded asynchronous event driven We can achieve vertical scale by adding additional CPU cores and there are actually conventions within the language We're in just a couple of lines of code you can tell no JS to fork off a certain amount of Worker processes to match the number of available processors on the server in which the code is running so it can auto-scale to an environment again Very ideal for something like a container environment where we may not necessarily know the sizing of that environment And we can use JavaScript on the browser as well as in the server Which is going to minimize this mismatch between the environment So for instance, I can do all of my form validation in a single app as opposed to having to do form validation on the front end And then repeat that validation again on the back end There's a list of registered subscribers Which are basically just node processes And they are notified when their state changes Okay So you have a pub sub or a topic like pattern Happening between worker nodes and a master node and that master node is able to communicate down to the worker nodes and The worker nodes can communicate back up to the master using a topic kind of pub sub methodology We also have npm This used to be called the node package manager Now you're just supposed to pretend that the node doesn't stand for node anymore because this has become a general sort of JavaScript Module repository, but the vast majority of these modules are for node So anybody who's familiar with, you know, maybe pip in Python or cpan in Perl or new get in dotnet you already know what npm is It's just a package manager for installing dependencies for your node applications As of April of 2019 that number has doubled and there's no question now that npm is not only the fastest growing Module repository and dependency repository out there, but it's also the largest Compared even to things like maven central right here for Java, right? So any Java developers like myself who are using maven you're like, oh, there's a lot of modules in there Yeah, well npm has, you know, almost four times as many at this point and continuing to grow very quickly So just sort of a general overview here sort of pros and cons of using node on the good side of things It is very lightweight with an extremely low memory footprint It is a true cross-platform environment In that server and client side code can both be written in the same language as we talked about before It is very fast It's asynchronous nature allows it to be just about as efficient as it possibly can be It is very popular getting lots of popularity right now I think I think it has sort of the same appeal that a language like Perl had in the late 90s right this this this shared repository of well-written dependencies But it's just a little bit more advanced of a language right now But I think that's why it's catching fire the way it is there's already a lot of people who Understand JavaScript and so to make the transition to node is just not that difficult You need to learn a little bit more about the additional modules that you can use and note and learn a little bit about npm Get familiar with some subjects like semantic versioning and things like that But overall if you've done JavaScript development, it's pretty easy to make this transition It is full-stack web development and it's highly extensible Now on the bad side of things The v8 engine does have a 1.7 memory gigabyte memory limit, okay? That means that we have to have multiple v8 engines processing In parallel if we want to be able to use more than 1.7 Gigs of memory within our application and again, we can do that by taking advantage of nodes clustering functionality So this makes a vertical scaling challenge, but workarounds do exist Module versions can get a little bit confusing for the most part people are Conforming to semantic versioning which does make your life easier, but not necessarily Over open source governance is not flawless if anybody's familiar with the left pad debacle from a few years ago This was a really big deal. There was a module and node. It was like 18 lines of code It was a very small module and the purpose of that module was to install to insert spaces left tab spaces So that you could align text this thing was used all over the place all right tons and tons of apps were using this The maintainer got angry and pulled the module off of npm literally breaking the internet It's a very interesting story to read But a good reminder for everybody that you have to be careful about your use of open source You hide open source is the best thing in the world, but you have to govern it. You have to manage it You can't just go wild with it And definitely a learning curve for developers who maybe aren't used to dealing with a language that is inherently asynchronous again It's it's a different paradigm. It really feels different when you're coding You know you expect your code to just execute one line one line one line one line like you're used to with it with a Synchronous language, but in this case that's not happening at all Note is absolutely going to skip ahead in your code and execute things further down Even if it hasn't finished the asynchronous action that it had before we do have ways to make this a little bit easier We have like promises and closures and things like those patterns if you're used to that We now have a relatively new functionality that was introduced in ECMAScript 2016 I think called a sync await which allows us to pretend that our code is a little bit more iterative But but just again, you know be aware that's probably the biggest challenge for people who are just coming in to JavaScript And to know JS is wrapping their heads around this this sort of inherent asynchronous nature Here's a web-enabled hello world app So again, this is a this is a web enabled one we're actually creating a back-end web server here Okay, so as opposed to just you know printing something out to the command line or whatnot We're actually spinning up a lightweight web server that's called Just basically the HTTP module that that ships with node And that HTTP module allows us to create a small HTTP server respond to certain requests and then You know push what we want to and of course we tell it to listen on a particular point or report Okay, so this is interesting right this is JavaScript creating a back-end web server that can service requests All right, that's that's different. JavaScript is usually served up by a back-end server It's not usually the back-end server, but again that that's fundamentally what what's different about this Very high-level look at the architecture and what kind of makes this different and so I said before That that the creator of Node.js Ryan doll built this thing over the weekend Well, if you look at the architecture here, you can kind of see how that's possible right down here This is the v8 Chrome engine. This is the actual JavaScript interpreter This is not written by or maintained by the Node.js community This is the industry standard JavaScript interpreter, but what have we done here? We have had our we were asking our app To pass commands through the node engine. This is proprietary to Node.js We have some miscellaneous libraries that we might hit to access the operating system Okay, we've just fundamentally shifted here from what we're used to with JavaScript JavaScript's not supposed to be able to know anything about what's going on at the operating system level It's sandbox to the browser for security purposes, right? You wouldn't want somebody able to just access or just just run some Arbitrary JavaScript code on your laptop and give them access to your operating system But node of course has to do that because it's running on the back end So it has some special libraries specifically for accessing things about the operating system level Then we have this interesting thing here called LibUV LibUV is a very fast Event loop. It's an event loop that was created in C++ specifically for Node.js Now it is has found some use in some other applications as well. It's completely open source But this is the magic. This is what makes Node.js so different I'm passing commands asynchronously down into a an event loop that event loop is Asynchronously taking actions against the engine or against the operating system and returning things back to the application This is how I'm capable of having a distributed application that could actually spawn Multiple instances of the v8 engine to allow this to to allow the code to execute in parallel All right, so it is literally spawning off multiple Java node v8 processes on the server to go and Service a single JavaScript action Okay, so you're writing code and when it executes that action actually goes into its own isolated v8 Engine instance and execute so then return something so this does a couple of things for us Right, so first of all it makes it very easy for us to be concurrent in general as long as you can wrap your head around the Asynchronous semantics of the language you shouldn't even really have to think about this It just kind of works that way it also makes it inherently thread safe Okay, because v8 itself is single-threaded and because we're running these multiple JavaScript Actions inside of isolated separate v8 instances. They are running in their own thread. They are thread safe inherently Another way of looking at the same Architecture here's our app passing commands into v8. Here's the special node. J. S. Bindings And here's this event queue and it really just is a queue right? It's a loop Events come into the queue the red off the queue in a loop if we have a blocking operation like a database read or a file system read then Then this will block but that's okay because the next event queue can be sent out Into another instance of v8 and execute in parallel Okay, so this is where the magic happens, but if you look at This and this these two pieces here were just kind of we're just kind of stapled on to JavaScript And that's how Ryan doll was able to create no JS in a weekend, right? He didn't really write that much code he just kind of Put together some some libraries that made sense to work together So you know for the most popular programming language out there with the biggest number of dependencies and modules out of any Other language that's pretty impressive that he really is kind of crank the thing out over a weekend It's a very smart guy if you ever get a chance to meet him or talk with him He doesn't like conferences and he's not a big public speaker But he does attend some of them if you get a chance to hear him or speak with him I highly recommend it. He's a very smart guy Okay, so how do we actually get node going on your system well kind of depends on your operating system If you're dealing with Linux if we're using Linux, which you know, you probably should be Most of these open source technologies were built with Linux in mind and then maybe back ported to Like a like a like a Windows environment Mac is kind of the exception, right? We're running BSD. So it's it's Unixy enough It does run on Windows But you know why? There is an official Docker image as well And a standalone shell script installer so many many options to install it if you're in a Linux environment This is the easiest way to do it. It's usually just you know, yum install node.js or app get install node.js Once it's been installed we want to make sure that our Package manager package manager has been installed as well and we can validate that just by checking the version of each binary from the command line So here we are just saying no dash version Cranked out of old version and upgraded on my Mac and then we're seeing that MPM is installed as well And if that runs your code is gonna run because these tools are written in Node.js All right So let's do a quick node app. It's enough theory for the moment. We're just gonna do a super simple Console hello world app and we'll do it from scratch then we'll execute it on the command line So I'm just gonna set the mic down here for a second So a couple of things to note on this if you're reminded at all of Pearl Python any of these languages that feel almost like scripting languages because we can run them right from the command line without having to do a Build necessarily right you should be reminded of that because you can all right now If we have dependencies and things like that which most most of our more complex apps are gonna have then There is a build process using MPM But all that build process really does is download these modules which which don't have to be compiled All right, they're just being interpreted by the by the v8 engine All right So you get to just kind of just kind of start real quick without having to do a whole lot of planning Without having to worry about a bunch of build files and stuff and for the most part the The IDE is gonna do you know a lot of work for you so So we're gonna speed up just a little bit because I want to make sure we can get through all this content I really like VS code for no JS development. I really do Microsoft is surprising everybody right now This shirt says open source and it's a Microsoft The world's changing a little bit And and VS code is a great great little IDE totally free and open source and the preview edition cooler new functionality So you can do things like remotely develop via SSH on a remote server and stuff like that. It's pretty great Terminal integration is essential when you're building your node apps. In fact, you've done that demo I didn't even open an IDE right. I just went right right into VI and just just threw something out there The built-in debugger works flawlessly with no JS. It's really a nice experience. It just it just works And you do have other options though go with what's familiar and go with what's available and is not That's critical So we've all got our preferences when it comes to ID ease or maybe you're already familiar with something like Eclipse That's fine. There's there's no JS tooling for Eclipse. Maybe you prefer an online IDE it's something that's integrated already with Docker and maybe gives you a container environment Well, you have that too. Just want to make sure that you've met these basic criteria when you're picking this ID ID you really want the debugger obviously You want syntax highlighting you want it to support what's called ES lint For those that don't know JavaScript is not really JavaScript. It's the specific specification is actually called ECMA script or ECMA script And that's what that ES comes from so you want ES lint And if you ever use lint before to clean up your code or to check your code for syntax, it's basically what it's doing We want terminal integration. We want NPM integration. We want code completion with IntelliSense We want a beautifier. We do want Docker integration these days, you know It's just a lot easier to get started with with Docker We want node modules integration, which we'll look at in a minute and we want our source control integration Hopefully we're using git or something like that and we're not just you know saving our our program in a zip or something But you do have some other Options when you want to look at an IDE. This one is actually pretty cool. I have to say this cloud 9 IDE It's completely online And so it's kind of like it's kind of cloudy basically all your your code's gonna get sort of in the cloud But it does have to get integration and all that kind of stuff. You can push all your code out to your github live preview JetBrains if you like the IntelliJ experience if you're a Java developer JetBrains does produce one that's similar called WebStorm for Node.js Komodo and Then node clips if you like Eclipse then you can just get the Node.js plugins for Eclipse so plenty of options here I just really like VS code so we're gonna focus on that We have a bunch of VS code extensions for Node.js when we search for it up here You can see we've got our debug and really just a just a just a bunch of stuff And there's a whole lot of plugins for the various frameworks and Dependency libraries that we can use with nodes so things like view.js or angular.js or react There's a lot of tooling that's built in for that as well I have another talk on react which unfortunately didn't get accepted at this one But I will be giving that talk at the OSS summit in San Diego in August Start with at least no debug in the Node.js extension Going Take time to explore what's out there though In VS code we have a launch file that's specific to VS code All right, this has nothing to do with Node.js This is telling VS code how to launch our app, but this is essential if we want to be able to debug our app, okay? The launch configuration is controlled through a JSON file called launch.json So launches and it basically just describes the environment bootstrap information for the app If I want to set some environment variables maybe This is where I would do that But it is essential for debugging because your app is going to get more complex You're going to need some stuff set up in your environment before you can run your app like an environment variable or what not Maybe you're using OAuth and you need a client key. I don't know you're just you're going to be storing stuff in an environment variable And it won't launch properly without that environment variable being set So you need to tell VS code what the environment should look like and you do that in this launch.json file So let's take a quick look at the debugger I can get coordinated here. Okay, so We'll start I'm setting breakpoints just like I normally would in any IDE We'll go ahead and set two one at the very beginning Even though it's kind of useless and then one afterwards so that we can check and introspect the contents of our variable Okay, when you get started with node, you're going to spend a lot of time in here All right in in this debugger because it's very easy to look at the way that the node.js object notation works It's very easy to kind of see how functions like every object is actually treated like a function Functions our first-class citizens in node.js so I can pass them and I can set them and and all that get more into that I have an advanced talk on this So let's just run this. Let's look at our launch configuration. Okay So we stopped at our first breakpoint and we can already see that we've got some useful stuff in here and I Realized that's kind of hard to see. Let me so I'm not going to go into the contents of all of this right now but I do Kind of recommend you poke around in here because you're going to get to learn a lot about what nodes actually doing in the background For you, but we can see that we have to find our constant. It just hasn't been set yet currently undefined so let's move to our next breakpoint and Great, we can see that our variable has actually been populated at this point. We could introspect it We can set a watch point on it really anything that you'd expect to be able to do in a debugger. We can do here So we've seen just a quick hello world that you can get started with very easily And now we've had a little preview of what we can do in terms of our developer our debugger In our ID So this is the basic lifecycle of a node app We're going to create and clone an SCM repo. Hopefully again, hopefully we're using source control like good people, right? But if not, you can just create a folder If you're going to use get you know set up your ignore files and whatnot you want to initialize the project This is the best practice. I haven't done that yet. The very last demo shows that but npm and knit will set up File called package.json that we're about to see and that's like your build file That's where all your dependency information is housed as well as some meta information about the app itself NPM and it will set that up for you automatically and a lot of IDE plug-ins and extensions will do that, too Then you just get to it start coding commit as normal and then build so in our target production environment We're going to run this npm install that's going to download in all of our necessary dependencies when we see our package .json file in a minute This npm install will actually go out to the npm repository pull all the modules down Which is effectively the build process for node because again, we're not compiling anything That's this is what the npm and it kind of looks like So you see it's going to prompt you for some information Things like a git repo author your license which should always be gpl3 and then It's going to generate your package.json file based on that. We just talked through all this Yes Okay So now let's turn this into a proper node application or what we should really be calling a node module even large node Applications are still considered a node module, right? This just comes with your node tooling right if you've installed node You should have the npm tooling as well that I have this script in there I'm just going to kind of leave all this blank But this right here is the package.json file. All right, so let's say it's okay. Yes when we cat it out Then this is what we have now In just a minute, I'm going to kind of rush through a little bit because I want to see I want to show you the very last part Which is working with external modules and npm But all of that dependency data is held in that package.json file Which again looks like this So our our apps can use dependencies or modules remember everything in node.js is a module technically Most open-source languages these days are going to have a set of modules that can be added to a project node is no different You can also create your own modules whether privately or freely available And the npm repositories would actually provide these and it could be used to add dependencies to a project by again Using this npm install command, but it's not npm install blank like doing the whole build like we saw a second ago This is actually installing a particular module. So let's see what that looks like So let's add a little color to our app There's a module for node just called colors and it's for doing colors like what ANSI ANSI generated color codes in the terminal You want it to be readable and even fun and as you start working with more and more node.js apps on the command line You'll find that people actually do care about this like they're putting cool little utf icons and stuff in their code and putting colors in and everything If we run npm dash dash save that will actually make sure this module is saved to package.json So that when we distribute it to our production environment and we run npm install those modules will be downloaded into our environment So here we're just saying npm install dash dash save colors and then in our code We can now require the colors module And now we can use this syntax to make something like red and underlined So let's take a look at that Real fast and then we'll wrap it up NPM Notice all the pretty colors Okay. Now. What did that do? We've got our package.json file and now we have this new folder called node modules as well And this is unsurprisingly where our modules just downloaded to so if we do a quick ls in here We can see that the colors module downloaded and if we pick this up. It's just another node.js module It's just written in node If we look at our package.json file We can see that we now have a dependency section in here and it automatically picked a version for me And I can use semantic version and syntax here if I want to enforce some stuff And then at this point if we run npm install even if we don't have that not node modules folder It'll go and download that module for us again All right, so we just imported a dependency and use the module and that Actually wraps us up. So what did we learn today? We learned that you should carry your clicker with you when you leave podium No.js is a language that focuses on concurrency and unified development under a single language Dependencies are assisted through the node package manager, which is no longer called the node package manager It is asynchronous by default a lot of IDEs exist You should initialize your projects using npm init you can install modules with npm install They're built from package.json when we install in a production environment and they're included in variables using the require command But there's still a lot to learn so Go learn about understanding asynchronous coding. It just takes practice Get to know the events and streams inside of node learn about functional programming. This is very much functional programming Master ID is debugger and start exploring other modules and finally feel free to reach out to me I do get lonely and You I promise you I will accept your LinkedIn or Twitter or any of that I do get a little political on Twitter though, so if you're easily offended by hippie politics, then maybe don't go there That's it. Thanks