-: 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.