1 00:00:03,680 --> 00:00:07,140 A discussion about Node Modules is incomplete 2 00:00:07,140 --> 00:00:10,310 without talking about Callbacks and Error handling. 3 00:00:10,310 --> 00:00:14,820 What are callbacks and why are they essential for 4 00:00:14,820 --> 00:00:17,250 supporting asynchronous computation that is very 5 00:00:17,250 --> 00:00:20,610 useful when we write Node.js applications? 6 00:00:20,610 --> 00:00:25,130 How is error handling done in Node applications? 7 00:00:25,130 --> 00:00:29,615 Let's talk briefly about these in this lecture. 8 00:00:29,615 --> 00:00:34,305 Before we proceed on to talk about Node Modules and Callbacks, 9 00:00:34,305 --> 00:00:40,315 we need to understand two salient features about the JavaScript language itself. 10 00:00:40,315 --> 00:00:46,295 First and foremost, JavaScript supports what is called as first-class functions. 11 00:00:46,295 --> 00:00:48,430 What do we mean by first-class functions? 12 00:00:48,430 --> 00:00:52,838 Is that a function can be treated just like any other variable. 13 00:00:52,838 --> 00:00:55,620 And hence, functions can be passed around as 14 00:00:55,620 --> 00:01:00,955 parameters inside function calls to other functions. 15 00:01:00,955 --> 00:01:06,630 And that essentially allows us to send in functions as callback functions that can be 16 00:01:06,630 --> 00:01:14,110 called from another Node module in order to get some work accomplished. 17 00:01:14,110 --> 00:01:20,010 Then look at how this is very useful in supporting callbacks in Node.js. 18 00:01:20,010 --> 00:01:25,107 The second aspect about JavaScript is the support for Closures. 19 00:01:25,107 --> 00:01:26,835 What we mean by Closures? 20 00:01:26,835 --> 00:01:31,185 Especially, if you are familiar with functional programming languages, 21 00:01:31,185 --> 00:01:33,325 you understand how closure works. 22 00:01:33,325 --> 00:01:37,050 A function defined inside another function 23 00:01:37,050 --> 00:01:42,955 automatically gets access to the variables that are declared in the outer function. 24 00:01:42,955 --> 00:01:46,185 So even if the outer function is completed execution, 25 00:01:46,185 --> 00:01:51,000 when the inner function executes later the inner function will still have access to 26 00:01:51,000 --> 00:01:56,020 the values of the variables within that outer function. 27 00:01:56,020 --> 00:01:57,465 And this is again, 28 00:01:57,465 --> 00:02:05,244 very effectively used when we use Callbacks in Node applications. 29 00:02:05,244 --> 00:02:08,790 If you are used to the standard way of writing applications, 30 00:02:08,790 --> 00:02:12,870 then you are familiar with synchronous computation where you 31 00:02:12,870 --> 00:02:17,918 specify a computation as a set of steps to be done one after another. 32 00:02:17,918 --> 00:02:21,165 Now, if you organize your computation as follows, 33 00:02:21,165 --> 00:02:27,885 as shown on the left side of the slide here, 34 00:02:27,885 --> 00:02:33,260 we have computation one then followed by a long running computation, 35 00:02:33,260 --> 00:02:36,095 followed by computation two, and computation three. 36 00:02:36,095 --> 00:02:38,400 So in this arrangement, 37 00:02:38,400 --> 00:02:41,940 let's assume that computation two is dependent upon 38 00:02:41,940 --> 00:02:45,250 the long running computation completing its work, 39 00:02:45,250 --> 00:02:48,690 then it makes sense for computation two to wait until 40 00:02:48,690 --> 00:02:53,430 the long running computation is completed before it gets executed. 41 00:02:53,430 --> 00:02:56,670 Now, we might have another piece of work to 42 00:02:56,670 --> 00:03:00,435 be done which is defined by computation three. 43 00:03:00,435 --> 00:03:05,055 Computation three may be in noway dependent upon computation two, 44 00:03:05,055 --> 00:03:11,092 or the long running computation to complete before it is executed. 45 00:03:11,092 --> 00:03:12,420 So in this case, 46 00:03:12,420 --> 00:03:16,635 if we do synchronous execution of this computation, 47 00:03:16,635 --> 00:03:18,825 then computation three will get stuck, 48 00:03:18,825 --> 00:03:23,895 even though it is no way dependent upon the completion of either computation two, 49 00:03:23,895 --> 00:03:25,800 or the long running computation. 50 00:03:25,800 --> 00:03:29,310 So thereby, the amount of work to be done by computation three, 51 00:03:29,310 --> 00:03:35,625 will be delayed because of no reason of it's own, right? 52 00:03:35,625 --> 00:03:41,725 Instead is delayed because of something that precedes it in the sequence of computation. 53 00:03:41,725 --> 00:03:45,735 Now, asynchronous computation, we can rearrange this work 54 00:03:45,735 --> 00:03:50,265 in such a way that computation one, when it completes, 55 00:03:50,265 --> 00:03:57,350 can spawn off those long running computation to be done behind the scenes independently, 56 00:03:57,350 --> 00:04:02,706 and since computation two is dependent upon the long running computation to finish, 57 00:04:02,706 --> 00:04:09,314 then computation two can be executed when the long running computation is finished. 58 00:04:09,314 --> 00:04:14,265 Now, this frees up computation three to continue on, 59 00:04:14,265 --> 00:04:16,820 right after computation one finishes. 60 00:04:16,820 --> 00:04:18,585 So this way of arranging, 61 00:04:18,585 --> 00:04:22,815 ensures that computation three will finish much faster than 62 00:04:22,815 --> 00:04:28,000 being stuck behind the long running computation, and computation two. 63 00:04:28,000 --> 00:04:33,945 So this approach of rearranging your work is very useful especially, 64 00:04:33,945 --> 00:04:37,650 when you have a long running computation especially, 65 00:04:37,650 --> 00:04:40,000 I/O bound computation to be done. 66 00:04:40,000 --> 00:04:43,174 So in this case, you can spawn off the I/O bound computation, 67 00:04:43,174 --> 00:04:44,700 and when that completes, 68 00:04:44,700 --> 00:04:47,580 then whatever needs to be done thereafter, 69 00:04:47,580 --> 00:04:51,830 can be sent to it as a Callback. 70 00:04:51,830 --> 00:04:54,540 So computation two will be turned into 71 00:04:54,540 --> 00:04:58,490 a Callback and then given off to the long running computation. 72 00:04:58,490 --> 00:05:01,440 So when that completes its work, 73 00:05:01,440 --> 00:05:07,015 then it'll call back the function that is enclosed inside the callback. 74 00:05:07,015 --> 00:05:11,020 So this is leveraged very effectively by Node.js 75 00:05:11,020 --> 00:05:17,250 in rearranging the computation within our Node applications. 76 00:05:17,250 --> 00:05:20,740 Now, this is very, 77 00:05:20,740 --> 00:05:25,520 very useful when we look at the way Node.js itself runs. 78 00:05:25,520 --> 00:05:26,735 So as we realize, 79 00:05:26,735 --> 00:05:31,830 Node.js is organized into a single threaded event loop. 80 00:05:31,830 --> 00:05:34,690 This single threaded event loop basically, 81 00:05:34,690 --> 00:05:39,620 picks up requests as they come in and execute it one after another. 82 00:05:39,620 --> 00:05:42,592 Whenever it needs to spawn off an I/O request, 83 00:05:42,592 --> 00:05:44,650 the I/O request will be spawned off, 84 00:05:44,650 --> 00:05:48,910 and any work that needs to be done after the I/O request is completed, 85 00:05:48,910 --> 00:05:51,330 will be enclosed inside a Callback. 86 00:05:51,330 --> 00:05:52,940 So when the I/O request completes, 87 00:05:52,940 --> 00:05:55,660 then it'll put the Callback into the request queue, 88 00:05:55,660 --> 00:05:58,510 and the Callback will be handled thereafter, 89 00:05:58,510 --> 00:06:00,030 by the event loop. 90 00:06:00,030 --> 00:06:02,890 So the event loop is a continuously running loop 91 00:06:02,890 --> 00:06:06,595 which basically picks up requests from the request queue, 92 00:06:06,595 --> 00:06:09,240 and then services them one at a time. 93 00:06:09,240 --> 00:06:11,470 So when you think back about it, 94 00:06:11,470 --> 00:06:14,093 you realize that Node.js is a single threaded, 95 00:06:14,093 --> 00:06:15,340 but at the same time, 96 00:06:15,340 --> 00:06:19,645 it is able to achieve much faster rate of completion of work, 97 00:06:19,645 --> 00:06:24,580 simply because of the judicious use of callbacks, 98 00:06:24,580 --> 00:06:29,680 and the asynchronous execution of I/O requests, 99 00:06:29,680 --> 00:06:32,815 like for file accesses or database, 100 00:06:32,815 --> 00:06:39,280 or long running processing that can be done independently behind the scenes. 101 00:06:39,280 --> 00:06:43,045 Now, the way the Node.js event loop handles all this, 102 00:06:43,045 --> 00:06:48,410 is that the event loop is arranged in a sequence of phases. 103 00:06:48,410 --> 00:06:51,710 So as you see in the diagram shown here, 104 00:06:51,710 --> 00:06:55,060 the phases include timer handling, 105 00:06:55,060 --> 00:06:58,390 I/O callback handling, then you have idle, prepare, 106 00:06:58,390 --> 00:07:05,800 then the poll where the incoming requests for connections or data are handled, 107 00:07:05,800 --> 00:07:07,585 and then the check phase, 108 00:07:07,585 --> 00:07:10,290 and then finally, the close callbacks phase. 109 00:07:10,290 --> 00:07:16,351 Now, some details about what is done in each of these phases is listed to the right side. 110 00:07:16,351 --> 00:07:17,905 In the timer phase, 111 00:07:17,905 --> 00:07:21,550 the event loop handles anything that is triggered by the 112 00:07:21,550 --> 00:07:25,770 setTimeout() function in JavaScript. 113 00:07:25,770 --> 00:07:29,010 The I/O callbacks are executed, 114 00:07:29,010 --> 00:07:32,620 almost all the callbacks that come back to be 115 00:07:32,620 --> 00:07:36,795 executed after an I/O request will be handled by the I/O callbacks queue. 116 00:07:36,795 --> 00:07:41,065 So each of these phases maintains its own separate queue, 117 00:07:41,065 --> 00:07:46,053 and the Node.js event loop picks up requests from each of these queues, and handles them. 118 00:07:46,053 --> 00:07:52,150 The, idle, prepare, is meant for internal use by Node.js. 119 00:07:52,150 --> 00:07:57,910 The poll is where it retrieves new I/O events to be handled and perhaps, 120 00:07:57,910 --> 00:08:00,313 the requests coming in from outside. 121 00:08:00,313 --> 00:08:08,354 The close callback phase handles any socket closures that need to be handled, and so on. 122 00:08:08,354 --> 00:08:11,050 Now, we don't need to worry too much about 123 00:08:11,050 --> 00:08:15,430 all these details if we need to really write a Node.js application. 124 00:08:15,430 --> 00:08:19,720 When required, we will look at some of these details as and when 125 00:08:19,720 --> 00:08:25,030 it is essential for understanding how our Node application works. 126 00:08:25,030 --> 00:08:27,985 But for the moment, this gives you a big picture view 127 00:08:27,985 --> 00:08:31,990 of how the Node.js event loop is handled. 128 00:08:31,990 --> 00:08:35,830 Sufficed to say that this is sufficient enough information for us to 129 00:08:35,830 --> 00:08:40,590 understand the Node applications and how they work for the moment. 130 00:08:40,590 --> 00:08:42,895 If you want to know more details, 131 00:08:42,895 --> 00:08:46,810 then I have given you a link to a detailed description in the Node.js 132 00:08:46,810 --> 00:08:53,930 documentation which explains about the event loop in more detail. 133 00:08:53,930 --> 00:08:58,615 With this quick understanding of Node, 134 00:08:58,615 --> 00:09:01,445 Callbacks, and Error handling, 135 00:09:01,445 --> 00:09:03,296 we will move on to the exercise, 136 00:09:03,296 --> 00:09:09,280 where we will look at how a Node application can written with Callbacks, 137 00:09:09,280 --> 00:09:14,110 and how errors can be handled inside a Node application. 138 00:09:14,110 --> 00:09:18,840 We will see repeated use of this pattern in subsequent exercises, 139 00:09:18,840 --> 00:09:21,421 and subsequent lessons specifically, 140 00:09:21,421 --> 00:09:22,960 when we look at Express, 141 00:09:22,960 --> 00:09:26,860 and how we build server side applications using Express 142 00:09:26,860 --> 00:09:32,720 in more detail in the later part of this course.