‫-: In questo video, faremo
‫un'ultima configurazione specifica per Heroku che è quella
‫di rispondere a un cosiddetto "segnale
‫di termine malato" che Heroku emette di tanto
‫in tanto.
‫Quindi un Heroku dyno, e ancora un
‫dyno è solo un nome che Heroku usa fondamentalmente
‫per un contenitore in cui
‫è in esecuzione la
‫tua applicazione, quindi questi dyno si riavviano ogni 24 ore
‫per mantenere la tua app in uno stato sano.
‫Va bene? E il modo
‫in cui Heroku lo fa è inviando il cosiddetto
‫"segnale di termine malato" alla nostra applicazione
‫per appunti, e l'applicazione si chiuderà praticamente immediatamente.
‫Va bene? Ora, il problema è
‫che lo spegnimento può essere molto brusco.
‫Quindi questo può lasciare le richieste che sono
‫attualmente in fase di elaborazione
‫sostanzialmente sospese in aria,
‫e quindi non è l'ideale.
‫Quindi in pratica è quello che succede anche
‫quando c'è un rifiuto non gestito.
‫Quindi qui nel nostro server, punto JS,
‫ricordiamo come in realtà abbiamo spento con garbo
‫il server ogni volta che si è verificato
‫un rifiuto non gestito. Va bene?
‫Quindi ora faremo
‫qualcosa di molto simile quando riceveremo il
‫"segnale di termine malato". Va bene? Quindi diciamo process dot
‫on ammalato,
‫e quindi fondamentalmente, in realtà il termine malato
‫è solo un evento che può essere
‫emesso e che la nostra applicazione riceve e
‫a cui può quindi rispondere.
‫Quindi esattamente come il rifiuto non gestito. Destra?
‫Ora qui non abbiamo un errore,
‫quindi eseguiamo anche un
‫registro della console
‫qui come termine malato ricevuto.
‫Chiudendo
‫con grazia.
‫E aggiungiamo alcune emoji qui
‫solo per farlo risaltare nella nostra console
‫tra tutti questi registri che abbiamo lì.
‫Va bene, e ora
‫eseguiamo lo spegnimento con grazia, che è
‫fondamentalmente solo per chiudere il server.
‫Quindi questo fondamentalmente chiuderà il server, ma prima ancora
‫gestirà tutte le richieste
‫in sospeso. E quindi
‫è esattamente quello che vogliamo,
‫invece di una conclusione molto brusca dell'applicazione, giusto?
‫Quindi, una volta fatto, blocchiamolo sulla
‫console.
‫Quindi console
‫dot log, aggiungiamo ancora
‫una bella emoji qui processo terminato.
‫Va bene. E in questo
‫caso qui, non usiamo il punto di uscita del
‫processo, perché il termine malato stesso causerà la chiusura dell'applicazione.
‫Non abbiamo bisogno di farlo manualmente
‫come abbiamo fatto qui. Va bene?
‫Quindi, fondamentalmente, il termine malato è un segnale che
‫viene utilizzato per causare l'arresto effettivo
‫di un programma. Quindi è un modo
‫molto gentile per chiedere a un programma di terminare. Va bene?
‫Quindi, di nuovo, dobbiamo implementare questo ascolto di questo
‫evento qui, perché Heroku ogni
‫24 ore chiuderà
‫la nostra applicazione inviando questo segnale,
‫o questo evento, alla nostra applicazione.
‫E quindi, chiudiamo il processo con grazia, utilizzando
‫il punto di chiusura del server, che
‫consente a tutte le richieste in sospeso di elaborare
‫ancora fino alla fine. Va bene?
‫Quindi, ora proviamo questo.
‫E quindi quello che dobbiamo
‫fare prima è ovviamente inviare tutte queste modifiche
‫al nostro repository git e vedi
‫che in questo
‫momento abbiamo tre file modificati.
‫Quindi abbiamo modificato il server in questa
‫lezione e il controller alt in app
‫dot JS nell'ultima. Destra?
‫Quindi, aggiungiamoli tutti all'area di staging git add
‫all, quindi eseguiamo il commit di queste
‫modifiche nel nostro repository.
‫Quindi modifica, Heroku, config.
‫Chiamiamola così.
‫Va bene. E ora
‫ricorda come ridistribuiamo sostanzialmente l'applicazione.
‫Bene, è molto facile.
‫Git push ramo principale dell'addendum di Heroku.
‫Ok, quindi questo invierà
‫sostanzialmente tutte le modifiche fino a
‫questo ramo e quindi
‫ricostruirà l'applicazione su Heroku e, ovviamente, la rilancerà.
‫Quindi vedi che fa tutto
‫questo processo che ha fatto quando abbiamo
‫distribuito per la prima volta l'applicazione di
‫nuovo ogni volta che distribuiamo l'applicazione un'altra volta.
‫E ora è fatto. E quindi, per testare
‫ciò che abbiamo appena fatto qui, riavviamo fondamentalmente
‫manualmente l'applicazione. E
‫quindi invierà anche il termine
‫per malattia all'app e dovrebbe innescare qualunque
‫cosa accada qui. Quindi iniziamo dando
‫un'occhiata a tutti i nostri dynos, quindi è qualcosa che
‫non abbiamo ancora fatto, quindi questo è Heroku
‫PS e quindi vedi che
‫abbiamo qui questo dyno web gratuito. Va bene?
‫Che funziona, o fondamentalmente che inizia
‫usando il comando di avvio MPM, proprio
‫come ho detto in uno dei video precedenti.
‫Ok, quindi ora quello che possiamo
‫fare per riavviare è molto semplicemente Heroku PS e riavviare.
‫Quindi non era corretto credo.
‫Ora dovrebbe essere, e questo è fatto.
‫Quindi, diamo un'occhiata ora ai
‫registri che sono i registri di Heroku dash dash tail.
‫Va bene, così ed eccolo
‫qui.
‫Provenendo dalla nostra app, vediamo il termine di malattia ricevuto e
‫quindi elaboriamo i blocchi terminati.
‫Va bene, e poi lo
‫vedi, avviando il processo con il
‫comando NPM start.
‫Va bene, quindi questo è il
‫punto JS del server, proprio come abbiamo specificato,
‫e ora l'app è in esecuzione sulla porta 57 due sei sette.
‫E quindi ricorda come ho detto prima che
‫fondamentalmente Heroku esegue la
‫propria app su una porta casuale. E quindi questo è
‫quello. Va bene? Grande!
‫Quindi usciamo da questo, ripuliamolo, e così
‫con quello, in realtà concludiamo
‫tutte le cose di configurazione di Heroku nella nostra applicazione.
‫Fantastico. Ora ci sono solo
‫altre due cose rimaste che
‫è implementare qualcosa chiamato CORS, o Cross Origin Resource
‫Sharing, e poi anche finire i pagamenti Stripe
‫usando i webhook. Quindi ricorda come
‫ho promesso di implementarlo un po' più
‫tardi, e così lo faremo nelle prossime due lezioni.
‫Va bene? Quindi ci vediamo tra un secondo.