1 00:00:01,110 --> 00:00:02,860 In this video, we're gonna do 2 00:00:02,860 --> 00:00:05,780 one last Heroku-specific configuration 3 00:00:05,780 --> 00:00:08,047 which is to respond to a so-called 4 00:00:08,047 --> 00:00:10,770 "sick term signal" that Heroku emits 5 00:00:10,770 --> 00:00:12,023 from time to time. 6 00:00:13,670 --> 00:00:16,300 So a Heroku dyno, and again 7 00:00:16,300 --> 00:00:19,460 a dyno is just a name that Heroku uses 8 00:00:19,460 --> 00:00:21,540 for basically a container in which 9 00:00:21,540 --> 00:00:23,230 your application is running 10 00:00:23,230 --> 00:00:26,820 so these dynos restart every 24 hours 11 00:00:26,820 --> 00:00:29,930 in order to keep your app in a healthy state. 12 00:00:29,930 --> 00:00:32,930 Okay? And the way that Heroku does this 13 00:00:32,930 --> 00:00:36,060 is by sending the so-called "sick term signal" 14 00:00:36,060 --> 00:00:38,577 to our note application, and the application 15 00:00:38,577 --> 00:00:41,640 will then basically shut down immediately. 16 00:00:41,640 --> 00:00:44,680 All right? Now, the problem with this is 17 00:00:44,680 --> 00:00:46,830 that the shut down can be very abrupt. 18 00:00:46,830 --> 00:00:50,020 So this can then leave requests 19 00:00:50,020 --> 00:00:51,930 that are currently being processed 20 00:00:51,930 --> 00:00:53,730 basically hanging in the air, 21 00:00:53,730 --> 00:00:55,789 and so that's not ideal. 22 00:00:55,789 --> 00:00:58,830 So basically that's what happens also 23 00:00:58,830 --> 00:01:01,623 when there is an unhandled rejection. 24 00:01:02,850 --> 00:01:05,024 So here in our server, dot JS, 25 00:01:05,024 --> 00:01:07,320 remember how we actually gracefully 26 00:01:07,320 --> 00:01:09,700 shut down the server whenever there was 27 00:01:09,700 --> 00:01:12,690 an unhandled rejection. All right? 28 00:01:12,690 --> 00:01:13,990 So now we're actually gonna do 29 00:01:13,990 --> 00:01:16,240 something very similar when we receive 30 00:01:16,240 --> 00:01:20,310 the "sick term signal". All right? So let's say 31 00:01:22,410 --> 00:01:23,690 process dot on 32 00:01:26,870 --> 00:01:29,660 sick term, and so basically, really 33 00:01:29,660 --> 00:01:32,300 the sick term is just an event that can be 34 00:01:32,300 --> 00:01:35,160 emitted and that our application receives 35 00:01:35,160 --> 00:01:36,700 and can then respond to. 36 00:01:36,700 --> 00:01:40,383 So exactly like the unhandled rejection. Right? 37 00:01:41,430 --> 00:01:43,293 Now here we do not have an error, 38 00:01:46,210 --> 00:01:47,760 and so let's actually do 39 00:01:48,720 --> 00:01:50,250 a console log here as well 40 00:01:52,130 --> 00:01:53,713 sick term received. 41 00:01:56,200 --> 00:01:57,280 Shutting down 42 00:01:58,690 --> 00:02:00,520 gracefully. 43 00:02:00,520 --> 00:02:02,820 And let's add some emoji here just 44 00:02:02,820 --> 00:02:05,400 to make it stand out in our console 45 00:02:05,400 --> 00:02:07,823 among all these logs that we have there. 46 00:02:09,580 --> 00:02:11,980 All right, and now let's actually 47 00:02:11,980 --> 00:02:14,700 do the graceful shut down, 48 00:02:14,700 --> 00:02:17,173 which is basically just to close the server. 49 00:02:21,650 --> 00:02:25,270 So this will basically close the server, 50 00:02:25,270 --> 00:02:27,150 but before that still handle all 51 00:02:27,150 --> 00:02:29,300 of the pending requests. And so that's 52 00:02:29,300 --> 00:02:31,800 exactly what we want, instead of a 53 00:02:31,800 --> 00:02:35,820 very abrupt finishing of the application, right? 54 00:02:35,820 --> 00:02:38,310 Then, once that's done, let's lock that 55 00:02:38,310 --> 00:02:39,193 to the console. 56 00:02:40,810 --> 00:02:42,133 So console dot log, 57 00:02:43,580 --> 00:02:46,010 again let's add a nice emoji here 58 00:02:47,260 --> 00:02:50,063 process terminated. 59 00:02:50,950 --> 00:02:53,740 Okay. And in this case here, we do not use 60 00:02:53,740 --> 00:02:56,654 process dot exit, because the sick term itself 61 00:02:56,654 --> 00:02:59,940 will cause the application to shut down. 62 00:02:59,940 --> 00:03:01,970 We do not need to do it manually 63 00:03:01,970 --> 00:03:05,100 such as we did up here. All right? 64 00:03:05,100 --> 00:03:07,990 So basically, sick term is a signal that 65 00:03:07,990 --> 00:03:09,720 is used to cause a program to 66 00:03:09,720 --> 00:03:12,430 really stop running. So it's like very 67 00:03:12,430 --> 00:03:17,430 politely way to ask a program to terminate. Okay? 68 00:03:17,900 --> 00:03:21,510 So again, we need to implement this listening 69 00:03:21,510 --> 00:03:23,560 to this event here, because Heroku 70 00:03:23,560 --> 00:03:25,530 every 24 hours will shut down 71 00:03:25,530 --> 00:03:28,140 our application by sending this signal, 72 00:03:28,140 --> 00:03:30,470 or this event, to our application. 73 00:03:30,470 --> 00:03:32,720 And so then, we shut down the process 74 00:03:32,720 --> 00:03:34,882 gracefully, by using server dot close, 75 00:03:34,882 --> 00:03:37,760 which allows all the pending requests 76 00:03:37,760 --> 00:03:41,090 to still process until the end. Okay? 77 00:03:41,090 --> 00:03:43,390 So, let's actually now test this. 78 00:03:43,390 --> 00:03:45,190 And so what we need to do first 79 00:03:45,190 --> 00:03:47,890 is to of course commit all of these modifications 80 00:03:47,890 --> 00:03:50,000 to our git repository 81 00:03:50,000 --> 00:03:51,690 and you see that right now we have 82 00:03:51,690 --> 00:03:53,670 three modified files. 83 00:03:53,670 --> 00:03:56,530 So we modified the server in this lecture, 84 00:03:56,530 --> 00:03:59,340 and the alt controller in app dot JS 85 00:03:59,340 --> 00:04:01,923 in the last one. Right? 86 00:04:02,980 --> 00:04:06,050 So, lets add all of them to the staging area 87 00:04:06,050 --> 00:04:08,850 git add all, and then commit 88 00:04:09,860 --> 00:04:12,163 these changes really to our repo. 89 00:04:14,600 --> 00:04:19,390 So edit, Heroku, config. 90 00:04:19,390 --> 00:04:20,683 Let's just call it that. 91 00:04:21,800 --> 00:04:24,240 All right. And now remember how we 92 00:04:24,240 --> 00:04:26,890 basically redeploy the application. 93 00:04:26,890 --> 00:04:28,980 Well, that's very easy. 94 00:04:28,980 --> 00:04:33,133 Git push Heroku addendum master branch. 95 00:04:34,730 --> 00:04:37,260 Okay, so this will now basically send 96 00:04:37,260 --> 00:04:40,300 all the modifications up to this branch 97 00:04:40,300 --> 00:04:42,830 and will then rebuild the application 98 00:04:42,830 --> 00:04:47,170 on Heroku and, of course, relaunch it as well. 99 00:04:47,170 --> 00:04:49,350 So you see that it does all this process that 100 00:04:49,350 --> 00:04:51,900 it did when we first deployed the application 101 00:04:51,900 --> 00:04:54,490 all over again each time that we deploy 102 00:04:54,490 --> 00:04:57,120 the application another time. 103 00:04:57,120 --> 00:05:00,712 And now that's done. And so, in order to test 104 00:05:00,712 --> 00:05:04,070 what we just did here, let's basically manually 105 00:05:04,070 --> 00:05:06,390 restart the application. And so that will then 106 00:05:06,390 --> 00:05:08,663 also send the sick term to the app 107 00:05:08,663 --> 00:05:12,320 and should trigger whatever happens here 108 00:05:12,320 --> 00:05:14,980 Okay? So let's start by taking a look 109 00:05:14,980 --> 00:05:18,520 at all our dynos, so that's something that 110 00:05:18,520 --> 00:05:21,510 we didn't do yet, so that's Heroku PS 111 00:05:23,340 --> 00:05:25,220 and so you see that we have here 112 00:05:25,220 --> 00:05:30,010 this one free web dyno. Okay? 113 00:05:30,010 --> 00:05:32,560 Which runs, or basically which starts 114 00:05:32,560 --> 00:05:35,390 by using the MPM start command, just as 115 00:05:35,390 --> 00:05:38,300 I mentioned in one of the previous videos. 116 00:05:38,300 --> 00:05:41,530 Okay, so now what we can do in order to restart 117 00:05:41,530 --> 00:05:46,530 is very simply Heroku PS and restart. 118 00:05:49,890 --> 00:05:52,850 So it was not correct I think. 119 00:05:52,850 --> 00:05:56,340 Now it should be, and that's done. 120 00:05:56,340 --> 00:05:59,360 So, let's take a look now at the logs 121 00:05:59,360 --> 00:06:04,150 which is Heroku logs dash dash tail. 122 00:06:06,940 --> 00:06:10,410 All right, so 123 00:06:10,410 --> 00:06:11,420 and here it is. 124 00:06:11,420 --> 00:06:15,260 Coming from our app, we see the sick term received 125 00:06:15,260 --> 00:06:17,533 and then process terminated locks. 126 00:06:18,370 --> 00:06:19,940 All right, and you see that then 127 00:06:19,940 --> 00:06:22,170 after that, starting process with 128 00:06:22,170 --> 00:06:23,723 command NPM start. 129 00:06:24,980 --> 00:06:27,250 All right, and so that is note server dot JS 130 00:06:27,250 --> 00:06:30,020 just as we specified, and now the app is 131 00:06:30,020 --> 00:06:34,120 running on port 57 two six seven. 132 00:06:34,120 --> 00:06:36,310 And so remember how I said earlier that 133 00:06:36,310 --> 00:06:37,650 basically Heroku runs their app 134 00:06:37,650 --> 00:06:40,930 on a random port. And so this one 135 00:06:40,930 --> 00:06:43,790 is that. All right? Great! 136 00:06:43,790 --> 00:06:46,850 So let's exit this, clean this up, 137 00:06:46,850 --> 00:06:49,040 and so with that, we actually wrap up 138 00:06:49,040 --> 00:06:52,720 all the Heroku configuration stuff in our application. 139 00:06:52,720 --> 00:06:56,140 Fantastic. Now there's just two more things left 140 00:06:56,140 --> 00:06:57,890 which is to implement something called 141 00:06:57,890 --> 00:07:01,129 CORS, or Cross Origin Resource Sharing, 142 00:07:01,129 --> 00:07:04,330 and then also finishing the Stripe payments 143 00:07:04,330 --> 00:07:07,470 using webhooks. So remember how I promised 144 00:07:07,470 --> 00:07:09,890 to implement that one a bit later, and so 145 00:07:09,890 --> 00:07:12,990 we will do that over the next two lectures. 146 00:07:12,990 --> 00:07:16,073 All right? So see you back then in a second.