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