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.