All language subtitles for 008 Responding to a SIGTERM Signal_Downloadly.ir_en

In this video, we're gonna do

one last Heroku-specific configuration

which is to respond to a so-called

"sick term signal" that Heroku emits

from time to time.

So a Heroku dyno, and again

a dyno is just a name that Heroku uses

for basically a container in which

your application is running

so these dynos restart every 24 hours

in order to keep your app in a healthy state.

Okay? And the way that Heroku does this

is by sending the so-called "sick term signal"

to our note application, and the application

will then basically shut down immediately.

All right? Now, the problem with this is

that the shut down can be very abrupt.

So this can then leave requests

that are currently being processed

basically hanging in the air,

and so that's not ideal.

So basically that's what happens also

when there is an unhandled rejection.

So here in our server, dot JS,

remember how we actually gracefully

shut down the server whenever there was

an unhandled rejection. All right?

So now we're actually gonna do

something very similar when we receive

the "sick term signal". All right? So let's say

process dot on

sick term, and so basically, really

the sick term is just an event that can be

emitted and that our application receives

and can then respond to.

So exactly like the unhandled rejection. Right?

Now here we do not have an error,

and so let's actually do

a console log here as well

sick term received.

Shutting down

gracefully.

And let's add some emoji here just

to make it stand out in our console

among all these logs that we have there.

All right, and now let's actually

do the graceful shut down,

which is basically just to close the server.

So this will basically close the server,

but before that still handle all

of the pending requests. And so that's

exactly what we want, instead of a

very abrupt finishing of the application, right?

Then, once that's done, let's lock that

to the console.

So console dot log,

again let's add a nice emoji here

process terminated.

Okay. And in this case here, we do not use

process dot exit, because the sick term itself

will cause the application to shut down.

We do not need to do it manually

such as we did up here. All right?

So basically, sick term is a signal that

is used to cause a program to

really stop running. So it's like very

politely way to ask a program to terminate. Okay?

So again, we need to implement this listening

to this event here, because Heroku

every 24 hours will shut down

our application by sending this signal,

or this event, to our application.

And so then, we shut down the process

gracefully, by using server dot close,

which allows all the pending requests

to still process until the end. Okay?

So, let's actually now test this.

And so what we need to do first

is to of course commit all of these modifications

to our git repository

and you see that right now we have

three modified files.

So we modified the server in this lecture,

and the alt controller in app dot JS

in the last one. Right?

So, lets add all of them to the staging area

git add all, and then commit

these changes really to our repo.

So edit, Heroku, config.

Let's just call it that.

All right. And now remember how we

basically redeploy the application.

Well, that's very easy.

Git push Heroku addendum master branch.

Okay, so this will now basically send

all the modifications up to this branch

and will then rebuild the application

on Heroku and, of course, relaunch it as well.

So you see that it does all this process that

it did when we first deployed the application

all over again each time that we deploy

the application another time.

And now that's done. And so, in order to test

what we just did here, let's basically manually

restart the application. And so that will then

also send the sick term to the app

and should trigger whatever happens here

Okay? So let's start by taking a look

at all our dynos, so that's something that

we didn't do yet, so that's Heroku PS

and so you see that we have here

this one free web dyno. Okay?

Which runs, or basically which starts

by using the MPM start command, just as

I mentioned in one of the previous videos.

Okay, so now what we can do in order to restart

is very simply Heroku PS and restart.

So it was not correct I think.

Now it should be, and that's done.

So, let's take a look now at the logs

which is Heroku logs dash dash tail.

All right, so

and here it is.

Coming from our app, we see the sick term received

and then process terminated locks.

All right, and you see that then

after that, starting process with

command NPM start.

All right, and so that is note server dot JS

just as we specified, and now the app is

running on port 57 two six seven.

And so remember how I said earlier that

basically Heroku runs their app

on a random port. And so this one

is that. All right? Great!

So let's exit this, clean this up,

and so with that, we actually wrap up

all the Heroku configuration stuff in our application.

Fantastic. Now there's just two more things left

which is to implement something called

CORS, or Cross Origin Resource Sharing,

and then also finishing the Stripe payments

using webhooks. So remember how I promised

to implement that one a bit later, and so

we will do that over the next two lectures.

All right? So see you back then in a second.