You Don't Know Node.js
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51867 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201661 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
Core dumpPresentation of a groupAsynchronous Transfer ModeSlide ruleCodeProbability density functionMultilaterationCore dumpPresentation of a groupMetropolitan area networkLaptopCodeSlide ruleSoftware developerVolume (thermodynamics)BitNeuroinformatikInformation managementTerm (mathematics)RandomizationDemo (music)Computer virusXMLComputer animation
01:20
Video gameWritingStatement (computer science)Video gameMobile appType theoryMathematicsSoftwareDifferent (Kate Ryan album)Power (physics)Computer animation
02:27
Video gameComputer animation
03:17
Video gameComputer animationProgram flowchart
04:03
Link (knot theory)Right angleComputer animationProgram flowchart
04:51
Video gameComputer animation
05:43
Core dumpRow (database)Internet forumNetwork topologyFrame problemTrailBitSlide ruleComputer animation
06:36
Table (information)Point (geometry)Multiplication signSlide ruleComputer animation
09:20
Computer animation
10:07
Core dumpSlide ruleCodeProbability density functionVideo gameExecution unitTwitterEmailBlogHacker (term)Task (computing)Function (mathematics)outputProgrammschleifeSystem programmingJava appletThread (computing)Process (computing)Video game consoleClient (computing)Projective planeThread (computing)Order (biology)Wave packetComa BerenicesHypermediaSlide ruleRepository (publishing)Presentation of a groupBuildingTwitterMultiplication signSystem programmingPoint (geometry)outputVideo gameTask (computing)Function (mathematics)Frame problemRight angleWeb pageProcess (computing)Product (business)Translation (relic)1 (number)Functional (mathematics)Level (video gaming)DiagramDatabaseWeb browserCodeServer (computing)BlogJava appletEvent horizonWeb serviceFile systemSoftware developer2 (number)Line (geometry)ImplementationGreatest elementSystem callScheduling (computing)AnalogyResultantSynchronizationDatabase normalizationBlock (periodic table)Computer programmingTerm (mathematics)Medical imagingProgrammschleifeBitSoftwareSoftware frameworkContrast (vision)Set (mathematics)MultiplicationWeb applicationCASE <Informatik>Lattice (order)Computer animation
17:55
Event horizonIntrusion detection systemProgrammschleifeMathematical singularitySoftwareSystem programmingCodeVertex (graph theory)Content (media)LogarithmError messageComputing platformLine (geometry)System programmingControl flowRight angle2 (number)Reading (process)Thread (computing)Virtual machineBlogFile systemEvent horizonCASE <Informatik>Process (computing)Condition numberReverse engineeringSystem callComputing platformNormal (geometry)Term (mathematics)TorusBlock (periodic table)ResultantCore dumpGodProgrammschleifeMultiplication signCodeOrder (biology)Complex (psychology)Server (computing)Formal languageTask (computing)Module (mathematics)Set (mathematics)Configuration spaceForcing (mathematics)Computer fileIntegrated development environmentMultiplicationAreaNumberComputing platformFacebookCartesian coordinate systemComa BerenicesDiagramComputer configurationContent (media)Address spaceType theoryDifferent (Kate Ryan album)Goodness of fitFunctional (mathematics)LogicRevision controlBit rateBenchmarkIP addressScalabilityPhysical systemSynchronizationDirectory serviceInterface (computing)Computer animation
23:53
Computing platformMobile appSystem programmingScripting languageJava appletFormal languageCodeString (computer science)Function (mathematics)Object (grammar)Web browserVariable (mathematics)Module (mathematics)Common Language InfrastructureoutputInformationComputing platformRead-only memoryRevision controlReading (process)Process (computing)FingerprintContext awarenessInformationSingle-precision floating-point formatMultiplication signComputer fileReading (process)Process (computing)Module (mathematics)Revision controlUtility softwareCategory of beingLimit (category theory)Library (computing)Bookmark (World Wide Web)Integrated development environmentKey (cryptography)Formal languageJava appletTwitterMobile appWindowType theoryFront and back endsObject (grammar)Level (video gaming)outputVariable (mathematics)Web browserOrder (biology)Standard deviationBlogCASE <Informatik>PasswordConfiguration spaceDatabaseString (computer science)Complex (psychology)Data storage deviceSource codeDifferent (Kate Ryan album)System callRight angleFamilyLocal ringPower (physics)Server (computing)BuildingUniform resource locatorProduct (business)CodeState of matterComputer architectureComputing platformFile systemSequelScripting languageSystem programmingWeb 2.0Order of magnitudeSubject indexingMathematicsInterface (computing)Group actionComputer animation
29:30
Process (computing)Electric generatorEvent horizonCore dumpModul <Datentyp>State observerSoftware design patternString (computer science)Vertex (graph theory)Sanitary sewerLimit (category theory)Continuous functionType theoryDuplex (telecommunications)Singuläres IntegralDependent and independent variablesStandard deviationProcess (computing)Server (computing)Multiplication signWeb 2.0BuildingType theoryOcean currentDirectory serviceWeb browserInterface (computing)Ferry CorstenStreaming mediaComputer fileSystem programmingStandard deviationModule (mathematics)Electric generatorPower (physics)WebsiteCodeSoftware design patternEvent horizonPattern languageCore dumpSoftware developerProjective planeString (computer science)State observerFunctional (mathematics)DeterminismSemiconductor memoryVertex (graph theory)Demo (music)Revision controlFocus (optics)MereologyBitDependent and independent variablesPrototypeImplementationArithmetic meanRepository (publishing)LogicOrder (biology)Reading (process)outputNewsletterBlogWordComputer configurationRight angleLine (geometry)System callRadical (chemistry)40 (number)Crash (computing)Duplex (telecommunications)Medical imagingBuffer solutionFunction (mathematics)Limit (category theory)File systemMetreFlagComputer animation
36:41
Beer steinProcess (computing)Event horizonFunction (mathematics)LogarithmStreaming mediaStandard deviationoutputInterface (computing)Reading (process)Military operationServer (computing)Singuläres IntegralParsingBinary codeCluster samplingData bufferASCIIData conversionDefault (computer science)Error messageDemo (music)Vertex (graph theory)Stack (abstract data type)Adventure gameInstallation artScale (map)System programmingBefehlsprozessorNumberCodeCodeLine (geometry)Virtual machineDeadlockRight angleReading (process)Software frameworkDefault (computer science)Object (grammar)Server (computing)Power (physics)SoftwarePoint (geometry)Logic gateEmailComputer file2 (number)Well-formed formulaWeb 2.0Single-precision floating-point formatGoodness of fitDependent and independent variablesThread (computing)System programmingProcess (computing)Physical lawScaling (geometry)Streaming mediaRule of inferenceScalabilityCore dumpPhysical systemSoftware developerForcing (mathematics)Projective planeNumberExpressionDoubling the cubeModule (mathematics)Response time (technology)Musical ensembleFunction (mathematics)Type theoryMultiplication signWeb applicationTransformation (genetics)Social classCondition numberScripting languageOperator (mathematics)Functional (mathematics)Interface (computing)Link (knot theory)Buffer solutionMetreOrder of magnitudeWindowWeb browserString (computer science)Radical (chemistry)Event horizonRevision controlSimilarity (geometry)RAIDSpeech synthesisProgrammschleifeSlide ruleMaxima and minimaVideo game consoleEntire functionKey (cryptography)BefehlsprozessorData compressionSpacetimeRandom matrixVertex (graph theory)Java appletData typeComputer animation
46:38
Process (computing)CodeEvent horizonError messageVertex (graph theory)Message passingGame theoryDependent and independent variablesInformationRule of inferenceInferenceNormed vector spaceCore dumpControl flowAxiom of choiceMetric systemServer (computing)Demo (music)ExpressionStatisticsTerm (mathematics)Read-only memoryDemonAsynchronous Transfer ModeProcess (computing)Game controllerSoftware testingServer (computing)WindowMultiplicationLibrary (computing)Right angleOperator (mathematics)Forcing (mathematics)Macro (computer science)Revision controlVirtual machinePlastikkarteNumberTable (information)View (database)Structural loadFunction (mathematics)Multiplication signCircleoutputDifferent (Kate Ryan album)Interface (computing)Condition numberSystem programming2 (number)Physical systemData managementCodeVideo gameCore dumpBitMobile appScalabilityProgrammschleifeIntrusion detection systemLastteilungSource code
49:58
Process (computing)Error messageLogarithmEvent horizonTime domainThermal expansionStack (abstract data type)Message passingError messageProcess (computing)Event horizonUniform resource locatorInterface (computing)Open sourceStreaming mediaModule (mathematics)Right angleBuffer solutionCodeDomain nameString (computer science)Slide ruleVertex (graph theory)BlogBoilerplate (text)EmailLimit (category theory)Computer virusDifferent (Kate Ryan album)Computer fileComputer hardwareOperator (mathematics)LoginComputing platformType theoryContext awarenessMobile appObject (grammar)System programmingNumberChainStatisticsJava appletFunctional (mathematics)Task (computing)Interactive televisionCore dumpChecklistSource codeException handlingBuildingSystem callSubject indexingSoftware developerWebsiteMessage passingArithmetic meanGodGoogolComa BerenicesExtreme programmingSemiconductor memoryBoss CorporationGroup actionComputer programmingConsistencyParameter (computer programming)Video gameScaling (geometry)AuthorizationFlash memoryCategory of beingLaptopMultiplication signAlgebraic closureForm (programming)Hand fan2 (number)Patch (Unix)Electronic mailing listFormal languageMetreComputer animation
Transcript: English(auto-generated)
00:05
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.
00:24
It's going to be about the core fundamental, the basics. So even if you work with Node.js, some build tools for random 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.
00:47
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.
01:01
They're doing really well there. Maybe we can beat them in terms of making sounds later. Can I have a little bit more volume in my mic? Thank you. So take a picture, get the slides and follow me with the code examples.
01:21
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.
01:44
So, is that my computer?
02:09
Did you have a different adapter? Oh, the different...
02:21
The power. Do you know where is it? That would make sense.
02:50
Yep. No? 40? Let me try to mirror.
03:40
Still not even worth. It's just to be good, right? Let me try. It's all like that.
06:10
Because it's perfect, the picture is good down there.
06:30
Stop building a tealight. We saw a bit of a slide on the TV, so I think the frame will be there for the track now. So, let's stop building. Yeah, this is the table. I have a picture now.
09:07
So that's actually perfect, because you have time to download the slides.
10:11
Yeah, it was there.
10:38
Thank you!
10:42
Okay, so... Start over again. Welcome to You Don't Know Node.js. This is a hands-on presentation. 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.
11:01
I want you to have the code, so you can later refer to it. So, we're building apps, 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 peoples, right?
11:22
Software is becoming everywhere. And with this big kind of a goal, I will introduce myself. I've published and wrote 12 books, not counting Chinese, Korean and Russian translations. The most popular ones are Practical Node.js and ProExpress.js.
11:43
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. And you can follow me on Twitter at azat underscore co. I tweet about JavaScript and Node.js mostly, and I also have a blog.
12:05
And if you have questions after this conference, you can reach me at my email, hiatazat.co. I work at Capital One, it's one of the US top 10 banks in the financial industry.
12:21
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 Storify. That's where I got to use Node.js at a pretty relatively large scale. And I saw from my own eyes that how Node.js has been official
12:45
in terms of having a generalistic approach and in terms of performance and having a better developmental experience. I also teach at nodeprogram.com, where you can find live in-person trainings in Node.js
13:01
as well as online trainings. Capital One is in the top 10 US banks. We're also in the UK and Canada. In the US, we're famous for our Visigoth commercials, but most people think it's Vikings. Some of them are funny.
13:23
Why use Node.js? Let's start with basics. I want to give you some ammo. When you go to your work on Monday next week, you have something to tell your co-workers and your team leads in order to convince them, hey, maybe we should use Node.js for our next project.
13:42
The biggest selling point of Node.js is its performance. Basically, it's faster. It's faster because it optimizes the input and output bound processes. Most of the time, input and output are the most expensive tasks that we have
14:02
compared to CPU-bound tasks. If we can optimize for them, that will give us a good boost in performance. Node.js has this thing called non-blocking I.O. How many of you are already familiar with this term? Raise your hand. Like half of the audience. For the rest of the half, this will be beneficial.
14:23
Non-blocking, this diagram shows you a high-level overview of how it's implemented in Node.js. We have the thing called event loop. Event loop is always looking for something to execute. It's never blocked or almost never blocked.
14:41
It allows our system, our Node.js-based system, to process multiple requests in parallel at the same time. Then event loop delegates those tasks, those heavy input-output tasks, like reading from a file system or writing to a database. The most popular thing that we like to do when we're building web apps
15:02
is to make HTTP requests to APIs or third-party services. Those are 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 are Java developers here?
15:22
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. Thread.sleep is putting the entire process to sleep. Nothing will happen on this particular thread
15:41
unless the timer expires. The entire thing will be basically useless. We will see step 1, step 2, and then step 3. Contrast that code with this Node.js. Now we have fancy callbacks. Set time out. It takes a callback, which is a function definition.
16:01
It's an anonymous function definition. It doesn't have a name. It basically tells, OK, schedule that in the future. Don't execute it now. The future will happen at 1 second. 1,000 milliseconds. The good thing about this code and this Node.js implementation is that set timer is not blocking.
16:22
Node.js, this process, will continue to execute. We will see step 1, step 2, and then after 1 second we will see step 3. Then if we have more code, Node.js will still continue to execute that. The result of this would be step 1, step 2, and then step 4.
16:42
Not step 3. Then after 1 second we will see step 3 and step 5. If you're familiar with how callbacks, Dred, jQuery, or Promises in Angular framework works on the browser, this is a very similar approach. We're scheduling something in the future.
17:01
The benefit is that our process is not blocked. We can process a lot of requests. Putting processes to sleep, that's not very useful. Most of the time we are building web services. That analogy, setTimeout, that's exactly how Node.js is implementing asynchronous input-output.
17:23
It could be writing to the database, or it could be making a request. Let's take a look at this diagram. This is a blocking system, maybe written in Python or Java. We have four clients. Please take this, it must be important.
17:40
We have four clients. There's a meeting request. The client at the bottom, he or she, has three requests. Each request is blocked by the previous request because it's hitting that one thread. Compare it to standing in line for coffee. We have that pretty cool Twilio booth downstairs at the expo.
18:03
I saw a lot of people standing in line, 20 people, maybe 10-20 people, during the day. 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.
18:20
This is the diagram. 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. You can text or Facebook your drink and then you can walk around,
18:43
talk with other people and they will text you back when the drink is ready. This is a much more enjoyable experience than waiting in line and not able to do other things. The texting to get your coffee, that's non-blocking, that's asynchronous. That's what we usually want.
19:03
This quote is from cordinghorror.com. It's a pretty famous blog. I highly recommend subscribing to it. Basically the blocking system has to be multi-threaded because each thread is blocked. Multi-threading could be very dangerous if you don't know how to use it.
19:21
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. Blocking systems have to be multi-threaded. Node.js, by design,
19:42
the designers of Node.js, the original creators, decided we're not going to create multiple threads, we just have single threads. 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 way.
20:07
That's one of the concerns. People tell, Node.js is single-threaded, it's not going to perform well. That actually forces you to think about scalability early on and I'll show you how to scale your system as well.
20:21
Before we do that, it's still possible to write blocking code in Node.js. Node.js is a platform, it's not going to prevent you from writing the blocking code. You need to be very careful how you implement your Node applications. For example, this is a CPU-intensive task that iterates many times
20:41
and on my machine it was taken 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. Most of the times our blocking code is not so obvious.
21:03
Most of the times it's buried under some module. So fs is a file system module to work with file systems and directories. In this example I'm using synchronous methods. We don't see that for loop which revolves, but I know that it's asynchronous
21:21
and the results would be accounts, then hello Ruby and then IPs and then hello Node. 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.
21:42
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 are like siblings, they have evil siblings which are synchronous and they have the good siblings.
22:01
This is the good sibling, asynchronous method, read file. 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,
22:21
it will be defined. But then I might have a racing condition between what data I will have the first, accounts or IPs. The data will be always after displaying Hello Ruby and Hello Node. So far so good? Feel free to ask questions in the middle.
22:40
We're not going to have a formal Q&A at the end. Why bother? 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.
23:03
So why bother to have synchronous code? It's there. Sometimes in the very edge case scenarios 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
23:22
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.
23:41
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 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.
24:02
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. We get the performance, our company spends less money on the servers,
24:20
that's all wonderful. But how many of you actually hit the performance limitations using traditional languages like Java or Python? So probably not many. I'm in the same boat. So most of the apps I'm building, unless it's for DacuSign or Storify, I don't experience that issue. Like remember Twitter in the early days,
24:41
you would see that whale, so they had that performance issue. 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. It's here to stay, it's not going to go away. We have a new standard now,
25:01
ES6 and ES7, 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 joints and you need to know the syntax.
25:20
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. So a lot of other technologies. Having Node.js on the backend eliminates at least one language. And then if you use a NoSQL database like MongoDB, which I really, really love,
25:42
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 quote instead of a single quote because it's a different language.
26:02
I'm reusing my code, so templates, utility libraries from the browser, I can re-use 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,
26:21
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'll probably take you like a weekend to get started,
26:40
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, it's not triple equals browser JavaScript. It's not completely same as browser JavaScript.
27:02
So we don't have window object. Obviously there is no windows on the server side. We also have more power. We can get the environmental information, we can work with file systems, etc. So there is this thing, it's called global. Either lower case or capital cased,
27:23
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, file name or dirname, that will give you the absolute path
27:40
to the file name, the currently running script, or it will give you just the path without the file name. 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 ES6 modules
28:02
in Node.js, the problem is solved. It's common JS syntax, it's beautiful. So module, that's how you export and require 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
28:20
or webpack tool. How do I get information about my system, like versions or platform? How do I read environmental variables, such as, for example, API keys or passwords? There is this thing, it's called global.process, or you can just access it by process. So every global property
28:42
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
29:01
of pretty much everything. For example, like V8 engine version. You can get the architecture. ArcV, that's how we get the input from the command line. And env, that's where your environment, that's where your API keys, you can access them once you're ready to deploy to production.
29:22
So don't store your passwords in your source code and don't create config.json. You can use the environmental variables. Oh, we have issues again.
29:41
The ghost of demo. 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 working directory.
30:01
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 website and that website can create a file on your file system.
30:21
Okay, so let's move into some of the Node.js patterns. How many of you really understand and like callbacks? Oh wow, it's like 40%. Very cool. I like callbacks until I hear callback hell. There's even a website called callbackhell.com.
30:42
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 developmental sense.
31:00
Meaning when you add more developers on the project it can become harder to understand that code. And sometimes nested callbacks can lead to problems. So we have advanced patterns
31:21
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 that 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
31:40
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 subject, we have observers or event listeners and then we have
32:01
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 new keyword
32:23
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, it's the name of the event, will be triggered, this function will be executed and we can have multiple events
32:41
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
33:02
we'll 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 and callbacks we have just one function that is executed at the end.
33:21
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
33:42
but the job needs to be customizable so at the end we want to put some custom logic but we don't want to hardcode it in the module. We want the consumers, developers who use the module to give the power to customize what will happen at the end. So we can use events
34:00
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,
34:21
let's say I'm a developer and want to implement the weekly job. So it's a weekly newsletter and then I'm creating an event listener and then we emit it. 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, undefined.
34:44
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
35:02
and 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 how they're singletons to check it out.
35:23
Okay, so let's move on. Problems with large data. So it's slow because you have to wait for the implementation in Node.js. One gigabyte, that's it. You're done. The last one is just a joke. We can use streams.
35:41
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. We have four types of streams.
36:01
We have writable, readable, and then the transform means it's just transforming. And streams are already inherited from EventEmitter. So we can use that interface to implement our streams.
36:21
And streams are everywhere, especially in the core, Node.js core. We can use streams for HTTP request 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.
36:58
And if you're following on your machines,
37:03
it's stdin.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.
37:23
This is how it looks like in the code. So basically process.stdin, I get my readable stream. And then I'm listening
37:40
for the onData. So remember the previous slides with EventEmitters, so very similar. We create this EventListener onData. So onData will happen each time I have a new line on my terminal. And I can start process that text. And then once I'm done, it's good to have also
38:00
a listener for the end event. We also have a different approach. We can use read method. So read method is synchronous but it's okay for it to be synchronous because it's really
38:21
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,
38:41
that would be the output of your node script. And there is a write operation. We use it like this, process.stdout.write. So this would be analogous for console.log. In fact console.log is using something similar.
39:01
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 our systems really really shine because we don't want the consumers of either our API or our web app to wait
39:21
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
39:41
it's a function, 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 1GB file to load. And then at the end I can parse it, I can do something else with it. There is also pipe interface.
40:02
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 of the data. So r.pipe, z.pipew will read from a file,
40:22
compress it and then write to a different file. All without having any buffers. Speaking of buffers, buffer is a special data type. We don't have it in the browser JavaScript. There is a read buffer in
40:41
ES6 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
41:02
sometimes you might see when you're expecting a string 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 string. You need to convert it. When you're reading or writing to a file or it's
41:21
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 to string it will use UTF-8. Remember FS from a few
41:42
slides back. When we're reading from a file the data is a buffer by Server stream it's a small express JS server
42:02
that I've written and I'm launching it node space server-stream. What it's doing is basically it has two endpoints. One endpoint is using stream and another is not using
42:21
stream. Let's go to the one that is not using stream. It's a huge infographic about Capital One. It's 8 megabytes or something like that. I'm going to the dev tools. I'm going to network and
42:42
I'm clicking on the response. Actually I'm clicking on the header and I don't know if you can see. It's 6.57 milliseconds. Let's remember that number.
43:00
Go to network. Click on all. By the way, I love dev tools. Such a nice thing. How many of you like dev tools? It's 1.4 milliseconds. Response time is shorter. Sometimes I get an order
43:20
of magnitude shorter. Right now it's 0.42. This is 6 milliseconds. This is 0.4 milliseconds. Response time. This is not like entire infographic. That's only the first byte but that's enough for users to start seeing something. That's
43:42
the benefit of using streams. I also have two more endpoints. They use a different interface but the idea is the same. Streams are faster. Some good stream resources.
44:01
There's automated workshop which have exercises you and it will test your answers. It's a great tool to learn streams. There's also a stream handbook. Going back to having a single system. Node.js
44:22
is 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? Basically it forces developers to think about scalability early on. To build distributed systems. If you're using
44:41
Java it's like it's multi-threaded I don't need to worry about it with Node.js. 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
45:00
that we have multiple 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. Most of the times it's web servers. Workers are web servers
45:21
and then the master is controlling those web servers. Typically we have as many processes as many CPUs we have. It's not like a hard rule you can have more but more returns so basically to maximize the max CPU
45:41
from your machine that's the best practice to have the same number of workers. This is the code. As you can see it's very easy. All we're doing we're having nif condition cluster.isMaster and we're forking new processes. .fork will create a new Node.js
46:01
process using exactly the worker. And then cluster.isWorker that's where our web server code goes. It can use express or just core HTTP doesn't matter.
46:22
And number of CPUs that comes from the core module it's called OS. This is an example of having multiple processes.
46:44
Node.space.cluster I have something else running so let's just kill everything. So as you can see I have four workers and they have different process IDs. So that's
47:01
approved that it's different processes. 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 loading. Basically you want to restart, you have new
47:20
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. 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
47:48
Node.js and I will be hitting my local host. I will have a 20 second timeout and I will have max 10 concurrent requests. So now I'm going back and
48:01
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 machine you can tell me your numbers and we can compare
48:20
whose machine is faster. So basically I was able to do 800 requests. When I'm doing it on Mac Pro I have 2,000 requests. So there are other libraries for doing a similar thing for having multiple
48:41
processes. So the advantage of cluster is that it's core but the 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.
49:04
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
49:21
modify your server code. So remember that e-fails condition in the cluster example, so in pm2 it's just your server code. You don't do anything with it. And it'll also give you a nice interface.
49:48
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. So there are two more ways
50:00
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 there outsource to a different platform or language, maybe Python or Java.
50:21
You can do it with spawn. Spawn, you can handle large functions. Fork, it's only for Node.js processes, you've seen how it's working. And exact, it's for something small, maybe like Linux commands to get the memory, to get some stats because it has a buffer.
50:40
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 node on data, again event emitters.
51:01
Fork is very similar only we don't specify that it's node because we assume it's node. 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
51:21
they named with dash, but that's one of the problems because different interface we don't use events, it's just a callback, just a callback because we don't have streams. One of the other objections of why not to use node
51:41
because it's hard to think about asynchronous code. Our brains are not really evolved to think about processes running in parallel, concurrently we're much better suited to think about synchronous code. Because we lose the context.
52:02
For example, remember that setTimeout? When setTimeout 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. Try catch, right? We know what it's doing, it's allowing us to catch
52:22
errors. This code will work absolutely fast, there's no events. If we have callbacks and events, so all I did just put setTimeout here and I'm throwing error in the future, this app will crash.
52:43
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. This is how I feel when asynchronous error happens and
53:01
no one handled it. So how to deal with it? Here's the list, the checklist for what to do. Let's go through them. So first of all, again, event-meter, right?
53:22
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, you implement this event handler. And at least have a trace,
53:41
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 the code one, which means error. Again, different approach,
54:01
same idea. So request, I'm sending a 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.
54:22
This is like the mother of all the error events. It's 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
54:42
a notification, sending an email to your webmaster, to your DevOps. 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 www.google.com, like the
55:01
URL domains, I have no idea why they named it. You can go to the doc that it's softly deprecated. It's very confusing but basically it means that they might remove it from the core in the future. Right now it's in the core and even when they remove
55:22
it, it's still relatively popular with users, it's going to leave as an NPM module. I don't see any reasons why not to use it. This is the idea. We're creating a domain. And our falling code,
55:41
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.
56:01
So this is async error. It failed. And this is domain async. It didn't fail, it gave me a nice error message which I programmed there. Now the last thing you can do, it's number six, it's a bonus. And it's really cool for
56:20
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,
56:41
import all of those modules. And then what I'm doing, I'm writing the string capital 1 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 the gip.
57:01
Basically it has the name of my module, my C++ add-on and my source file. Then I need this tool node-gip 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.releases.
57:23
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
57:41
If you're interested in working with Node.js, capital 1 is hiring in UK, US and Canada. Shameless plug. And we're also using cutting edge open source technologies like React, Kotlin, Closure, Angular 2, etc. Some of the people they're working in heavily regulated
58:01
industries like healthcare, defense, finance, government industry and working with open source. This is a talk I did at Node Interactive in December. So 30 second summary. Event emitters everywhere
58:21
in the core, it's good to know them. Streams, very very powerful. They basically will make you like a guru, ninja, pro in your team if you know how to use them. Buffers, need to convert them.
58:43
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 and nodeprogram.com
59:01
And one last thing, this is a quote from the same blogger, codinghorror.com JavaScript, it's really really becoming popular. Thank you.