You Don't Know Node.js
Mardan, Azat
This talk will give a sneak peak of the most interesting and powerful Node.js features. Node.js is quickly capturing the programming world not just in web, but in IoT, drones, robots and embedded systems. Do you use Node tool such as Grunt, Gulp or Webpack to built your front-end assets. Do you use an HTTP server built with Express? Do you generate code using Yeoman? But do you really know Node? If you are a geek like most of us, then you’d appreciate this presentation. You’ll become more confident in the internals of Node.js and understand how certain things work. Node.js is fast and scalable web-oriented non-blocking I/O built on top of Google Chrome V8 engine. Almost every web developer uses Node or Node-based tools to some extent. However, Node has some really powerful features worth knowing. This talk dives deep into the core mechanisms of the Node.js platform and some of its most interesting features such as: Event Loop: Brush-up on the core concept which enables the non-blocking I/O Streams and buffers: Effective way to work with data Process and global: How to access more info Event emitters: Crash course in the event-based pattern Clusters: Fork processes like a pro AsyncWrap, Domain and uncaughtException: Handling async errors C++ addons: Contributing to the core and writing your own C++ addons
 Hello. Hello, everyone. Welcome to the Node.js presentation. You don't know Node. We will go over five core features. It's not going to be about a fancy framework, cutting edge advanced stuff like promises or anything like that. It's going to be about the core fundamental, the basics. So even if you work with Node.js, some build tools for friend development, you might not know about these core features. So let's get started. And this is a hands-on presentation. So I want you to take out your laptops, download the code. I have it on GitHub, the code and the slides and the PDFs, and follow the demos that I will be showing you on your computers. And turn off all the IMs and slacks and notifications. They're doing really well there. Maybe we can beat them in terms of making sounds later. Can I have some little bit more volume in my mind? Thank you. So take a picture, get the slides and follow me with the code examples. So first of all, I want to remind you why we're here, why we're coming to this type of conferences and why we're doing software. So I want to put this big statement. We write software, we write apps to make our lives and life of other people better, basically, because software changes lives. Software is pretty much everywhere. So is that my computer? Did you have a different adapter? Oh, the different, the power. Do you know where is it? Oh, okay. That would make sense. Yeah. No. 40. Let me try to mirror. This is all summing up. No, too unworth. It used to be good, right? Let me try. Yeah, it's all like that. You can try another cable, but it's so strange because now it's because it's perfect. The picture is good down there. It was completely stable in the time there. But then, on the slide number 3, the picture started to fly on the project. So, it's stable. What? The fuck? Yeah, this is stable. But this, I don't have a picture now. Yeah, it's stable. Yeah, it's stable. So, that's actually perfect because you have time to download the slides. Yeah, it's stable. Yeah, it's stable. Yeah, it was there. Now it's there. 50. Thank you. Okay, so, start over again. Welcome to YouDon'tKnowNotJS. This is a hands-on presentation. And in case you missed it the first time, this is the repository where you can get the slides and the code. So, this presentation will have a lot of code examples. I want you to have the code so you can later refer to it. So, we're building software and we're trying to use better technologies, better frameworks to improve the lives, improve the community, the lives of our loved ones, the lives in general of other people, right? Software is becoming everywhere. And with this big kind of a goal, I will introduce myself. I published and wrote 12 books, not counting Chinese, Korean, and Russian translations. The most popular ones are Practical Node.js and ProExpress.js. You might have seen them on Amazon.com. They were on the first page if you search for Node.js. My new book, React Quickly, it's coming in a few months. That will be about React.js. You can follow me on Twitter at azad underscore co. I tweet about JavaScript and Node.js mostly. And I also have a blog. And if you have questions after this conference, you can reach me at my email. Hi, at azad.co. I work at Capital One. It's one of the US top 10 banks in the financial industry. I'll talk about it more in the next slide. Before that, I worked at startups, US federal government agencies. I would like to highlight my experience with DocuSign and StoryFi. That's where I got to use Node.js at a pretty relatively large scale. And I saw from my own eyes that Node.js is, how Node.js is beneficial in terms of having a generalistic approach and in terms of performance and having a better developmental experience. They also teach at Nodeprogram.com, where you can find live in-person trainings in Node.js as well as online trainings. So Capital One, it's in the top 10 US banks. We're also in the UK and Canada. And in US, we're famous for our Visigoth commercials, but most people think it's Vikings. Some of them are funny. So why use Node.js? So let's start with basics, right? I want to give you some ammo. So when you go to your work on Monday next week, you have something to tell your coworkers and your team leads in order to convince them, hey, maybe we should use Node.js for our next project. So the biggest selling point of Node.js is its performance. So basically, it's faster. And it's faster because it optimizes the input and output bound processes. So most of the times, input and output is the most expensive tasks that we have compared to CPU bound tasks. So if we can optimize for them, that will give us a good boost in performance. So Node.js has this thing, it's called non-blocking I.O. How many of you already familiar with this term? Raise your hand. OK, so like half of the audience. So for the rest of the half, this will be beneficial. So non-blocking, this diagram shows you high level overview how it's implemented in Node.js. So we have the thing it's called Event Loop. Event Loop, it's always looking for something to execute. So basically, it's never blocked or almost never blocked. And it allows our system, our Node.js-based system to process multiple requests pretty much in parallel, pretty much at the same time. And then Event Loop delegates those tasks, those heavy input-output tasks, like reading from a file system or writing to a database, or the most popular thing that we like to do when we're building web apps is to make HTTP requests to APIs or third-party services. So those all time-consuming tasks, Event Loop delegates them. Let's go a little bit more low level. This is Java code. How many of you Java developers here? OK, just about 20%, not that many. Most of the time I'm teaching Node.js to Java developers. But you can guess what this means, right? Thread.sleep, it's putting the entire process to sleep. So nothing will happen on this particular thread unless the timer expires, right? So the entire thing will be basically useless. OK, we will see step one, step two, and then step three. Contrast that code with this Node.js. So now we have fancy callbacks. So set time out, it takes a callback, which is a function definition. It's anonymous function definition. It doesn't have a name. And basically tells, OK, schedule that in the future. Don't execute it now. And the future will happen at one second, so 1,000 milliseconds. But the good thing about this code and this Node.js implementation is that set timeout is not blocking. So Node.js, this process will continue to execute. So we will see step one, step two, and then after one second we will see step three. OK, and then if we have more code, Node.js will still continue to execute that. So the result of this would be step one, step two, and then step four, not step three. And then after one second we will see step three and step five. So if you're familiar with how callbacks, Dread, jQuery, or promises in Angular framework works on the browser, this is a very similar approach basically. We're scheduling something in the future. But the benefit is that our process is not blocked. We can process a lot of requests. So putting processes to sleep, that's not very useful. Most of the time we are using, we're building web services. But that analogy, set timeout, that's exactly how Node.js is implementing a synchronous input output. So it could be writing to the database or it could be making a request. Let's take a look at this diagram. So this is a blocking system, maybe written in Python or Java. And we have four clients. Please take this, it must be important. We have four clients, they submit requests. So the client at the bottom, he or she, have three requests. But each request is blocked by the previous request, because it's hitting that one thread. Compare it to standing in line for a coffee. We have that pretty cool Twilio booth downstairs at the expo. I saw a lot of people standing in line, 20 people, maybe 10, 20 people during the breaks. So that's your typical blocking system, because you have to wait for the people in front of you to order your drink and to get your drink. In Node.js we have a non-blocking system. This is a diagram, again we have that event loop, which is delegating the processes. And event loop is always available, or almost always available. Compare that to the same Twilio booth with a coffee bar, but they have that option where you can text, or Facebook your drink, and then you can walk around, talk with other people, and they will text you back when the drink is ready. So this is much more enjoyable experience than waiting in line, and not able to do other things. So the texting to get your coffee, that's non-blocking, that's asynchronous. That's what we usually want. This quote is from CordingHorror.com, it's a pretty famous blog. I would recommend subscribing to it. So basically the blocking system, they have to be multi-threaded, because each thread is blocked, but multi-threading could be very dangerous if you don't know how to use it. You can get racing conditions, you need to know how to synchronize the data between multiple threads. You might have deadlocks, etc. It can really blow in your face. And yeah, blocking system, they have to be multi-threaded. So Node.js, by design, the designers of Node.js, the original creators, they decided, we're not going to create multiple threads, we just have single thread. And this is actually a beautiful thing, because with a single thread, you can avoid all that complexity and work in a pure asynchronous and non-blocking environment. And that's one of the concerns people tell, oh hey, Node.js is single-threaded, it's not going to perform well. But that actually forces you to think about scalability early on, and that'll show you how to scale your system as well. But before we do that, it's still possible to write blocking code in Node.js, right? In Node.js, it's a platform that's not going to prevent you from writing the blocking code. So you need to be very careful how you implement your Node applications. For example, this is a CPU intensive task that iterates many times, and on my machine it was taking from 100 to 1000 milliseconds. Obviously, it's a bad code, you don't want to do that in Node.js. Or at least you don't want to have one process to do CPU intensive tasks. Sometimes, most of the times, our blocking code is not so obvious. Most of the times, it's buried under some module. So FS is a file system module to work with file systems and directories. And in this example, I'm using synchronous methods. So we don't see that for loop, which revolves, but I know that it's a synchronous. And the results would be accounts, then hello Ruby, and then IPs, and then hello Node. So just as in your normal traditional blocking language like Python or Ruby or Java, it would be executed in the order in which you have statements. So no surprises here, but basically it will be a blocking code. This is a non-blocking version of exactly the same functionality. So FS has two types of methods. They're like siblings. They have eval siblings, which is synchronous, and they have the good siblings. This is a good sibling, asynchronous method, read file. And immediately you can see the difference in terms of how I implement it. I use callbacks instead of using an assignment. I cannot use an assignment because the data is not available. The data will be available only in the callback. So the contents will be available only in the callback. It will be defined. But then I might have a racing condition between what data I will have the first, accounts or IPs. But the data will be always after displaying hello Ruby and hello Node. So far so good. And feel free to ask questions in the middle. We're not going to have a formal Q&A at the end. Why bother having asynchronous? Why bother? So the question is why bother to have asynchronous version? Because without having asynchronous code, you will be blocking your process and you will lose that benefit of Node.js. Sorry, why bother having the synchronous? Why bother having the reverse? So why bother to have the synchronous code? It's there. Sometimes in a very edge case scenario you might need it. For example, you're starting a server and you're reading from a configuration file. So it doesn't make sense to start the server at all if you cannot get the configuration settings like port number or IP addresses. So in some edge case scenarios, it's there, it's for you. But most of the modules, they implement asynchronous interfaces. So Node typically is much faster than other platforms. Now all of the benchmarks, they don't really test your business logic. So we don't have like exact data, but mining total experience, working with teams and reading blog posts from PayPal, eBay, other big companies, Uber also runs everything on Node.js. Usually it tells that they have a dramatic improvement in performance, even like order of magnitude, like 10 times or 20 times faster. So that's all good, right? We get the performance, our company spends less money on the servers. That's all wonderful. But how many of you actually hid the performance limitations using traditional languages like Java or Python? So probably not many, right? I'm in the same boat. So most of the apps I'm building, unless it's for DacuSynos, or StoryFi, I don't experience that issue. Like remember Twitter in the early days, you would see that whale, so they had that performance issue, right? But I'm not experiencing them. So for me, my personal, my favorite benefit of Node.js is that you can have one language across your entire stack. So we have JavaScript on the browser, right? It's here to stay, it's not going to go away. We have a new standard now, we have six and seven, et cetera, so it's evolving, it's becoming better. Then you need to know another language, like Python or Java, for the backend. And then for database, if you're using traditional SQL database, you need to know SQL, which is a complex language in itself. You have all those joins, and you need to know the syntax, right? So three languages just to build your application, but then you need to know HTTP, you need to know CSS, you need to know HTML, and so a lot of other technologies, right? Having Node.js on the backend eliminates at least one language. And then if you use a Node SQL database like MongoDB, which I really, really love, then you can eliminate one more language. So having one language allows me to think faster, because I'm not switching the context. And I'm not making stupid mistakes like, oh, I forgot a semicolon here, or I need a double-quad instead of a single-quad, because it's a different language. I'm reusing my code, so templates, utility libraries from the browser, I can reuse them. And then I'm remembering those interfaces, I'm remembering how to call a method faster, I'm remembering all those methods and properties, because I'm using them twice more frequently. So that's a good thing. That's my personal favorite thing about Node.js. And for you, if you're learning Node.js, but you know JavaScript, browser JavaScript really well, it's probably take you like a weekend to get started, to get to the comfortable level with Node.js, because most of Node.js, it's your browser JavaScript. So we have the same array methods, the same string methods, so it's very, very, very great. But Node.js is not triple equals browser JavaScript. It's not completely same as browser JavaScript, right? So what are the difference? So we don't have window object. Obviously, there's no windows on the server side. We also have more power. We can get the environmental information, we can work with file systems, et cetera. So there is this thing that's called global. If there are lowercase or capitalized, that will give us a lot of properties and a few methods, those extra benefits, those extra things that we're lacking in browser JavaScript. For example, filename or dirname, that will give you the absolute path to the filename, the currently running script, or it will give you just the path without the filename. So it could be convenient when you need to know what is the location. Then we have native modules in Node.js. We don't have modules in browser. So even if you're using, yes, six modules, you have to rely on some transpiler like Babel or System.js. So in Node.js, the problem is solved. It's common JS syntax. It's beautiful. So module, that's how you export and requires that how you import a module in Node.js. It's all native. A few other things. How do I get a command line interface input? For example, I'm building a new grant or webpack tool. How do I get information about my system, like versions or platform? How do I read environmental variables, for example, API keys or passwords? There is this thing. It's called global.process, or you can just access it by process. Every global property is accessible without the prefix. You can either type explicitly, global, or implicitly you can just call that name process. And it's a really big object. I will just highlight some of the properties. For example, PID will get you the process ID. Versions, you can get versions of pretty much everything. For example, like V8 engine version. You can get the architecture. Arc V, that's how we get the input from the command line. And EMV, that's where your environment, that's where your API keys, you can access them once you're ready to deploy the production. So don't store your passwords in your source code. And don't create config.json, because you can use environmental variables. Oh, we have issues again. The ghost of demo. Okay, so it's a good thing to have some type of monitoring when you're building a web server especially. So you can get uptime. It's how long your process is running, and then the memory usage. CWD, that's the current warranty directory. And then we can exit the process, or we can kill another process from Node.js. So I hope you can start understanding that Node.js gives you more power. Obviously in the browser, we don't have that power because you don't want to go to a website, and that website can create a file on your file system, right? Okay, so let's move into Node.js, some of the Node.js patterns. How many of you really understand and like callbacks? Oh, wow, it's like 40%. Really cool. I like callbacks until I hit callback hell. There's even a website. It's called callbackhell.com. And once you're inside of that nested pyramid of doom, or sometimes it's called nested approach, it might be tricky to really understand what is happening. So callbacks could be, especially in large projects, they're not very scalable in the developmental sense, meaning when you add more developers on a project, it can become harder to understand that code. And sometimes nested callbacks can lead to problems. So we have advanced patterns like promises and generators in the sync await. I'm not going to talk about them because they're not part of the core. So core modules, they don't use promises, right? Version 6 of Node.js, it comes with promises without any flags. You have the promises, standard ES6 promises. But when you use modules, you have only two options, callbacks or events. So let's focus on events because callbacks, most of the people are familiar with them. Basically events, they're your standard observer pattern. So we have a subject, we have observers or event listeners, and then we have someone else triggering those events. This is how you create it. So you require events, which is a core module, you don't need any NPM for this, and then you create a new object. So this will be our subject, emitter, and we're using prototypical instantiating patterns, so we need to say a new keyword. And we define our event listener, our observer, basically. The way we define it is very easy. We provide a string, and then we provide a function. So when the string is the name of the event, it will be triggered, this function will be executed. And we can have multiple events with the same name or with a different name as well. So let's consider a little bit more interesting example. So I have two events, but they have the same name. So what will happen, they will be triggered in the order in which I define them. So the last line, immediate knock, will basically trigger that event, and then I would see who's there and go away. So immediately you can understand the benefits comparing to callbacks. In callbacks we have just one function that is executed at the end. Here with events you can have multiple functions. You can execute them in the middle, in the end, it doesn't matter, it's up to you. So you get more power. Now, this is a more realistic example. Let's say we have a module, it's called job.js, and the code is in that GitHub repository. But the job needs to be customizable. So at the end we want to put some custom logic, but we don't want to hard-code it in the module. We want the consumers, so developers, who use the module to give the power to customize what will happen at the end. So we can use events for this. The way we do it, we basically emit an event, and then in our documentation we tell developers, if you want to have that custom ending, go ahead and implement an event listener because we will be emitting an event. And then developers, let's say I'm a developer, I want to implement the weekly job. So it's a weekly newsletter, and then I'm creating this event listener because I know the done will be emitted. If I don't have that event listener, that's cool, okay. That's also okay. That's also cool because it's not going to crash. It's not like, oh, I'm defined, right? So this is a powerful pattern, how you can basically create modules and abstract some of the code by still giving the flexibility to developers, developers who use your modules. Some of the useful methods, for example, we can remove event listeners. We cannot do that with callbacks. We can specify, hey, execute it just once, right? With once. It's another advantage. Some of the other node patterns, I wrote this blog post, node patterns from callbacks to observers. I also talk about modules and have their singletons to check it out. Okay, so let's move on. Problems with large data. So it's slow because you have to wait for all data to load. There's also buffer limitation in Node.js. One gigabyte, that's it. You're done. The last one is just a joke. We can use streams. Streams are, again, it's a core module in Node.js. It allows us for continuous consumption of the data. So we can transform it. We can do something with the data without waiting for the whole chunk of the data to load. Okay. We have four types of streams. We have writable, readable, duplex and transform. Duplex, it means it's both writable and readable, and then the transform means it's just transforming. Streams already inherit from Eventimator, so we can use that interface to implement our streams. Streams are everywhere, especially in the core, not just core. We can use streams for HTTP requests and response. We can use them for standard input and output for reading and writing to a file. This is an example of a readable stream. I don't want to have to name one of that. And if you're following on your machines, it's std in.js. Can you see it? Probably not. So basically each line, each new string, it's a chunk of data, and I'm processing it as I go. This is how it looks like in the code. So basically process.std in. I get my readable stream, then I execute Resume and set the encoding, and then I'm listening for the onData. So remember the previous slides with the Ventimator, so very similar. We create this event listener onData. So onData will happen each time I have a new line on my terminal, and I can start processing that text. And then once I'm done, it's good to have also a listener for the end event. Okay. So demo, we did this. For readable, we also have a different approach. We can use read method. So read method, it's synchronous, but it's okay for it to be synchronous because it's really just a chunk of data. It's just one line. So imagine that large data file, we're processing it line by line. And when it's null, that means that it's over. Basically, the stream is over, so we can have a while loop and compare it to the null. Example of a writable stream, so std out, that would be the output of your node script. And there is a write operation. We use it like this, process.std out.write. So this would be an analogous for console.log. In fact, console.log is using something similar. So we're writing to our output stream. What about HTTP? Because most of the times we're building HTTP servers, right? That's where streams really, really shine because we don't want the consumers of either our API or our web app to wait for too long, right? So in this example, I have a server and I'm getting that request object. So your typical hello world type of server, very minimalistic. But then, instead of waiting for entire data, I'm creating an event listener on data and transform. Let's imagine it's a function defined somewhere else. Maybe it's a module. But the key here is that the chunk is available right away. I don't have to wait for the entire one gigabyte file to load. And then at the end, I can parse it. I can do something else with it. There's also pipe interface. Pipe is very similar to the pipes, double pipes in your Linux terminal command or command prompt in Windows. So basically, we're taking one stream and piping it to another, then piping it to another. So we're passing the data. So r.pipe, z.pipe, w, we'll read from a file, compress it, and then write to a different file. All without having any buffers. Speaking of buffers, buffers is a special data type. We don't have it in the browser JavaScript. There is a rate buffers in the S6, which is kind of similar. And the way we create buffers, we can execute that from. This has been just recently changed in version 6. And version 5, you would use a different approach. And I have a link to the documentation as well. If you're new to buffers, sometimes you might see, when you're expecting a stream, you might see something like this, which looks like an array, but it has numbers. That means you didn't convert from buffer to a stream. You can easily convert by specifying and encoding. So by default, when you're reading or writing to a file, or it's a request, it's a buffer. Especially if you're not using any frameworks, it will be buffer. So you need to convert it. This is how you can do it. By default, if you just say toString, it will use UTF-8. So remember FS from a few slides back. So when we're reading from a file, the data, it's a buffer by default. Without this example, it doesn't have the encoding. Okay, so server stream, it's a small express JS server that I've written. And I'm launching a node space server dash stream. So what it's doing is basically it has two endpoints. One endpoint is using stream, and another is not using stream. So let's go to the one that is not using stream. And it's a huge infographic about Capital One. It's like 8 megabytes or something like that. And I'm going to the DevTools. I'm going to Network. And I'm clicking on the response. Actually, I'm clicking on the header, and I don't know if you can see. So it's 6.57 milliseconds. So let's remember that number. So I'm going to go to Network, click on all. By the way, I love DevTools. Such a nice thing. How many of you like DevTools? Yeah. So it's 1.4 milliseconds. So response time is shorter. Sometimes I get it order of magnitude shorter. Yeah, so right now it's 0.42. Okay. And this was, this is 6 milliseconds. This is 0.4 milliseconds. Okay, so response time. This is not like entire infographic. That's only the first byte. But that's enough for users to start seeing something, right? So that's the benefit of using streams. I also have two more endpoints that they use a different interface, but that is the same. Streams are faster. Some good stream resources. There's automated workshop, which have exercises you can go through them, and it will test your answers. So it's a great tool to learn streams. And there's also a stream hands book. Okay, so going back to having a single system, right? Node.js, it's single threaded, but I like to flip it around and make it an advantage versus having it as a disadvantage. How you can do it. So basically it forces developers to think about scalability early on. Most of us, we build microservices, we build distributed systems, right? So if you're using Java, it's like, oh, it's a multi-threaded, I don't need to worry about it with Node.js. Oh, I'm starting a new project. I need to start thinking about scalability, how it's going to work across multiple stateless servers early on. Luckily, there is a core module, it's called cluster. The idea is that we have multiple processes. So we can spawn multiple processes with this core module. And one of the processes, it will be like the main thing. It will control everything else. And then we'll have workers who will do the main job. So most of the times it's web servers. So workers have web servers, and then the master is controlling those web servers. And typically we have as many processes as many CPUs we have. So it's not like a hard rule, you can have more, but you get low diminishing returns. So basically to maximize the max CPU from your machine, that's the best practice to have the same number of workers. This is the code. So as you can see, it's very easy. All we are doing, we're having nif condition, cluster.isMaster and we fork in new processes. So.fork will create a new Node.js process using exactly the same file. So this code is for both master and the cluster, the worker. And then cluster is worker, that's where our web server code goes. It can use express or just core HTTP, it doesn't matter. And number of CPUs, that comes from the core module. It's called os. So this is an example of having multiple processes. So Node, space cluster. Oh, I have something else running. So let's just kill everything. Okay, so as you can see, I have four workers and they have different process ideas. So that's a proof that it's different processes, right? And all of them, they're listening on the same port. So this is like a load balancing. Basically, we have four processes listening on the same port. Another benefit of this is that you can do zero downtime reloading. Basically, you want to restart, you have new version of your server. If you have multiple workers, you can kill them one by one and replay them one by one without losing the availability, right? So again, that forces you to think about scalability and creating better systems early on. So I'm going to a new window and I'm using this tool. It's called load test. It's similar to Apache AB or Jmeter for Java. It's a load testing tool, but it's reading in pure Node.js. And I will be hitting my local host. I will have 20 second time out and I will have max 10 concurrent requests. So now I'm going back and I see that different processes respond to my load testing requests. You see the numbers change, right? And it will take some time, but it will give us some numbers. If you're running on your machines, you can tell me your numbers. We can compare who's machine is faster. So basically, I was able to do 800 requests. When I'm doing it on Mac Pro, I have 2000 requests. Okay. So there are other libraries for doing a similar thing, for having multiple processes. So the advantage of Cluster is that it's core, but other libraries, they have more features. For example, PM2, strong loop cluster control. I recommend using one of those unless you want to build a new PM. PM stands for process manager. Some of the advantages. Again, you can have zero seconds reload downtime. So basically, your app will be forever available, forever alive. Another advantage of PM2, you don't need to modify your server code. So remember that if else condition in the cluster example, so in PM2 is just your server code. You don't do anything with it. And it also give you a nice... Give you a nice... I'll show it to you. It will give you a nice interface. So basically, it's a table. It shows me how many processes they have, how many online, etc. So PM2 is a little bit nicer. Okay. So there are two more ways how you can launch external processes from Node.js. For example, maybe you want to build a system where Node.js is just doing input-output operations, but then the heavy lifting, the CPU bound tasks their outsourced to different platform or language, maybe Python or Java. You can do it with spawn. Spawn, you can handle large data, it's for streams. Fork, it's only for Node.js processes. You've seen how it's working. It's for something small, maybe like a Linux command to get the memory, to get some stats because it has a buffer. So it's not using streams, so you don't want to hit the buffer limitation. I have some examples of how to use spawn. So basically, you provide the name of the command, then provide the arguments. And then again, you listen for that data. So on data, again, event emitters. Fork is very similar, only we don't specify that it's Node because we assume it's Node. Okay. So Fork is for Node, it's a narrow case of spawn. Exec, and all three of them, they come from child underscore process. I don't know why they named it with underscore. Most of the modules in Node, they named with dash. But this one of the inconsistencies that we have. Exec has different interface. We don't use events. It's just a callback. Just a callback because we don't have streams. Okay. So one of the other objections of why Node to use Node because it's hard to think about asynchronous code. Our brains, they're not really evolved to think about processes running in parallel concurrently. We're much better suited to think about synchronous code. And then on top of that, it's also hard to debug errors in synchronous code because we lose the context. So for example, remember that set timeout. So when set timeout is executed in the callback, which was scheduled in the future by the previous process, we lose that context. Let's take a look at this example. So try catch, right? We know what it's doing. It's allowing us to catch errors. So this code will work absolutely beautifully, but it's synchronous code. There is no callbacks. There is no events. If we have callbacks and events, so all I did just put set timeout here and I'm throwing error in the future. This app will crash. So try catch is totally useless. This code will miserably fail because the error happens in the future in the callback and we lose that context. Okay? This is how I feel when asynchronous error happens and no one handled it. So how to deal with it? Here's the list. Checklist. Let's go through them. So first of all, again, eventimeter, right? Most of the modules, virtually all of the modules, especially core modules, they would trigger error. So you want to listen for that. So you as a developer, when you're consuming those modules, implement this event handler. And at least have trace, save that error message somewhere, right? Log it. You can also use chain methods, just a different syntax, same idea. And here I'm exiting the process. So I'm exiting it with a code one, which means error. Again, different approach, same idea. So request, I am sending a request. That request can have two types of errors. When I'm making the request, so I need to listen to the event errors, and then when the request is happening, then this would have an error as well inside of the callback. This is like the mother of all the error events. Basically, when nothing else works, have this listener on your process. So this is like the last chance, the very last chance to do something useful, like logging your error, tracing it, creating a notification, sending an email to your webmaster, to your dev apps. So process that on uncut exception, always have it. Now there is this cool thing, it's called domain. It has absolutely nothing to do with domains like the.gov.com, like the URL domains. I have no idea why they named it. And they have a label, if you go to the docs, that it's softly deprecated. It's very confusing, but basically it means that they might remove it from the core in the future. But right now it's in the core, and even when they remove it, it's still relatively popular with users. It's going to live as an NPM module. So I don't see any reasons why not to use it. And this is the idea. So we're creating in the main. And our falling code, our error-prone code, it goes inside of the run. So basically run is wrapping our bad code. And then we're not scared of asynchronous errors. So this code will work. I can prove it to you. If I go here. So this is async error. It failed. And this is the domain async. It didn't fail. It gave me a nice error message, which I programmed there. Okay. Now the last thing you can do, it's number six. It's a bonus. And it's really cool for some of you IoT and hardware geeks. You can build a C++ add-on and create a JavaScript interface on top of that. Node.js works very beautifully with C++. So create your C++ code. This is just a boilerplate code. I just copied it in portals of those modules. And then what I'm doing, I'm writing the string capital one. And then I'm exporting the method hello. So the hello will be available in my node code when I import this module. Then I need to create this file binding.jip, basically it has the name of my module, my C++ add-on, and my source file. Then I need this tool, Node.jip, which will compile everything for me. And all I need to do is just execute those two commands. That's it. It's done. It's working. I will have this folder build-dry slash releases. Now in my code, I'm importing that using require, remember require. It's a global property, global method. And that's it. I will have my string. So this string is coming from C++. Okay. So if you're interested in working with Node.js, capital one is hiring in UK, US, and Canada, shameless plug. And we're also using cutting edge open source technologies like React, Kotlin, Clojure, Angular 2, et cetera. Some of the people there working in heavily regulated industries like healthcare, defense, finance, or capital one is finance. So if you're interested in how we solve the problem of being in a heavily regulated industry and working with open source, this is a talk I did at Node.interactive. So 30-second summary. Event emitters everywhere in the core. It's good to know them. Streams very, very powerful. They basically will make you like a guru or ninja, a pro in your team if you know how to use them. Buffers need to convert them. Clusters, they allow you to scale. And you can build C++ add-ons. I almost want to join them. It's so much fun there. Slides. And my contacts. Write me an email. For further learning, check out my blog at NodeProgram.com. And one last thing. This is a quote from the same blogger, codinghorror.com. JavaScript. It's really, really becoming popular. Thank you.
 Hello. Hello, everyone. Welcome to the Node.js presentation. You don't know Node. We will  go over five core features. It's not going to be about a fancy framework, cutting edge  advanced stuff like promises or anything like that. It's going to be about the core fundamental,  the basics. So even if you work with Node.js, some build tools for friend development, you  might not know about these core features. So let's get started. And this is a hands-on  presentation. So I want you to take out your laptops, download the code. I have it on GitHub,  the code and the slides and the PDFs, and follow the demos that I will be showing you  on your computers. And turn off all the IMs and slacks and notifications. They're doing  really well there. Maybe we can beat them in terms of making sounds later. Can I have  some little bit more volume in my mind? Thank you. So take a picture, get the slides and  follow me with the code examples. So first of all, I want to remind you why we're here,  why we're coming to this type of conferences and why we're doing software. So I want to  put this big statement. We write software, we write apps to make our lives and life of  other people better, basically, because software changes lives. Software is pretty much everywhere.  So is that my computer? Did you have a different adapter?  Oh, the different, the power. Do you know where is it?  Oh, okay. That would make sense. Yeah. No. 40.  Let me try to mirror.  This is all summing up.  No, too unworth.  It used to be good, right?  Let me try.  Yeah, it's all like that.  You can try another cable, but it's so strange because now it's because it's perfect.  The picture is good down there.  It was completely stable in the time there.  But then, on the slide number 3, the picture started to fly on the project.  So, it's stable.  What?  The fuck?  Yeah, this is stable.  But this, I don't have a picture now.  Yeah, it's stable.  Yeah, it's stable.  So, that's actually perfect because you have time to download the slides.  Yeah, it's stable.  Yeah, it's stable.  Yeah, it was there.  Now it's there. 50.  Thank you.  Okay, so, start over again.  Welcome to YouDon'tKnowNotJS.  This is a hands-on presentation.  And in case you missed it the first time, this is the repository where you can get the slides and the code.  So, this presentation will have a lot of code examples.  I want you to have the code so you can later refer to it.  So, we're building software and we're trying to use better technologies, better frameworks to improve the lives, improve the community,  the lives of our loved ones, the lives in general of other people, right?  Software is becoming everywhere.  And with this big kind of a goal, I will introduce myself.  I published and wrote 12 books, not counting Chinese, Korean, and Russian translations.  The most popular ones are Practical Node.js and ProExpress.js.  You might have seen them on Amazon.com.  They were on the first page if you search for Node.js.  My new book, React Quickly, it's coming in a few months.  That will be about React.js.  You can follow me on Twitter at azad underscore co. I tweet about JavaScript and Node.js mostly.  And I also have a blog.  And if you have questions after this conference, you can reach me at my email.  Hi, at azad.co.  I work at Capital One.  It's one of the US top 10 banks in the financial industry.  I'll talk about it more in the next slide.  Before that, I worked at startups, US federal government agencies.  I would like to highlight my experience with DocuSign and StoryFi.  That's where I got to use Node.js at a pretty relatively large scale.  And I saw from my own eyes that Node.js is, how Node.js is beneficial in terms of having  a generalistic approach and in terms of performance and having a better developmental experience.  They also teach at Nodeprogram.com, where you can find live in-person trainings in Node.js  as well as online trainings.  So Capital One, it's in the top 10 US banks.  We're also in the UK and Canada.  And in US, we're famous for our Visigoth commercials, but most people think it's Vikings.  Some of them are funny.  So why use Node.js?  So let's start with basics, right?  I want to give you some ammo.  So when you go to your work on Monday next week, you have something to tell your coworkers  and your team leads in order to convince them, hey, maybe we should use Node.js for our next project.  So the biggest selling point of Node.js is its performance.  So basically, it's faster.  And it's faster because it optimizes the input and output bound processes.  So most of the times, input and output is the most expensive tasks that we have compared to CPU bound tasks.  So if we can optimize for them, that will give us a good boost in performance.  So Node.js has this thing, it's called non-blocking I.O.  How many of you already familiar with this term?  Raise your hand.  OK, so like half of the audience.  So for the rest of the half, this will be beneficial.  So non-blocking, this diagram shows you high level overview how it's implemented in Node.js.  So we have the thing it's called Event Loop.  Event Loop, it's always looking for something to execute.  So basically, it's never blocked or almost never blocked.  And it allows our system, our Node.js-based system to process multiple requests pretty much in parallel, pretty much at the same time.  And then Event Loop delegates those tasks, those heavy input-output tasks, like reading from a file system  or writing to a database, or the most popular thing that we like to do when we're building web apps  is to make HTTP requests to APIs or third-party services.  So those all time-consuming tasks, Event Loop delegates them.  Let's go a little bit more low level.  This is Java code.  How many of you Java developers here?  OK, just about 20%, not that many.  Most of the time I'm teaching Node.js to Java developers.  But you can guess what this means, right?  Thread.sleep, it's putting the entire process to sleep.  So nothing will happen on this particular thread unless the timer expires, right?  So the entire thing will be basically useless.  OK, we will see step one, step two, and then step three.  Contrast that code with this Node.js.  So now we have fancy callbacks.  So set time out, it takes a callback, which is a function definition.  It's anonymous function definition.  It doesn't have a name.  And basically tells, OK, schedule that in the future.  Don't execute it now.  And the future will happen at one second, so 1,000 milliseconds.  But the good thing about this code and this Node.js implementation is that set timeout is not blocking.  So Node.js, this process will continue to execute.  So we will see step one, step two, and then after one second we will see step three.  OK, and then if we have more code, Node.js will still continue to execute that.  So the result of this would be step one, step two, and then step four, not step three.  And then after one second we will see step three and step five.  So if you're familiar with how callbacks, Dread, jQuery, or promises in Angular framework works on the browser,  this is a very similar approach basically.  We're scheduling something in the future.  But the benefit is that our process is not blocked.  We can process a lot of requests.  So putting processes to sleep, that's not very useful.  Most of the time we are using, we're building web services.  But that analogy, set timeout, that's exactly how Node.js is implementing a synchronous input output.  So it could be writing to the database or it could be making a request.  Let's take a look at this diagram.  So this is a blocking system, maybe written in Python or Java.  And we have four clients.  Please take this, it must be important.  We have four clients, they submit requests.  So the client at the bottom, he or she, have three requests.  But each request is blocked by the previous request, because it's hitting that one thread.  Compare it to standing in line for a coffee.  We have that pretty cool Twilio booth downstairs at the expo.  I saw a lot of people standing in line, 20 people, maybe 10, 20 people during the breaks.  So that's your typical blocking system, because you have to wait for the people in front of you  to order your drink and to get your drink.  In Node.js we have a non-blocking system.  This is a diagram, again we have that event loop, which is delegating the processes.  And event loop is always available, or almost always available.  Compare that to the same Twilio booth with a coffee bar,  but they have that option where you can text, or Facebook your drink,  and then you can walk around, talk with other people,  and they will text you back when the drink is ready.  So this is much more enjoyable experience than waiting in line, and not able to do other things.  So the texting to get your coffee, that's non-blocking, that's asynchronous.  That's what we usually want.  This quote is from CordingHorror.com, it's a pretty famous blog.  I would recommend subscribing to it.  So basically the blocking system, they have to be multi-threaded,  because each thread is blocked, but multi-threading could be very dangerous if you don't know how to use it.  You can get racing conditions, you need to know how to synchronize the data between multiple threads.  You might have deadlocks, etc.  It can really blow in your face.  And yeah, blocking system, they have to be multi-threaded.  So Node.js, by design, the designers of Node.js, the original creators, they decided,  we're not going to create multiple threads, we just have single thread.  And this is actually a beautiful thing, because with a single thread, you can avoid all that complexity  and work in a pure asynchronous and non-blocking environment.  And that's one of the concerns people tell, oh hey, Node.js is single-threaded, it's not going to perform well.  But that actually forces you to think about scalability early on,  and that'll show you how to scale your system as well.  But before we do that, it's still possible to write blocking code in Node.js, right?  In Node.js, it's a platform that's not going to prevent you from writing the blocking code.  So you need to be very careful how you implement your Node applications.  For example, this is a CPU intensive task that iterates many times,  and on my machine it was taking from 100 to 1000 milliseconds.  Obviously, it's a bad code, you don't want to do that in Node.js.  Or at least you don't want to have one process to do CPU intensive tasks.  Sometimes, most of the times, our blocking code is not so obvious.  Most of the times, it's buried under some module.  So FS is a file system module to work with file systems and directories.  And in this example, I'm using synchronous methods.  So we don't see that for loop, which revolves, but I know that it's a synchronous.  And the results would be accounts, then hello Ruby, and then IPs, and then hello Node.  So just as in your normal traditional blocking language like Python or Ruby or Java,  it would be executed in the order in which you have statements.  So no surprises here, but basically it will be a blocking code.  This is a non-blocking version of exactly the same functionality.  So FS has two types of methods.  They're like siblings.  They have eval siblings, which is synchronous, and they have the good siblings.  This is a good sibling, asynchronous method, read file.  And immediately you can see the difference in terms of how I implement it.  I use callbacks instead of using an assignment.  I cannot use an assignment because the data is not available.  The data will be available only in the callback.  So the contents will be available only in the callback.  It will be defined.  But then I might have a racing condition between what data I will have the first, accounts or IPs.  But the data will be always after displaying hello Ruby and hello Node.  So far so good.  And feel free to ask questions in the middle.  We're not going to have a formal Q&A at the end.  Why bother having asynchronous?  Why bother?  So the question is why bother to have asynchronous version?  Because without having asynchronous code, you will be blocking your process  and you will lose that benefit of Node.js.  Sorry, why bother having the synchronous?  Why bother having the reverse?  So why bother to have the synchronous code?  It's there.  Sometimes in a very edge case scenario you might need it.  For example, you're starting a server and you're reading from a configuration file.  So it doesn't make sense to start the server at all if you cannot get the configuration settings  like port number or IP addresses.  So in some edge case scenarios, it's there, it's for you.  But most of the modules, they implement asynchronous interfaces.  So Node typically is much faster than other platforms.  Now all of the benchmarks, they don't really test your business logic.  So we don't have like exact data, but mining total experience,  working with teams and reading blog posts from PayPal, eBay, other big companies,  Uber also runs everything on Node.js.  Usually it tells that they have a dramatic improvement in performance,  even like order of magnitude, like 10 times or 20 times faster.  So that's all good, right?  We get the performance, our company spends less money on the servers.  That's all wonderful.  But how many of you actually hid the performance limitations  using traditional languages like Java or Python?  So probably not many, right?  I'm in the same boat.  So most of the apps I'm building, unless it's for DacuSynos,  or StoryFi, I don't experience that issue.  Like remember Twitter in the early days, you would see that whale,  so they had that performance issue, right?  But I'm not experiencing them.  So for me, my personal, my favorite benefit of Node.js  is that you can have one language across your entire stack.  So we have JavaScript on the browser, right?  It's here to stay, it's not going to go away.  We have a new standard now, we have six and seven, et cetera,  so it's evolving, it's becoming better.  Then you need to know another language, like Python or Java,  for the backend.  And then for database, if you're using traditional SQL database,  you need to know SQL, which is a complex language in itself.  You have all those joins, and you need to know the syntax, right?  So three languages just to build your application,  but then you need to know HTTP, you need to know CSS,  you need to know HTML, and so a lot of other technologies, right?  Having Node.js on the backend eliminates at least one language.  And then if you use a Node SQL database like MongoDB,  which I really, really love, then you can eliminate one more language.  So having one language allows me to think faster,  because I'm not switching the context.  And I'm not making stupid mistakes like,  oh, I forgot a semicolon here, or I need a double-quad instead  of a single-quad, because it's a different language.  I'm reusing my code, so templates, utility libraries from the browser,  I can reuse them.  And then I'm remembering those interfaces,  I'm remembering how to call a method faster,  I'm remembering all those methods and properties,  because I'm using them twice more frequently.  So that's a good thing.  That's my personal favorite thing about Node.js.  And for you, if you're learning Node.js,  but you know JavaScript, browser JavaScript really well,  it's probably take you like a weekend to get started,  to get to the comfortable level with Node.js,  because most of Node.js, it's your browser JavaScript.  So we have the same array methods, the same string methods,  so it's very, very, very great.  But Node.js is not triple equals browser JavaScript.  It's not completely same as browser JavaScript, right?  So what are the difference?  So we don't have window object.  Obviously, there's no windows on the server side.  We also have more power.  We can get the environmental information,  we can work with file systems, et cetera.  So there is this thing that's called global.  If there are lowercase or capitalized,  that will give us a lot of properties and a few methods,  those extra benefits, those extra things  that we're lacking in browser JavaScript.  For example, filename or dirname,  that will give you the absolute path to the filename,  the currently running script,  or it will give you just the path without the filename.  So it could be convenient when you need to know  what is the location.  Then we have native modules in Node.js.  We don't have modules in browser.  So even if you're using, yes, six modules,  you have to rely on some transpiler like Babel or System.js.  So in Node.js, the problem is solved.  It's common JS syntax.  It's beautiful.  So module, that's how you export  and requires that how you import a module in Node.js.  It's all native.  A few other things.  How do I get a command line interface input?  For example, I'm building a new grant or webpack tool.  How do I get information about my system,  like versions or platform?  How do I read environmental variables,  for example, API keys or passwords?  There is this thing.  It's called global.process,  or you can just access it by process.  Every global property is accessible without the prefix.  You can either type explicitly, global,  or implicitly you can just call that name process.  And it's a really big object.  I will just highlight some of the properties.  For example, PID will get you the process ID.  Versions, you can get versions of pretty much everything.  For example, like V8 engine version.  You can get the architecture.  Arc V, that's how we get the input from the command line.  And EMV, that's where your environment,  that's where your API keys, you can access them  once you're ready to deploy the production.  So don't store your passwords in your source code.  And don't create config.json,  because you can use environmental variables.  Oh, we have issues again.  The ghost of demo.  Okay, so it's a good thing to have some type of monitoring  when you're building a web server especially.  So you can get uptime.  It's how long your process is running,  and then the memory usage.  CWD, that's the current warranty directory.  And then we can exit the process,  or we can kill another process from Node.js.  So I hope you can start understanding  that Node.js gives you more power.  Obviously in the browser, we don't have that power  because you don't want to go to a website,  and that website can create a file on your file system, right?  Okay, so let's move into Node.js,  some of the Node.js patterns.  How many of you really understand and like callbacks?  Oh, wow, it's like 40%.  Really cool.  I like callbacks until I hit callback hell.  There's even a website.  It's called callbackhell.com.  And once you're inside of that nested pyramid of doom,  or sometimes it's called nested approach,  it might be tricky to really understand what is happening.  So callbacks could be, especially in large projects,  they're not very scalable in the developmental sense,  meaning when you add more developers on a project,  it can become harder to understand that code.  And sometimes nested callbacks can lead to problems.  So we have advanced patterns like promises  and generators in the sync await.  I'm not going to talk about them because they're not part of the core.  So core modules, they don't use promises, right?  Version 6 of Node.js, it comes with promises without any flags.  You have the promises, standard ES6 promises.  But when you use modules, you have only two options, callbacks or events.  So let's focus on events because callbacks,  most of the people are familiar with them.  Basically events, they're your standard observer pattern.  So we have a subject, we have observers or event listeners,  and then we have someone else triggering those events.  This is how you create it.  So you require events, which is a core module,  you don't need any NPM for this, and then you create a new object.  So this will be our subject, emitter,  and we're using prototypical instantiating patterns,  so we need to say a new keyword.  And we define our event listener, our observer, basically.  The way we define it is very easy.  We provide a string, and then we provide a function.  So when the string is the name of the event,  it will be triggered, this function will be executed.  And we can have multiple events with the same name  or with a different name as well.  So let's consider a little bit more interesting example.  So I have two events, but they have the same name.  So what will happen, they will be triggered in the order  in which I define them.  So the last line, immediate knock, will basically trigger that event,  and then I would see who's there and go away.  So immediately you can understand the benefits  comparing to callbacks.  In callbacks we have just one function that is executed at the end.  Here with events you can have multiple functions.  You can execute them in the middle, in the end,  it doesn't matter, it's up to you.  So you get more power.  Now, this is a more realistic example.  Let's say we have a module, it's called job.js,  and the code is in that GitHub repository.  But the job needs to be customizable.  So at the end we want to put some custom logic,  but we don't want to hard-code it in the module.  We want the consumers, so developers, who use the module  to give the power to customize what will happen at the end.  So we can use events for this.  The way we do it, we basically emit an event,  and then in our documentation we tell developers,  if you want to have that custom ending,  go ahead and implement an event listener  because we will be emitting an event.  And then developers, let's say I'm a developer,  I want to implement the weekly job.  So it's a weekly newsletter,  and then I'm creating this event listener  because I know the done will be emitted.  If I don't have that event listener, that's cool, okay.  That's also okay. That's also cool  because it's not going to crash.  It's not like, oh, I'm defined, right?  So this is a powerful pattern,  how you can basically create modules  and abstract some of the code  by still giving the flexibility to developers,  developers who use your modules.  Some of the useful methods, for example,  we can remove event listeners.  We cannot do that with callbacks.  We can specify, hey, execute it just once, right?  With once. It's another advantage.  Some of the other node patterns,  I wrote this blog post,  node patterns from callbacks to observers.  I also talk about modules  and have their singletons to check it out.  Okay, so let's move on.  Problems with large data.  So it's slow because you have to wait  for all data to load.  There's also buffer limitation in Node.js.  One gigabyte, that's it. You're done.  The last one is just a joke.  We can use streams.  Streams are, again, it's a core module in Node.js.  It allows us for continuous consumption of the data.  So we can transform it.  We can do something with the data  without waiting for the whole chunk of the data to load.  Okay.  We have four types of streams.  We have writable, readable, duplex and transform.  Duplex, it means it's both writable and readable,  and then the transform means it's just transforming.  Streams already inherit from Eventimator,  so we can use that interface to implement our streams.  Streams are everywhere, especially in the core,  not just core.  We can use streams for HTTP requests and response.  We can use them for standard input and output  for reading and writing to a file.  This is an example of a readable stream.  I don't want to have to name one of that.  And if you're following on your machines,  it's std in.js.  Can you see it? Probably not.  So basically each line, each new string,  it's a chunk of data, and I'm processing it as I go.  This is how it looks like in the code.  So basically process.std in.  I get my readable stream, then I execute Resume  and set the encoding, and then I'm listening for the onData.  So remember the previous slides with the Ventimator,  so very similar.  We create this event listener onData.  So onData will happen each time I have a new line on my terminal,  and I can start processing that text.  And then once I'm done, it's good to have also a listener  for the end event.  Okay.  So demo, we did this.  For readable, we also have a different approach.  We can use read method.  So read method, it's synchronous, but it's okay for it to be synchronous  because it's really just a chunk of data.  It's just one line.  So imagine that large data file, we're processing it line by line.  And when it's null, that means that it's over.  Basically, the stream is over, so we can have a while loop  and compare it to the null.  Example of a writable stream, so std out,  that would be the output of your node script.  And there is a write operation.  We use it like this, process.std out.write.  So this would be an analogous for console.log.  In fact, console.log is using something similar.  So we're writing to our output stream.  What about HTTP?  Because most of the times we're building HTTP servers, right?  That's where streams really, really shine  because we don't want the consumers of either our API  or our web app to wait for too long, right?  So in this example, I have a server  and I'm getting that request object.  So your typical hello world type of server, very minimalistic.  But then, instead of waiting for entire data,  I'm creating an event listener on data and transform.  Let's imagine it's a function defined somewhere else.  Maybe it's a module.  But the key here is that the chunk is available right away.  I don't have to wait for the entire one gigabyte file to load.  And then at the end, I can parse it.  I can do something else with it.  There's also pipe interface.  Pipe is very similar to the pipes,  double pipes in your Linux terminal command  or command prompt in Windows.  So basically, we're taking one stream and piping it to another,  then piping it to another.  So we're passing the data.  So r.pipe, z.pipe, w, we'll read from a file, compress it,  and then write to a different file.  All without having any buffers.  Speaking of buffers,  buffers is a special data type.  We don't have it in the browser JavaScript.  There is a rate buffers in the S6, which is kind of similar.  And the way we create buffers, we can execute that from.  This has been just recently changed in version 6.  And version 5, you would use a different approach.  And I have a link to the documentation as well.  If you're new to buffers, sometimes you might see,  when you're expecting a stream, you might see something like this,  which looks like an array, but it has numbers.  That means you didn't convert from buffer to a stream.  You can easily convert by specifying and encoding.  So by default, when you're reading or writing to a file,  or it's a request, it's a buffer.  Especially if you're not using any frameworks, it will be buffer.  So you need to convert it.  This is how you can do it.  By default, if you just say toString, it will use UTF-8.  So remember FS from a few slides back.  So when we're reading from a file, the data, it's a buffer by default.  Without this example, it doesn't have the encoding.  Okay, so server stream, it's a small express JS server that I've written.  And I'm launching a node space server dash stream.  So what it's doing is basically it has two endpoints.  One endpoint is using stream, and another is not using stream.  So let's go to the one that is not using stream.  And it's a huge infographic about Capital One.  It's like 8 megabytes or something like that.  And I'm going to the DevTools.  I'm going to Network.  And I'm clicking on the response.  Actually, I'm clicking on the header, and I don't know if you can see.  So it's 6.57 milliseconds.  So let's remember that number.  So I'm going to go to Network, click on all.  By the way, I love DevTools.  Such a nice thing.  How many of you like DevTools?  Yeah.  So it's 1.4 milliseconds.  So response time is shorter.  Sometimes I get it order of magnitude shorter.  Yeah, so right now it's 0.42.  Okay.  And this was, this is 6 milliseconds.  This is 0.4 milliseconds.  Okay, so response time.  This is not like entire infographic.  That's only the first byte.  But that's enough for users to start seeing something, right?  So that's the benefit of using streams.  I also have two more endpoints that they use a different interface,  but that is the same.  Streams are faster.  Some good stream resources.  There's automated workshop, which have exercises you can go through them,  and it will test your answers.  So it's a great tool to learn streams.  And there's also a stream hands book.  Okay, so going back to having a single system, right?  Node.js, it's single threaded,  but I like to flip it around and make it an advantage  versus having it as a disadvantage.  How you can do it.  So basically it forces developers to think about scalability early on.  Most of us, we build microservices,  we build distributed systems, right?  So if you're using Java, it's like, oh, it's a multi-threaded,  I don't need to worry about it with Node.js.  Oh, I'm starting a new project.  I need to start thinking about scalability,  how it's going to work across multiple stateless servers early on.  Luckily, there is a core module, it's called cluster.  The idea is that we have multiple processes.  So we can spawn multiple processes with this core module.  And one of the processes, it will be like the main thing.  It will control everything else.  And then we'll have workers who will do the main job.  So most of the times it's web servers.  So workers have web servers,  and then the master is controlling those web servers.  And typically we have as many processes as many CPUs we have.  So it's not like a hard rule, you can have more,  but you get low diminishing returns.  So basically to maximize the max CPU from your machine,  that's the best practice to have the same number of workers.  This is the code.  So as you can see, it's very easy.  All we are doing, we're having nif condition,  cluster.isMaster and we fork in new processes.  So.fork will create a new Node.js process using exactly the same file.  So this code is for both master and the cluster, the worker.  And then cluster is worker, that's where our web server code goes.  It can use express or just core HTTP, it doesn't matter.  And number of CPUs, that comes from the core module.  It's called os.  So this is an example of having multiple processes.  So Node, space cluster.  Oh, I have something else running.  So let's just kill everything.  Okay, so as you can see, I have four workers and they have different process ideas.  So that's a proof that it's different processes, right?  And all of them, they're listening on the same port.  So this is like a load balancing.  Basically, we have four processes listening on the same port.  Another benefit of this is that you can do zero downtime reloading.  Basically, you want to restart, you have new version of your server.  If you have multiple workers, you can kill them one by one  and replay them one by one without losing the availability, right?  So again, that forces you to think about scalability  and creating better systems early on.  So I'm going to a new window and I'm using this tool.  It's called load test.  It's similar to Apache AB or Jmeter for Java.  It's a load testing tool, but it's reading in pure Node.js.  And I will be hitting my local host.  I will have 20 second time out and I will have max 10 concurrent requests.  So now I'm going back and I see that different processes respond to my load testing requests.  You see the numbers change, right?  And it will take some time, but it will give us some numbers.  If you're running on your machines, you can tell me your numbers.  We can compare who's machine is faster.  So basically, I was able to do 800 requests.  When I'm doing it on Mac Pro, I have 2000 requests.  Okay.  So there are other libraries for doing a similar thing,  for having multiple processes.  So the advantage of Cluster is that it's core,  but other libraries, they have more features.  For example, PM2, strong loop cluster control.  I recommend using one of those unless you want to build a new PM.  PM stands for process manager.  Some of the advantages.  Again, you can have zero seconds reload downtime.  So basically, your app will be forever available, forever alive.  Another advantage of PM2, you don't need to modify your server code.  So remember that if else condition in the cluster example,  so in PM2 is just your server code.  You don't do anything with it.  And it also give you a nice...  Give you a nice...  I'll show it to you. It will give you a nice interface.  So basically, it's a table.  It shows me how many processes they have, how many online, etc.  So PM2 is a little bit nicer.  Okay.  So there are two more ways how you can launch external processes from Node.js.  For example, maybe you want to build a system where Node.js is just doing input-output operations,  but then the heavy lifting, the CPU bound tasks their outsourced to different platform or language,  maybe Python or Java.  You can do it with spawn.  Spawn, you can handle large data, it's for streams.  Fork, it's only for Node.js processes.  You've seen how it's working.  It's for something small, maybe like a Linux command to get the memory,  to get some stats because it has a buffer.  So it's not using streams, so you don't want to hit the buffer limitation.  I have some examples of how to use spawn.  So basically, you provide the name of the command, then provide the arguments.  And then again, you listen for that data.  So on data, again, event emitters.  Fork is very similar, only we don't specify that it's Node because we assume it's Node.  Okay.  So Fork is for Node, it's a narrow case of spawn.  Exec, and all three of them, they come from child underscore process.  I don't know why they named it with underscore.  Most of the modules in Node, they named with dash.  But this one of the inconsistencies that we have.  Exec has different interface.  We don't use events.  It's just a callback.  Just a callback because we don't have streams.  Okay.  So one of the other objections of why Node to use Node because it's hard to think about asynchronous code.  Our brains, they're not really evolved to think about processes running in parallel concurrently.  We're much better suited to think about synchronous code.  And then on top of that, it's also hard to debug errors in synchronous code because we lose the context.  So for example, remember that set timeout.  So when set timeout is executed in the callback, which was scheduled in the future by the previous process, we lose that context.  Let's take a look at this example.  So try catch, right?  We know what it's doing.  It's allowing us to catch errors.  So this code will work absolutely beautifully, but it's synchronous code.  There is no callbacks.  There is no events.  If we have callbacks and events, so all I did just put set timeout here and I'm throwing error in the future.  This app will crash.  So try catch is totally useless.  This code will miserably fail because the error happens in the future in the callback and we lose that context.  Okay?  This is how I feel when asynchronous error happens and no one handled it.  So how to deal with it?  Here's the list.  Checklist.  Let's go through them.  So first of all, again, eventimeter, right?  Most of the modules, virtually all of the modules, especially core modules, they would trigger error.  So you want to listen for that.  So you as a developer, when you're consuming those modules, implement this event handler.  And at least have trace, save that error message somewhere, right? Log it.  You can also use chain methods, just a different syntax, same idea.  And here I'm exiting the process.  So I'm exiting it with a code one, which means error.  Again, different approach, same idea.  So request, I am sending a request.  That request can have two types of errors.  When I'm making the request, so I need to listen to the event errors,  and then when the request is happening, then this would have an error as well inside of the callback.  This is like the mother of all the error events.  Basically, when nothing else works, have this listener on your process.  So this is like the last chance, the very last chance to do something useful, like logging your error,  tracing it, creating a notification, sending an email to your webmaster, to your dev apps.  So process that on uncut exception, always have it.  Now there is this cool thing, it's called domain.  It has absolutely nothing to do with domains like the.gov.com, like the URL domains.  I have no idea why they named it.  And they have a label, if you go to the docs, that it's softly deprecated.  It's very confusing, but basically it means that they might remove it from the core in the future.  But right now it's in the core, and even when they remove it,  it's still relatively popular with users.  It's going to live as an NPM module.  So I don't see any reasons why not to use it.  And this is the idea.  So we're creating in the main.  And our falling code, our error-prone code, it goes inside of the run.  So basically run is wrapping our bad code.  And then we're not scared of asynchronous errors.  So this code will work.  I can prove it to you.  If I go here.  So this is async error.  It failed.  And this is the domain async.  It didn't fail.  It gave me a nice error message, which I programmed there.  Okay.  Now the last thing you can do, it's number six.  It's a bonus.  And it's really cool for some of you IoT and hardware geeks.  You can build a C++ add-on and create a JavaScript interface on top of that.  Node.js works very beautifully with C++.  So create your C++ code.  This is just a boilerplate code.  I just copied it in portals of those modules.  And then what I'm doing, I'm writing the string capital one.  And then I'm exporting the method hello.  So the hello will be available in my node code when I import this module.  Then I need to create this file binding.jip,  basically it has the name of my module, my C++ add-on, and my source file.  Then I need this tool, Node.jip, which will compile everything for me.  And all I need to do is just execute those two commands.  That's it.  It's done.  It's working.  I will have this folder build-dry slash releases.  Now in my code, I'm importing that using require, remember require.  It's a global property, global method.  And that's it.  I will have my string.  So this string is coming from C++.  Okay.  So if you're interested in working with Node.js, capital one is hiring in UK,  US, and Canada, shameless plug.  And we're also using cutting edge open source technologies like React,  Kotlin, Clojure, Angular 2, et cetera.  Some of the people there working in heavily regulated industries like healthcare,  defense, finance, or capital one is finance.  So if you're interested in how we solve the problem of being in a heavily regulated industry  and working with open source, this is a talk I did at Node.interactive.  So 30-second summary.  Event emitters everywhere in the core.  It's good to know them.  Streams very, very powerful.  They basically will make you like a guru or ninja, a pro in your team if you know how to use them.  Buffers need to convert them.  Clusters, they allow you to scale.  And you can build C++ add-ons.  I almost want to join them.  It's so much fun there.  Slides.  And my contacts.  Write me an email.  For further learning, check out my blog at NodeProgram.com.  And one last thing.  This is a quote from the same blogger, codinghorror.com.  JavaScript.  It's really, really becoming popular.  Thank you.
You_Don_t_Know_Node_js_-_Azat_Mardan_0_2927.png You_Don_t_Know_Node_js_-_Azat_Mardan_2928_3707.png You_Don_t_Know_Node_js_-_Azat_Mardan_3708_4139.png You_Don_t_Know_Node_js_-_Azat_Mardan_4140_4619.png You_Don_t_Know_Node_js_-_Azat_Mardan_4620_5207.png You_Don_t_Know_Node_js_-_Azat_Mardan_5208_5291.png You_Don_t_Know_Node_js_-_Azat_Mardan_5292_6803.png You_Don_t_Know_Node_js_-_Azat_Mardan_6804_6863.png You_Don_t_Know_Node_js_-_Azat_Mardan_6864_7175.png You_Don_t_Know_Node_js_-_Azat_Mardan_7176_7235.png You_Don_t_Know_Node_js_-_Azat_Mardan_7236_7295.png You_Don_t_Know_Node_js_-_Azat_Mardan_7296_7343.png You_Don_t_Know_Node_js_-_Azat_Mardan_7344_7895.png You_Don_t_Know_Node_js_-_Azat_Mardan_7896_8087.png You_Don_t_Know_Node_js_-_Azat_Mardan_8088_8159.png You_Don_t_Know_Node_js_-_Azat_Mardan_8160_8351.png You_Don_t_Know_Node_js_-_Azat_Mardan_8352_8459.png You_Don_t_Know_Node_js_-_Azat_Mardan_8460_8939.png You_Don_t_Know_Node_js_-_Azat_Mardan_8940_8999.png You_Don_t_Know_Node_js_-_Azat_Mardan_9000_9227.png You_Don_t_Know_Node_js_-_Azat_Mardan_9228_9443.png You_Don_t_Know_Node_js_-_Azat_Mardan_9444_9527.png You_Don_t_Know_Node_js_-_Azat_Mardan_9528_9587.png You_Don_t_Know_Node_js_-_Azat_Mardan_9588_10331.png You_Don_t_Know_Node_js_-_Azat_Mardan_10332_10559.png You_Don_t_Know_Node_js_-_Azat_Mardan_10560_10607.png You_Don_t_Know_Node_js_-_Azat_Mardan_10608_10751.png You_Don_t_Know_Node_js_-_Azat_Mardan_10752_10859.png You_Don_t_Know_Node_js_-_Azat_Mardan_10860_22823.png You_Don_t_Know_Node_js_-_Azat_Mardan_22824_23099.png You_Don_t_Know_Node_js_-_Azat_Mardan_23100_23399.png You_Don_t_Know_Node_js_-_Azat_Mardan_23400_23807.png You_Don_t_Know_Node_js_-_Azat_Mardan_23808_40283.png You_Don_t_Know_Node_js_-_Azat_Mardan_40284_46283.png You_Don_t_Know_Node_js_-_Azat_Mardan_46284_49655.png You_Don_t_Know_Node_js_-_Azat_Mardan_49656_53459.png You_Don_t_Know_Node_js_-_Azat_Mardan_53460_55199.png You_Don_t_Know_Node_js_-_Azat_Mardan_55200_55247.png You_Don_t_Know_Node_js_-_Azat_Mardan_55248_62855.png You_Don_t_Know_Node_js_-_Azat_Mardan_62856_65591.png You_Don_t_Know_Node_js_-_Azat_Mardan_65592_67583.png You_Don_t_Know_Node_js_-_Azat_Mardan_67584_68255.png You_Don_t_Know_Node_js_-_Azat_Mardan_68256_69947.png You_Don_t_Know_Node_js_-_Azat_Mardan_69948_84359.png You_Don_t_Know_Node_js_-_Azat_Mardan_84360_87419.png You_Don_t_Know_Node_js_-_Azat_Mardan_87420_89446.png
Hello. Hello, everyone. Welcome to the Node.js presentation. You don't know Node. We will go over five core features. It's not going to be about a fancy framework, cutting edge advanced stuff like promises or anything like that. It's going to be about the core fundamental, the basics. So even if you work with Node.js, some build tools for friend development, you might not know about these core features. So let's get started. And this is a hands-on presentation. So I want you to take out your laptops, download the code. I have it on GitHub, the code and the slides and the PDFs, and follow the demos that I will be showing you on your computers. And turn off all the IMs and slacks and notifications. They're doing really well there. Maybe we can beat them in terms of making sounds later. Can I have some little bit more volume in my mind? Thank you. So take a picture, get the slides and follow me with the code examples. So first of all, I want to remind you why we're here, why we're coming to this type of conferences and why we're doing software. So I want to put this big statement. We write software, we write apps to make our lives and life of other people better, basically, because software changes lives. Software is pretty much everywhere. So is that my computer? Did you have a different adapter? Oh, the different, the power. Do you know where is it? Oh, okay. That would make sense. Yeah. No. 40. Let me try to mirror. This is all summing up. No, too unworth. It used to be good, right? Let me try. Yeah, it's all like that. You can try another cable, but it's so strange because now it's because it's perfect. The picture is good down there. It was completely stable in the time there. But then, on the slide number 3, the picture started to fly on the project. So, it's stable. What? The fuck? Yeah, this is stable. But this, I don't have a picture now. Yeah, it's stable. Yeah, it's stable. So, that's actually perfect because you have time to download the slides. Yeah, it's stable. Yeah, it's stable. Yeah, it was there. Now it's there. 50. Thank you. Okay, so, start over again. Welcome to YouDon'tKnowNotJS. This is a hands-on presentation. And in case you missed it the first time, this is the repository where you can get the slides and the code. So, this presentation will have a lot of code examples. I want you to have the code so you can later refer to it. So, we're building software and we're trying to use better technologies, better frameworks to improve the lives, improve the community, the lives of our loved ones, the lives in general of other people, right? Software is becoming everywhere. And with this big kind of a goal, I will introduce myself. I published and wrote 12 books, not counting Chinese, Korean, and Russian translations. The most popular ones are Practical Node.js and ProExpress.js. You might have seen them on Amazon.com. They were on the first page if you search for Node.js. My new book, React Quickly, it's coming in a few months. That will be about React.js. You can follow me on Twitter at azad underscore co. I tweet about JavaScript and Node.js mostly. And I also have a blog. And if you have questions after this conference, you can reach me at my email. Hi, at azad.co. I work at Capital One. It's one of the US top 10 banks in the financial industry. I'll talk about it more in the next slide. Before that, I worked at startups, US federal government agencies. I would like to highlight my experience with DocuSign and StoryFi. That's where I got to use Node.js at a pretty relatively large scale. And I saw from my own eyes that Node.js is, how Node.js is beneficial in terms of having a generalistic approach and in terms of performance and having a better developmental experience. They also teach at Nodeprogram.com, where you can find live in-person trainings in Node.js as well as online trainings. So Capital One, it's in the top 10 US banks. We're also in the UK and Canada. And in US, we're famous for our Visigoth commercials, but most people think it's Vikings. Some of them are funny. So why use Node.js? So let's start with basics, right? I want to give you some ammo. So when you go to your work on Monday next week, you have something to tell your coworkers and your team leads in order to convince them, hey, maybe we should use Node.js for our next project. So the biggest selling point of Node.js is its performance. So basically, it's faster. And it's faster because it optimizes the input and output bound processes. So most of the times, input and output is the most expensive tasks that we have compared to CPU bound tasks. So if we can optimize for them, that will give us a good boost in performance. So Node.js has this thing, it's called non-blocking I.O. How many of you already familiar with this term? Raise your hand. OK, so like half of the audience. So for the rest of the half, this will be beneficial. So non-blocking, this diagram shows you high level overview how it's implemented in Node.js. So we have the thing it's called Event Loop. Event Loop, it's always looking for something to execute. So basically, it's never blocked or almost never blocked. And it allows our system, our Node.js-based system to process multiple requests pretty much in parallel, pretty much at the same time. And then Event Loop delegates those tasks, those heavy input-output tasks, like reading from a file system or writing to a database, or the most popular thing that we like to do when we're building web apps is to make HTTP requests to APIs or third-party services. So those all time-consuming tasks, Event Loop delegates them. Let's go a little bit more low level. This is Java code. How many of you Java developers here? OK, just about 20%, not that many. Most of the time I'm teaching Node.js to Java developers. But you can guess what this means, right? Thread.sleep, it's putting the entire process to sleep. So nothing will happen on this particular thread unless the timer expires, right? So the entire thing will be basically useless. OK, we will see step one, step two, and then step three. Contrast that code with this Node.js. So now we have fancy callbacks. So set time out, it takes a callback, which is a function definition. It's anonymous function definition. It doesn't have a name. And basically tells, OK, schedule that in the future. Don't execute it now. And the future will happen at one second, so 1,000 milliseconds. But the good thing about this code and this Node.js implementation is that set timeout is not blocking. So Node.js, this process will continue to execute. So we will see step one, step two, and then after one second we will see step three. OK, and then if we have more code, Node.js will still continue to execute that. So the result of this would be step one, step two, and then step four, not step three. And then after one second we will see step three and step five. So if you're familiar with how callbacks, Dread, jQuery, or promises in Angular framework works on the browser, this is a very similar approach basically. We're scheduling something in the future. But the benefit is that our process is not blocked. We can process a lot of requests. So putting processes to sleep, that's not very useful. Most of the time we are using, we're building web services. But that analogy, set timeout, that's exactly how Node.js is implementing a synchronous input output. So it could be writing to the database or it could be making a request. Let's take a look at this diagram. So this is a blocking system, maybe written in Python or Java. And we have four clients. Please take this, it must be important. We have four clients, they submit requests. So the client at the bottom, he or she, have three requests. But each request is blocked by the previous request, because it's hitting that one thread. Compare it to standing in line for a coffee. We have that pretty cool Twilio booth downstairs at the expo. I saw a lot of people standing in line, 20 people, maybe 10, 20 people during the breaks. So that's your typical blocking system, because you have to wait for the people in front of you to order your drink and to get your drink. In Node.js we have a non-blocking system. This is a diagram, again we have that event loop, which is delegating the processes. And event loop is always available, or almost always available. Compare that to the same Twilio booth with a coffee bar, but they have that option where you can text, or Facebook your drink, and then you can walk around, talk with other people, and they will text you back when the drink is ready. So this is much more enjoyable experience than waiting in line, and not able to do other things. So the texting to get your coffee, that's non-blocking, that's asynchronous. That's what we usually want. This quote is from CordingHorror.com, it's a pretty famous blog. I would recommend subscribing to it. So basically the blocking system, they have to be multi-threaded, because each thread is blocked, but multi-threading could be very dangerous if you don't know how to use it. You can get racing conditions, you need to know how to synchronize the data between multiple threads. You might have deadlocks, etc. It can really blow in your face. And yeah, blocking system, they have to be multi-threaded. So Node.js, by design, the designers of Node.js, the original creators, they decided, we're not going to create multiple threads, we just have single thread. And this is actually a beautiful thing, because with a single thread, you can avoid all that complexity and work in a pure asynchronous and non-blocking environment. And that's one of the concerns people tell, oh hey, Node.js is single-threaded, it's not going to perform well. But that actually forces you to think about scalability early on, and that'll show you how to scale your system as well. But before we do that, it's still possible to write blocking code in Node.js, right? In Node.js, it's a platform that's not going to prevent you from writing the blocking code. So you need to be very careful how you implement your Node applications. For example, this is a CPU intensive task that iterates many times, and on my machine it was taking from 100 to 1000 milliseconds. Obviously, it's a bad code, you don't want to do that in Node.js. Or at least you don't want to have one process to do CPU intensive tasks. Sometimes, most of the times, our blocking code is not so obvious. Most of the times, it's buried under some module. So FS is a file system module to work with file systems and directories. And in this example, I'm using synchronous methods. So we don't see that for loop, which revolves, but I know that it's a synchronous. And the results would be accounts, then hello Ruby, and then IPs, and then hello Node. So just as in your normal traditional blocking language like Python or Ruby or Java, it would be executed in the order in which you have statements. So no surprises here, but basically it will be a blocking code. This is a non-blocking version of exactly the same functionality. So FS has two types of methods. They're like siblings. They have eval siblings, which is synchronous, and they have the good siblings. This is a good sibling, asynchronous method, read file. And immediately you can see the difference in terms of how I implement it. I use callbacks instead of using an assignment. I cannot use an assignment because the data is not available. The data will be available only in the callback. So the contents will be available only in the callback. It will be defined. But then I might have a racing condition between what data I will have the first, accounts or IPs. But the data will be always after displaying hello Ruby and hello Node. So far so good. And feel free to ask questions in the middle. We're not going to have a formal Q&A at the end. Why bother having asynchronous? Why bother? So the question is why bother to have asynchronous version? Because without having asynchronous code, you will be blocking your process and you will lose that benefit of Node.js. Sorry, why bother having the synchronous? Why bother having the reverse? So why bother to have the synchronous code? It's there. Sometimes in a very edge case scenario you might need it. For example, you're starting a server and you're reading from a configuration file. So it doesn't make sense to start the server at all if you cannot get the configuration settings like port number or IP addresses. So in some edge case scenarios, it's there, it's for you. But most of the modules, they implement asynchronous interfaces. So Node typically is much faster than other platforms. Now all of the benchmarks, they don't really test your business logic. So we don't have like exact data, but mining total experience, working with teams and reading blog posts from PayPal, eBay, other big companies, Uber also runs everything on Node.js. Usually it tells that they have a dramatic improvement in performance, even like order of magnitude, like 10 times or 20 times faster. So that's all good, right? We get the performance, our company spends less money on the servers. That's all wonderful. But how many of you actually hid the performance limitations using traditional languages like Java or Python? So probably not many, right? I'm in the same boat. So most of the apps I'm building, unless it's for DacuSynos, or StoryFi, I don't experience that issue. Like remember Twitter in the early days, you would see that whale, so they had that performance issue, right? But I'm not experiencing them. So for me, my personal, my favorite benefit of Node.js is that you can have one language across your entire stack. So we have JavaScript on the browser, right? It's here to stay, it's not going to go away. We have a new standard now, we have six and seven, et cetera, so it's evolving, it's becoming better. Then you need to know another language, like Python or Java, for the backend. And then for database, if you're using traditional SQL database, you need to know SQL, which is a complex language in itself. You have all those joins, and you need to know the syntax, right? So three languages just to build your application, but then you need to know HTTP, you need to know CSS, you need to know HTML, and so a lot of other technologies, right? Having Node.js on the backend eliminates at least one language. And then if you use a Node SQL database like MongoDB, which I really, really love, then you can eliminate one more language. So having one language allows me to think faster, because I'm not switching the context. And I'm not making stupid mistakes like, oh, I forgot a semicolon here, or I need a double-quad instead of a single-quad, because it's a different language. I'm reusing my code, so templates, utility libraries from the browser, I can reuse them. And then I'm remembering those interfaces, I'm remembering how to call a method faster, I'm remembering all those methods and properties, because I'm using them twice more frequently. So that's a good thing. That's my personal favorite thing about Node.js. And for you, if you're learning Node.js, but you know JavaScript, browser JavaScript really well, it's probably take you like a weekend to get started, to get to the comfortable level with Node.js, because most of Node.js, it's your browser JavaScript. So we have the same array methods, the same string methods, so it's very, very, very great. But Node.js is not triple equals browser JavaScript. It's not completely same as browser JavaScript, right? So what are the difference? So we don't have window object. Obviously, there's no windows on the server side. We also have more power. We can get the environmental information, we can work with file systems, et cetera. So there is this thing that's called global. If there are lowercase or capitalized, that will give us a lot of properties and a few methods, those extra benefits, those extra things that we're lacking in browser JavaScript. For example, filename or dirname, that will give you the absolute path to the filename, the currently running script, or it will give you just the path without the filename. So it could be convenient when you need to know what is the location. Then we have native modules in Node.js. We don't have modules in browser. So even if you're using, yes, six modules, you have to rely on some transpiler like Babel or System.js. So in Node.js, the problem is solved. It's common JS syntax. It's beautiful. So module, that's how you export and requires that how you import a module in Node.js. It's all native. A few other things. How do I get a command line interface input? For example, I'm building a new grant or webpack tool. How do I get information about my system, like versions or platform? How do I read environmental variables, for example, API keys or passwords? There is this thing. It's called global.process, or you can just access it by process. Every global property is accessible without the prefix. You can either type explicitly, global, or implicitly you can just call that name process. And it's a really big object. I will just highlight some of the properties. For example, PID will get you the process ID. Versions, you can get versions of pretty much everything. For example, like V8 engine version. You can get the architecture. Arc V, that's how we get the input from the command line. And EMV, that's where your environment, that's where your API keys, you can access them once you're ready to deploy the production. So don't store your passwords in your source code. And don't create config.json, because you can use environmental variables. Oh, we have issues again. The ghost of demo. Okay, so it's a good thing to have some type of monitoring when you're building a web server especially. So you can get uptime. It's how long your process is running, and then the memory usage. CWD, that's the current warranty directory. And then we can exit the process, or we can kill another process from Node.js. So I hope you can start understanding that Node.js gives you more power. Obviously in the browser, we don't have that power because you don't want to go to a website, and that website can create a file on your file system, right? Okay, so let's move into Node.js, some of the Node.js patterns. How many of you really understand and like callbacks? Oh, wow, it's like 40%. Really cool. I like callbacks until I hit callback hell. There's even a website. It's called callbackhell.com. And once you're inside of that nested pyramid of doom, or sometimes it's called nested approach, it might be tricky to really understand what is happening. So callbacks could be, especially in large projects, they're not very scalable in the developmental sense, meaning when you add more developers on a project, it can become harder to understand that code. And sometimes nested callbacks can lead to problems. So we have advanced patterns like promises and generators in the sync await. I'm not going to talk about them because they're not part of the core. So core modules, they don't use promises, right? Version 6 of Node.js, it comes with promises without any flags. You have the promises, standard ES6 promises. But when you use modules, you have only two options, callbacks or events. So let's focus on events because callbacks, most of the people are familiar with them. Basically events, they're your standard observer pattern. So we have a subject, we have observers or event listeners, and then we have someone else triggering those events. This is how you create it. So you require events, which is a core module, you don't need any NPM for this, and then you create a new object. So this will be our subject, emitter, and we're using prototypical instantiating patterns, so we need to say a new keyword. And we define our event listener, our observer, basically. The way we define it is very easy. We provide a string, and then we provide a function. So when the string is the name of the event, it will be triggered, this function will be executed. And we can have multiple events with the same name or with a different name as well. So let's consider a little bit more interesting example. So I have two events, but they have the same name. So what will happen, they will be triggered in the order in which I define them. So the last line, immediate knock, will basically trigger that event, and then I would see who's there and go away. So immediately you can understand the benefits comparing to callbacks. In callbacks we have just one function that is executed at the end. Here with events you can have multiple functions. You can execute them in the middle, in the end, it doesn't matter, it's up to you. So you get more power. Now, this is a more realistic example. Let's say we have a module, it's called job.js, and the code is in that GitHub repository. But the job needs to be customizable. So at the end we want to put some custom logic, but we don't want to hard-code it in the module. We want the consumers, so developers, who use the module to give the power to customize what will happen at the end. So we can use events for this. The way we do it, we basically emit an event, and then in our documentation we tell developers, if you want to have that custom ending, go ahead and implement an event listener because we will be emitting an event. And then developers, let's say I'm a developer, I want to implement the weekly job. So it's a weekly newsletter, and then I'm creating this event listener because I know the done will be emitted. If I don't have that event listener, that's cool, okay. That's also okay. That's also cool because it's not going to crash. It's not like, oh, I'm defined, right? So this is a powerful pattern, how you can basically create modules and abstract some of the code by still giving the flexibility to developers, developers who use your modules. Some of the useful methods, for example, we can remove event listeners. We cannot do that with callbacks. We can specify, hey, execute it just once, right? With once. It's another advantage. Some of the other node patterns, I wrote this blog post, node patterns from callbacks to observers. I also talk about modules and have their singletons to check it out. Okay, so let's move on. Problems with large data. So it's slow because you have to wait for all data to load. There's also buffer limitation in Node.js. One gigabyte, that's it. You're done. The last one is just a joke. We can use streams. Streams are, again, it's a core module in Node.js. It allows us for continuous consumption of the data. So we can transform it. We can do something with the data without waiting for the whole chunk of the data to load. Okay. We have four types of streams. We have writable, readable, duplex and transform. Duplex, it means it's both writable and readable, and then the transform means it's just transforming. Streams already inherit from Eventimator, so we can use that interface to implement our streams. Streams are everywhere, especially in the core, not just core. We can use streams for HTTP requests and response. We can use them for standard input and output for reading and writing to a file. This is an example of a readable stream. I don't want to have to name one of that. And if you're following on your machines, it's std in.js. Can you see it? Probably not. So basically each line, each new string, it's a chunk of data, and I'm processing it as I go. This is how it looks like in the code. So basically process.std in. I get my readable stream, then I execute Resume and set the encoding, and then I'm listening for the onData. So remember the previous slides with the Ventimator, so very similar. We create this event listener onData. So onData will happen each time I have a new line on my terminal, and I can start processing that text. And then once I'm done, it's good to have also a listener for the end event. Okay. So demo, we did this. For readable, we also have a different approach. We can use read method. So read method, it's synchronous, but it's okay for it to be synchronous because it's really just a chunk of data. It's just one line. So imagine that large data file, we're processing it line by line. And when it's null, that means that it's over. Basically, the stream is over, so we can have a while loop and compare it to the null. Example of a writable stream, so std out, that would be the output of your node script. And there is a write operation. We use it like this, process.std out.write. So this would be an analogous for console.log. In fact, console.log is using something similar. So we're writing to our output stream. What about HTTP? Because most of the times we're building HTTP servers, right? That's where streams really, really shine because we don't want the consumers of either our API or our web app to wait for too long, right? So in this example, I have a server and I'm getting that request object. So your typical hello world type of server, very minimalistic. But then, instead of waiting for entire data, I'm creating an event listener on data and transform. Let's imagine it's a function defined somewhere else. Maybe it's a module. But the key here is that the chunk is available right away. I don't have to wait for the entire one gigabyte file to load. And then at the end, I can parse it. I can do something else with it. There's also pipe interface. Pipe is very similar to the pipes, double pipes in your Linux terminal command or command prompt in Windows. So basically, we're taking one stream and piping it to another, then piping it to another. So we're passing the data. So r.pipe, z.pipe, w, we'll read from a file, compress it, and then write to a different file. All without having any buffers. Speaking of buffers, buffers is a special data type. We don't have it in the browser JavaScript. There is a rate buffers in the S6, which is kind of similar. And the way we create buffers, we can execute that from. This has been just recently changed in version 6. And version 5, you would use a different approach. And I have a link to the documentation as well. If you're new to buffers, sometimes you might see, when you're expecting a stream, you might see something like this, which looks like an array, but it has numbers. That means you didn't convert from buffer to a stream. You can easily convert by specifying and encoding. So by default, when you're reading or writing to a file, or it's a request, it's a buffer. Especially if you're not using any frameworks, it will be buffer. So you need to convert it. This is how you can do it. By default, if you just say toString, it will use UTF-8. So remember FS from a few slides back. So when we're reading from a file, the data, it's a buffer by default. Without this example, it doesn't have the encoding. Okay, so server stream, it's a small express JS server that I've written. And I'm launching a node space server dash stream. So what it's doing is basically it has two endpoints. One endpoint is using stream, and another is not using stream. So let's go to the one that is not using stream. And it's a huge infographic about Capital One. It's like 8 megabytes or something like that. And I'm going to the DevTools. I'm going to Network. And I'm clicking on the response. Actually, I'm clicking on the header, and I don't know if you can see. So it's 6.57 milliseconds. So let's remember that number. So I'm going to go to Network, click on all. By the way, I love DevTools. Such a nice thing. How many of you like DevTools? Yeah. So it's 1.4 milliseconds. So response time is shorter. Sometimes I get it order of magnitude shorter. Yeah, so right now it's 0.42. Okay. And this was, this is 6 milliseconds. This is 0.4 milliseconds. Okay, so response time. This is not like entire infographic. That's only the first byte. But that's enough for users to start seeing something, right? So that's the benefit of using streams. I also have two more endpoints that they use a different interface, but that is the same. Streams are faster. Some good stream resources. There's automated workshop, which have exercises you can go through them, and it will test your answers. So it's a great tool to learn streams. And there's also a stream hands book. Okay, so going back to having a single system, right? Node.js, it's single threaded, but I like to flip it around and make it an advantage versus having it as a disadvantage. How you can do it. So basically it forces developers to think about scalability early on. Most of us, we build microservices, we build distributed systems, right? So if you're using Java, it's like, oh, it's a multi-threaded, I don't need to worry about it with Node.js. Oh, I'm starting a new project. I need to start thinking about scalability, how it's going to work across multiple stateless servers early on. Luckily, there is a core module, it's called cluster. The idea is that we have multiple processes. So we can spawn multiple processes with this core module. And one of the processes, it will be like the main thing. It will control everything else. And then we'll have workers who will do the main job. So most of the times it's web servers. So workers have web servers, and then the master is controlling those web servers. And typically we have as many processes as many CPUs we have. So it's not like a hard rule, you can have more, but you get low diminishing returns. So basically to maximize the max CPU from your machine, that's the best practice to have the same number of workers. This is the code. So as you can see, it's very easy. All we are doing, we're having nif condition, cluster.isMaster and we fork in new processes. So.fork will create a new Node.js process using exactly the same file. So this code is for both master and the cluster, the worker. And then cluster is worker, that's where our web server code goes. It can use express or just core HTTP, it doesn't matter. And number of CPUs, that comes from the core module. It's called os. So this is an example of having multiple processes. So Node, space cluster. Oh, I have something else running. So let's just kill everything. Okay, so as you can see, I have four workers and they have different process ideas. So that's a proof that it's different processes, right? And all of them, they're listening on the same port. So this is like a load balancing. Basically, we have four processes listening on the same port. Another benefit of this is that you can do zero downtime reloading. Basically, you want to restart, you have new version of your server. If you have multiple workers, you can kill them one by one and replay them one by one without losing the availability, right? So again, that forces you to think about scalability and creating better systems early on. So I'm going to a new window and I'm using this tool. It's called load test. It's similar to Apache AB or Jmeter for Java. It's a load testing tool, but it's reading in pure Node.js. And I will be hitting my local host. I will have 20 second time out and I will have max 10 concurrent requests. So now I'm going back and I see that different processes respond to my load testing requests. You see the numbers change, right? And it will take some time, but it will give us some numbers. If you're running on your machines, you can tell me your numbers. We can compare who's machine is faster. So basically, I was able to do 800 requests. When I'm doing it on Mac Pro, I have 2000 requests. Okay. So there are other libraries for doing a similar thing, for having multiple processes. So the advantage of Cluster is that it's core, but other libraries, they have more features. For example, PM2, strong loop cluster control. I recommend using one of those unless you want to build a new PM. PM stands for process manager. Some of the advantages. Again, you can have zero seconds reload downtime. So basically, your app will be forever available, forever alive. Another advantage of PM2, you don't need to modify your server code. So remember that if else condition in the cluster example, so in PM2 is just your server code. You don't do anything with it. And it also give you a nice... Give you a nice... I'll show it to you. It will give you a nice interface. So basically, it's a table. It shows me how many processes they have, how many online, etc. So PM2 is a little bit nicer. Okay. So there are two more ways how you can launch external processes from Node.js. For example, maybe you want to build a system where Node.js is just doing input-output operations, but then the heavy lifting, the CPU bound tasks their outsourced to different platform or language, maybe Python or Java. You can do it with spawn. Spawn, you can handle large data, it's for streams. Fork, it's only for Node.js processes. You've seen how it's working. It's for something small, maybe like a Linux command to get the memory, to get some stats because it has a buffer. So it's not using streams, so you don't want to hit the buffer limitation. I have some examples of how to use spawn. So basically, you provide the name of the command, then provide the arguments. And then again, you listen for that data. So on data, again, event emitters. Fork is very similar, only we don't specify that it's Node because we assume it's Node. Okay. So Fork is for Node, it's a narrow case of spawn. Exec, and all three of them, they come from child underscore process. I don't know why they named it with underscore. Most of the modules in Node, they named with dash. But this one of the inconsistencies that we have. Exec has different interface. We don't use events. It's just a callback. Just a callback because we don't have streams. Okay. So one of the other objections of why Node to use Node because it's hard to think about asynchronous code. Our brains, they're not really evolved to think about processes running in parallel concurrently. We're much better suited to think about synchronous code. And then on top of that, it's also hard to debug errors in synchronous code because we lose the context. So for example, remember that set timeout. So when set timeout is executed in the callback, which was scheduled in the future by the previous process, we lose that context. Let's take a look at this example. So try catch, right? We know what it's doing. It's allowing us to catch errors. So this code will work absolutely beautifully, but it's synchronous code. There is no callbacks. There is no events. If we have callbacks and events, so all I did just put set timeout here and I'm throwing error in the future. This app will crash. So try catch is totally useless. This code will miserably fail because the error happens in the future in the callback and we lose that context. Okay? This is how I feel when asynchronous error happens and no one handled it. So how to deal with it? Here's the list. Checklist. Let's go through them. So first of all, again, eventimeter, right? Most of the modules, virtually all of the modules, especially core modules, they would trigger error. So you want to listen for that. So you as a developer, when you're consuming those modules, implement this event handler. And at least have trace, save that error message somewhere, right? Log it. You can also use chain methods, just a different syntax, same idea. And here I'm exiting the process. So I'm exiting it with a code one, which means error. Again, different approach, same idea. So request, I am sending a request. That request can have two types of errors. When I'm making the request, so I need to listen to the event errors, and then when the request is happening, then this would have an error as well inside of the callback. This is like the mother of all the error events. Basically, when nothing else works, have this listener on your process. So this is like the last chance, the very last chance to do something useful, like logging your error, tracing it, creating a notification, sending an email to your webmaster, to your dev apps. So process that on uncut exception, always have it. Now there is this cool thing, it's called domain. It has absolutely nothing to do with domains like the.gov.com, like the URL domains. I have no idea why they named it. And they have a label, if you go to the docs, that it's softly deprecated. It's very confusing, but basically it means that they might remove it from the core in the future. But right now it's in the core, and even when they remove it, it's still relatively popular with users. It's going to live as an NPM module. So I don't see any reasons why not to use it. And this is the idea. So we're creating in the main. And our falling code, our error-prone code, it goes inside of the run. So basically run is wrapping our bad code. And then we're not scared of asynchronous errors. So this code will work. I can prove it to you. If I go here. So this is async error. It failed. And this is the domain async. It didn't fail. It gave me a nice error message, which I programmed there. Okay. Now the last thing you can do, it's number six. It's a bonus. And it's really cool for some of you IoT and hardware geeks. You can build a C++ add-on and create a JavaScript interface on top of that. Node.js works very beautifully with C++. So create your C++ code. This is just a boilerplate code. I just copied it in portals of those modules. And then what I'm doing, I'm writing the string capital one. And then I'm exporting the method hello. So the hello will be available in my node code when I import this module. Then I need to create this file binding.jip, basically it has the name of my module, my C++ add-on, and my source file. Then I need this tool, Node.jip, which will compile everything for me. And all I need to do is just execute those two commands. That's it. It's done. It's working. I will have this folder build-dry slash releases. Now in my code, I'm importing that using require, remember require. It's a global property, global method. And that's it. I will have my string. So this string is coming from C++. Okay. So if you're interested in working with Node.js, capital one is hiring in UK, US, and Canada, shameless plug. And we're also using cutting edge open source technologies like React, Kotlin, Clojure, Angular 2, et cetera. Some of the people there working in heavily regulated industries like healthcare, defense, finance, or capital one is finance. So if you're interested in how we solve the problem of being in a heavily regulated industry and working with open source, this is a talk I did at Node.interactive. So 30-second summary. Event emitters everywhere in the core. It's good to know them. Streams very, very powerful. They basically will make you like a guru or ninja, a pro in your team if you know how to use them. Buffers need to convert them. Clusters, they allow you to scale. And you can build C++ add-ons. I almost want to join them. It's so much fun there. Slides. And my contacts. Write me an email. For further learning, check out my blog at NodeProgram.com. And one last thing. This is a quote from the same blogger, codinghorror.com. JavaScript. It's really, really becoming popular. Thank you.
Hello. Hello, everyone. Welcome to the Node.js presentation. You don't know Node. We will go the different, the power. Do you know where is the slides and the code. So, this presentation own eyes that Node.js is, how Node.js is called non-blocking I.O. How many of you already it's called Event Loop. Event Loop, it's always system or writing to a database, or the most building web apps is to make HTTP requests to not able to do other things. So the texting to file system module to work with file systems and cannot use an assignment because the data is not you. But most of the modules, they implement on the server side. We also have more power. We called global.process, or you can just access it Okay, so let's move into Node.js, some of the Node.js patterns. How many of you really project, it can become harder to understand that powerful pattern, how you can basically create Streams are, again, it's a core module in are everywhere, especially in the core, not just of similar. And the way we create buffers, we can this, which looks like an array, but it has have as many processes as many CPUs we have. So and I'm using this tool. It's called load test. will give us some numbers. If you're running on again, event emitters. Fork is very similar, only about synchronous code. And then on top of that, C++. So create your C++ code. This is just a