‫-: In diesem Video
‫werden wir eine letzte Heroku-spezifische Konfiguration vornehmen,
‫die auf ein sogenanntes "Krankheitssignal"
‫reagieren soll, das Heroku von Zeit zu
‫Zeit aussendet.
‫Ein Heroku-Dyno, und wieder ein Dyno, ist
‫nur ein Name, den Heroku im Grunde für
‫einen Container verwendet, in dem
‫Ihre Anwendung ausgeführt wird,
‫sodass diese Dynos alle 24 Stunden neu gestartet werden, um
‫Ihre App in einem fehlerfreien Zustand zu halten.
‫Okay? Und Heroku
‫macht dies, indem es das sogenannte "Krankheitssignal"
‫an unsere Notizanwendung sendet, und die
‫Anwendung wird dann im Grunde sofort heruntergefahren.
‫Gut? Das Problem dabei ist,
‫dass das Herunterfahren sehr abrupt erfolgen kann.
‫Das kann dann Anfragen, die gerade bearbeitet
‫werden, quasi in der
‫Luft hängen lassen,
‫und das ist nicht optimal.
‫Das passiert im Grunde auch, wenn
‫es eine unbehandelte Ablehnung gibt.
‫Erinnern Sie sich also hier in unserem
‫Server, dot JS, daran, wie wir den
‫Server tatsächlich ordnungsgemäß heruntergefahren haben, wenn es eine
‫nicht behandelte Ablehnung gab. Gut?
‫Also werden wir
‫jetzt etwas ganz Ähnliches machen, wenn
‫wir das "Krankheitssignal" erhalten. Gut? Sagen wir also
‫Prozesspunkt bei
‫Krankheit, und im Grunde ist die Krankheit
‫im Grunde nur ein Ereignis, das gesendet
‫werden kann und das unsere Anwendung empfängt
‫und darauf reagieren kann.
‫Also genau wie die unbehandelte Ablehnung. Rechts?
‫Jetzt haben wir hier keinen Fehler,
‫und lassen Sie uns
‫hier tatsächlich ein
‫Konsolenprotokoll erstellen, sowie Krankschreibung erhalten.
‫Anmutig herunterfahren.
‫Und fügen wir hier einige Emojis
‫hinzu, um sie in unserer Konsole unter all
‫diesen Protokollen hervorzuheben, die wir dort haben.
‫In Ordnung, und jetzt machen
‫wir das ordnungsgemäße Herunterfahren, das im Grunde
‫nur dazu dient, den Server zu schließen.
‫Dadurch wird der Server im Grunde geschlossen, aber davor
‫werden noch alle ausstehenden
‫Anfragen bearbeitet. Und
‫genau das wollen wir, anstatt
‫eine ganz abrupte Beendigung der Bewerbung, oder?
‫Wenn das erledigt ist, sperren wir das an
‫die Konsole.
‫Also Konsolen-Punkteprotokoll,
‫fügen wir wieder ein
‫nettes Emoji hier hinzu Prozess beendet.
‫Okay. Und in diesem Fall
‫verwenden wir hier nicht den Prozess dot exit, da
‫der Krankheitstermin selbst dazu führt, dass die Anwendung geschlossen wird.
‫Wir müssen es nicht manuell tun, wie wir
‫es hier oben getan haben. Gut?
‫Im Grunde ist Krankschreibung ein Signal, das verwendet wird, um
‫zu bewirken, dass ein Programm wirklich
‫nicht mehr läuft. Es ist also eine
‫sehr höfliche Art, ein Programm zum Beenden aufzufordern. Okay?
‫Auch hier müssen wir dieses Abhören dieses Ereignisses hier
‫implementieren, da Heroku alle 24
‫Stunden unsere Anwendung
‫herunterfährt, indem es dieses Signal oder
‫dieses Ereignis an unsere Anwendung sendet.
‫Und so beenden wir den Prozess
‫ordnungsgemäß, indem wir server dot close
‫verwenden, wodurch alle ausstehenden Anfragen bis zum Ende
‫verarbeitet werden können. Okay?
‫Also, lassen Sie uns das jetzt tatsächlich testen.
‫Was wir also zuerst tun
‫müssen, ist natürlich alle diese Änderungen in unser
‫Git-Repository zu übertragen und Sie sehen,
‫dass wir im
‫Moment drei geänderte Dateien haben.
‫Also haben wir in dieser Vorlesung den Server
‫und in der letzten den Alt-Controller in App
‫dot JS modifiziert. Rechts?
‫Also, fügen wir sie alle zum Staging-Bereich git
‫add all hinzu und übertragen diese Änderungen
‫dann wirklich in unser Repository.
‫Also edit, Heroku, config.
‫Nennen wir es einfach so.
‫Gut. Und jetzt denken Sie
‫daran, wie wir die Anwendung im Grunde neu bereitstellen.
‫Nun, das ist ganz einfach.
‫Git push Heroku Addendum Master Branch.
‫Okay, das schickt nun im
‫Grunde alle Änderungen an diesen Branch und
‫baut dann die Anwendung
‫auf Heroku neu auf und startet sie natürlich auch neu.
‫Sie sehen also, dass es
‫all diesen Prozess wie bei der ersten
‫Bereitstellung der Anwendung jedes Mal neu durchführt,
‫wenn wir die Anwendung ein weiteres Mal bereitstellen.
‫Und jetzt ist das erledigt. Um zu testen, was wir
‫gerade hier gemacht haben, starten wir die Anwendung im Grunde
‫manuell neu. Und damit
‫wird dann auch das Krankschreiben an
‫die App gesendet und sollte auslösen was auch immer
‫hier passiert Okay? Beginnen wir also
‫mit einem Blick auf all unsere Prüfstände, das haben wir
‫noch nicht gemacht, das ist Heroku PS und
‫ihr seht also, dass wir
‫hier diesen einen kostenlosen Web-Prüfstand haben. Okay?
‫Was läuft, oder im Grunde,
‫was mit dem MPM-Startbefehl startet, wie ich
‫in einem der vorherigen Videos erwähnt habe.
‫Okay, was wir jetzt tun können,
‫um neu zu starten, ist ganz einfach Heroku PS und Neustart.
‫Also war es meiner Meinung nach nicht richtig.
‫Jetzt sollte es sein, und das ist getan.
‫Werfen wir nun einen Blick auf
‫die Protokolle, bei denen es sich um Heroku-Protokolle Dash Dash Tail handelt.
‫Alles klar, und hier ist
‫es.
‫Von unserer App kommend sehen wir die erhaltene Krankschreibung
‫und verarbeiten dann beendete Sperren.
‫Alles klar, und Sie sehen,
‫dass danach der Prozess mit dem Befehl
‫NPM start gestartet wird.
‫In Ordnung, und das ist
‫Serverpunkt JS, genau wie wir es angegeben haben,
‫und jetzt läuft die App auf Port 57 zwei sechs sieben.
‫Denken Sie also daran, wie ich vorhin gesagt habe,
‫dass Heroku seine App
‫im Grunde auf einem zufälligen Port ausführt. Und so ist das
‫hier. Gut? Groß!
‫Beenden wir das, bereinigen wir dies,
‫und damit packen
‫wir tatsächlich alle Heroku-Konfigurationssachen in unsere Anwendung ein.
‫Fantastisch. Jetzt bleiben nur noch
‫zwei Dinge übrig, nämlich
‫etwas namens CORS oder Cross Origin Resource Sharing
‫zu implementieren und dann auch die Stripe-Zahlungen mit
‫Webhooks abzuschließen. Denken Sie also daran,
‫wie ich versprochen habe, das etwas später umzusetzen,
‫und das werden wir in den nächsten beiden Vorlesungen tun.
‫Gut? Also bis dann in einer Sekunde.