Le cours Express.js - Module 10 : journalisation et traitement des erreurs

1. Introduction du cours: Bienvenue dans le module 10, consacré à journalisation et à la gestion des erreurs de la série de cours Express JS. Je m'appelle Shawn Ragawnhi, votre guide pour Au fil des ans, j'ai développé applications évolutives et robustes pour divers secteurs. Dans ce cours, je vous aiderai à aborder l'un des aspects les plus critiques du développement, de la journalisation et de la gestion des erreurs en backend journalisation et de la gestion des erreurs L'un de mes moments les plus fiers a été celui où j'ai conçu un système de journalisation qui a réduit le temps de débogage d' un client de 60 % Aujourd'hui, je vais vous montrer comment obtenir des résultats similaires. Dans ce module, nous nous concentrerons sur identification et la gestion efficaces des erreurs dans Express s, en simplifiant la gestion des erreurs avec des outils tels que les erreurs asynchrones d'Express, enregistrant les erreurs vers plusieurs destinations telles que les fichiers et MongoDB pour Ensuite, gérer les exceptions non détectées et les rejets non gérés pour garantir la stabilité de l'application Enfin, nous allons extraire et organiser les éléments clés de votre application enregistrement et la configuration des itinéraires , pour une base de code propre et maintenable Ce cours s'adresse aux développeurs qui souhaitent créer des Express Jas robustes et faciles Si vous avez terminé les modules précédents, vous êtes prêt à vous lancer. Des connaissances de base de JavaScript , de Jas et d'Express sont tout ce dont vous avez besoin pour commencer. En maîtrisant la gestion des erreurs et la journalisation, vous améliorerez considérablement la fiabilité de vos applications Vous économiserez également d'innombrables heures de débogage, ce qui fera de vous un développeur plus efficace et plus utile Enfin, pour le projet, vous allez créer un gestionnaire personnalisé pour gérer les journaux lors de plusieurs transports. Il s'agit de Console Files et de Manga DB. Ensuite, vous allez refactoriser l' application Fair Wheels en extrayant validation Joy et la logique du serveur dans des modules distincts Ces tâches pratiques consolideront votre compréhension de la gestion des erreurs et de la modularisation Ce module change la donne en vos compétences en matière de développement de backend Plongeons-nous dans le vif du sujet et rendons vos applications plus robustes que jamais. Rendez-vous à la première conférence, commençons. 2. Introduction : enregistrement et traitement des erreurs: Dans notre mise en œuvre actuelle de l'application Fairwee, nous avons opté pour un monde idéal où tout fonctionne correctement Cependant, dans le monde réel, il y a toujours des erreurs inattendues. Par exemple, il est possible que notre connexion à Mongo Deb soit interrompue pour une raison quelconque Il est donc recommandé tenir compte de ces situations inattendues et de les gérer correctement, ce qui signifie que vous devez envoyer un message d'erreur approprié au client et consigner l' exception sur le serveur. Plus tard, vous pourrez consulter le journal et voir quels sont les problèmes qui se produisent fréquemment et comment vous pouvez les améliorer. Permettez-moi donc de vous présenter un scénario réel dans lequel notre serveur Mongo EV meurt. Donc, ici dans le terminal, vous pouvez voir que je lance l' application avec le mod Nord. Et voici l'autre fenêtre de mon terminal où je lance Mongo Damon Il s'agit d'un service d'arrière-plan qui écoute sur le port 27017 Et ici, dans Postman, j'ai un onglet ouvert pour envoyer une demande d'API CR Ainsi, lorsque nous envoyons cette demande, nous recevons 200 réponses. Magnifique. Maintenant, de retour dans le terminal Mongo DB, je vais arrêter ce processus Permettez-moi donc d'ouvrir une nouvelle fenêtre Power Show et de taper le nom du meilleur service MongoDB. Et c'est tout. Notre serveur Mongo DV est maintenant arrêté. Voyons ce qui se passe lorsque vous envoyez cette demande une fois de plus. Donc c'est accroché. Après quelques secondes, nous allons voir un message d'erreur dans le terminal sur lequel nous exécutons l'application. OK, voici le message d'erreur. Erreur de sélection du serveur Mongo, de sélection du SRO, puis nous avons une sélection de serveur à valeurs dynamiques, délai S. Et voici l'erreur réelle interrompue à l'arrêt Ainsi, par défaut, lorsque vous vous connectez à Mongo DB, si la connexion ne peut pas être établie, pilote MongoDB tentera de se reconnecter trois fois avec un intervalle d'une seconde. Si vous faites défiler la page vers le bas, C, notre application s'est bloquée. Cela signifie que nous avons quitté le processus avec le code 1. Maintenant, dans cette démonstration en particulier, j'ai arrêté le serveur MongoIV, donc peu importe que ce processus soit actif ou non . Mais imaginons que dans un scénario réel, notre serveur Manga Divi soit en panne pendant, disons, 1 minute, puis qu'il revienne au bout d'une minute Avec la mise en œuvre actuelle, notre processus de nœud prendra fin et ne pourra servir aucun autre client même après le retour de Mongo Divi Il s'agit donc d'un problème très important. Nous devons donc gérer correctement ces scénarios, et c'est ce que nous allons apprendre dans cette section. 3. Erreur de sélection de serveur: Faisons maintenant le premier pas pour gérer correctement cette erreur. Ainsi, chaque fois que vous voyez une erreur de sélection de serveur, cela signifie que le client Manga B ne peut se connecter à aucun serveur du déploiement de Mangaib Cela se produit pour diverses raisons, telles que des sonneries de connexion incorrectes, des problèmes de réseau, une mauvaise configuration du serveur ou une incompatibilité de version Notez que cette erreur s'est produite lorsque nous avons essayé de récupérer des données depuis l'API de la voiture Passons donc à notre module sur les voitures. C'est le gestionnaire pour obtenir la liste des voitures. Nous avons donc ici une promesse qui est retournée ici. Nous attendons cela, mais nulle part dans ce code, nous n'avons un bloc de cache d'essai pour gérer les promesses rejetées. Cette implémentation revient à obtenir une promesse, à l' appeler, mais à ne pas appeler de l' argent pour gérer les erreurs. Donc, si vous utilisez la syntaxe promise, nous devons toujours appeler le cache pour gérer les exceptions. Si vous utilisez une synchronisation et Aviate, vous devriez toujours avoir des blocs de cache r. Ici, nous devons mettre ce code dans un bloc tri comme celui-ci , puis ajouter le bloc de cache où se trouve l'erreur. Maintenant, nous devons envoyer une réponse appropriée au client. Répondez donc à ce statut. Nous utilisons le code d'erreur 500, qui signifie une erreur interne du serveur. Donc, quelque chose a échoué sur le serveur, nous ne savons pas quoi. Et puis envoyez un message comme si quelque chose avait échoué. Techniquement, nous devrions également enregistrer l'exception ici, mais nous y reviendrons plus tard. Améliorons donc cette application étape par étape. Voyons maintenant comment fonctionne cette nouvelle implémentation. Donc, de retour dans le terminal, je vais d' abord démarrer Mangaibi car si nous ne le démarrons pas et ne lançons pas l'application, écoutez, nous ne pouvons pas nous connecter à Donc, au départ, je veux être connecté à Mangaib, puis je veux supprimer cette connexion quelque part entre les deux Arrêtons donc cette application. Revenons maintenant à la fenêtre du terminal. Exécutons le nom du service de démarrage Mangaib. Lancez maintenant notre application Fair Wheels. OK, connecté à Manga DV. Je vais commencer ce processus. Encore une fois, le meilleur nom de service Manga DV. Ensuite, ici dans Post MD, je vais envoyer une demande pour le point de terminaison de la voiture. Cela va prendre 30 secondes, je vais donc suspendre l' enregistrement et revenir. D'accord. C'est ce que nous obtenons. 500 erreurs internes au serveur. Et c'est notre message. Maintenant, si vous regardez la fenêtre du terminal de notre application, vous ne voyez plus cette erreur de sélection du serveur, qui a entraîné la fin de ce processus. 4. Erreur dans le middleware dans Express: Lors de la dernière conférence, nous avons donc fait le premier pas pour gérer correctement les erreurs. Mais il y a un problème dans la mise en œuvre actuelle. Imaginons que demain nous décidions de modifier le message que nous envoyons au client. Avec l'implémentation actuelle, nous devons passer en revue tous les gestionnaires de route dans lesquels nous utilisons ce bloc Trcche et modifier Donc, dans une situation réelle, nous allons enregistrer ici l'erreur. Encore une fois, si à l'avenir, nous décidons de modifier la façon dont nous enregistrons l'erreur devrons revenir à plusieurs gestionnaires de routes et apporter cette modification Nous voulons donc déplacer cette logique gestion des erreurs vers un endroit central. À l'avenir, nous voulons donc modifier la logique de gestion des erreurs. Il y a un seul endroit que nous devons modifier. Passons donc au point d'index g. C'est ici que nous enregistrons nos fonctions intergicielles Dans Express, nous avons un type spécial de fonction d' intergiciel appelé intergiciel d'erreur Nous enregistrons cette fonction intergicielle après toutes les fonctions intergicielles existantes Ici, nous appelons l'application américaine et lui transmettons une fonction middleware avec trois paramètres, réponse à la demande et la suivante Mais nous ajoutons également un quatrième argument ici au début. C'est l'exception ou l'erreur que nous détectons ailleurs dans l'application. Maintenant, dans cette fonction, nous ajoutons toute la logique de gestion des erreurs dans notre application. Revenons donc aux voitures Js. Je vais couper cette logique à partir d'ici et la coller ici. Maintenant, revenons aux voitures J. une fois de plus. Ici, dans ce bloc de cache, nous voulons passer le contrôle à notre fonction middleware de gestion des erreurs Nous ajoutons donc un nouveau paramètre ici, ensuite. Et comme vous le savez, nous appelons next to pass control la fonction middleware suivante dans le pipeline de traitement des demandes Ici, dans le bloc de cache, nous appelons next et passons cette erreur en argument. Maintenant, comme dans index ou Js, nous avons enregistré cette fonction après toutes les fonctions intergicielles existantes, lorsque nous appellerons next, nous nous retrouverons Et l'erreur que nous transmettrons sera le premier argument de cette fonction. Avec cette nouvelle implémentation, nous disposons désormais d'un seul endroit pour gérer les erreurs. Donc, si vous souhaitez apporter des modifications à l'avenir, nous ne ferons que modifier cette fonction. Dans une application du monde réel, la logique de journalisation de l'exception ou des erreurs peut être longue de plusieurs lignes. Nous ne voulons pas ajouter tous les détails dans le point d'index Js. Donc, dans index ou Js, nous voulons simplement faire de l'orchestration Nous voulons conclure un accord de haut niveau. Les détails doivent être encapsulés dans un autre module. Je vais donc déplacer cette fonction, cette fonction middleware vers un module séparé Donc, de retour ici, nous avons ce dossier intergiciel. Ajoutons un nouveau fichier ici, point d'erreur Js. Pour en revenir à l'index Js, je vais obtenir cette fonction ici et, par erreur Js, définir les exportations de modules sur cette fonction. Nous avons donc séparé les détails de la gestion des erreurs dans un module distinct, ce qui permet de mieux séparer les préoccupations. En index ou en Js en haut, nous devons charger ce module. Donc erreur const. Nous avons défini ce paramètre sur require. Ensuite, nous montons d'un niveau dans le dossier du middleware et déchargeons le Enfin, ici, nous appelons app point g et lui transmettons notre fonction de gestion des erreurs. Notez que je n' appelle pas cette fonction. Je ne fais que transmettre une référence à cette fonction. Notre application a donc maintenant un meilleur design. Cependant, dans cast ou Js, nous avons ce bloc de cache try, et comme vous pouvez le constater, nous devons répéter dans chaque gestionnaire de route de notre application Nous devons ajouter cette erreur de cache, et ici nous devons appeler next. C'est répétitif. Dans la prochaine conférence, je vais donc vous montrer comment améliorer cette implémentation. 5. Éliminer les blocages par essais et attrapages: Dans ce gestionnaire de route, nous avons un bloc de cache try pour gérer les erreurs Le problème est que nous finirons par répéter ce bloc de cache try dans chaque gestionnaire de route Cela ajoute beaucoup de bruit à notre code et rend plus difficile de se concentrer sur la logique réelle de chaque itinéraire. C'est juste distrayant. Idéalement, nous voulons déplacer cette logique de gestion des erreurs de haut niveau vers une fonction unique que nous pouvons réutiliser sur toutes les routes. Laissez-moi vous montrer comment nous pouvons le faire. Tout d'abord, nous allons créer une fonction réutilisable appelée intergiciel asynchrone Cette fonction servira de modèle. Il inclura le bloc de cache tri dont nous avons besoin, mais nous le rendrons flexible afin qu'il puisse s'adapter aux différents gestionnaires d'itinéraires La fonction prendra donc un gestionnaire de route comme argument comme celui-ci À l'intérieur du bloc tr, nous appellerons ce gestionnaire En cas de problème, le bloc de cache transmettra la fonction d'erreur suivante du middleware Ainsi, la seule partie qui change pour chaque route est une logique spécifique dans le gestionnaire Tout le reste reste pareil. Bien, définissons ce middleware asynchrone. Cette fonction ressemblera donc à ceci. Il prend un gestionnaire de route comme argument à l'intérieur, nous enveloppons le gestionnaire dans un bloc de cache tr Si le gestionnaire génère une erreur, le bloc de cache appelle next avec l'exception Utilisons maintenant ce middleware dans notre itinéraire. Ainsi, au lieu d'écrire ce bloc de cache tr directement dans le gestionnaire de route, nous passons cette fonction à un intergiciel asynchrone Ce middleware se chargera de la gestion des erreurs pour Nous n'avons donc pas besoin du paramètre suivant, du bloc tr et du bloc de cache. Notre code de route devient donc beaucoup plus propre. Maintenant, regardez cette fonction ASN, la fonction anonyme que nous transmettons en tant que gestionnaire de route Finalement, nous voulons transmettre cette fonction ASN comme argument à cette nouvelle fonction Maintenant, comme le gestionnaire est une fonction ASN, nous devons l'attendre Et comme nous avons utilisé await ici, nous devons également marquer cette fonction comme AS. Il y a maintenant un petit problème que nous devons résoudre. Lorsque vous appelez le gestionnaire dans Async Middleware, nous devons transmettre la réponse à la demande et les paramètres suivants nous devons transmettre la réponse à la demande et les paramètres suivants. Mais voici le hic. Ces objets ne sont définis nulle part dans un intergiciel de synchronisation Alors, comment accéder à ces paramètres ? Eh bien, pour résoudre ce problème, nous devons comprendre comment fonctionne Express. Donc ici, lorsque nous définissons une route router dot get, disons nouvelle route. Ici, nous passons une fonction de gestionnaire de route qui prend trois paramètres, réponse à la demande et ensuite, et elle passe à un diagramme de code Nous n'appelons donc pas cette fonction notre service de vente. Au lieu de cela, nous passons une référence à cette fonction, et Express se charge de l' appeler et de transmettre les arguments requis. Il s'agit de la réponse à la demande et de la suivante au moment de l'exécution. Mais dans notre implémentation actuelle, nous appelons directement Async Middleware Ce n'est pas ainsi qu'Express s'attend à ce que cela fonctionne. Nous devons apporter un petit changement ici. Nous allons donc transformer cette fonction d'intergiciel asynchrone en fonction d'usine Donc, au lieu de l'appeler directement, nous allons lui faire renvoyer une nouvelle fonction. Cette fonction renvoyée agira comme le véritable gestionnaire de route qu'Express peut appeler Cette nouvelle fonction renvoyée acceptera donc la réponse à la demande, et ensuite en tant que paramètres. Et à l'intérieur, il appellera le gestionnaire d'origine, que nous passerons au Middleware asynchrone, transmettant la réponse à la demande et ensuite Désormais, lorsqu'Express appelle cette fonction renvoyée, elle fournit les objets nécessaires. C'est la réponse à la demande et ensuite, et tout fonctionnera parfaitement. Lors de l'installation, nous avons déplacé le tricchblock dans un intergiciel asynchrone Cela signifie que nos gestionnaires d'itinéraires sont désormais très propres. Nous attendons l' appel au gestionnaire, nous devons donc marquer la fonction d'appel, qui est cette fonction, comme asynchrone Et nous n'avons plus besoin d'appliquer cette fonction asynchrone ici , car dans cette fonction du middleware asynchrone n' attendons aucune promesse, nous renvoyons simplement une nous renvoyons simplement OK ? Enfin, rendons le middleware asynchrone Nous allons donc le déplacer vers un module distinct ici dans notre dossier middleware Créons un nouveau fichier appelé async Js. Permettez-moi de couper le code pour Async Middleware à partir d' ici et de le coller ici Enfin, nous allons l'exporter sous forme de module thought exports, et nous l'avons défini sur fun engine. De retour ici dans Casta Js, il suffit de charger ce middware asynchrone. Donc, en haut, const async middleware. Nous l'avons configuré pour requérir ensuite le dossier middleware et async Et c'est tout. Vous pouvez désormais utiliser ce middleware dans n'importe quel gestionnaire de route de votre application. Ainsi, avec cette approche, votre cœur devient plus propre, plus concentré et plus facile à entretenir. 6. Utiliser le module Errors Express Async: Dans la dernière conférence, nous avons défini cette fonction d' intergiciel asynchrone Maintenant que cette fonction d' intergiciel asynchrone résout le problème des blocs tr cach répétitifs, le problème que nous avons est que nous devons nous rappeler de l'appeler à Et cela rend également notre cordon un peu bruyant. Dans cette conférence, je vais donc vous montrer une approche différente. Nous allons utiliser un module NPM, et ce module patchera uniquement nos gestionnaires de routes lors Ainsi, lorsque nous envoyons une demande à ce point de terminaison, ce module encapsule le code de notre gestionnaire de route dans quelque chose comme ça Laissez-moi vous montrer comment cela fonctionne. Ouvrez donc un terminal et installez Express, async errors. Installons-le. Passons maintenant à index ou Js. Nous devons charger ce module au démarrage de l'application. Nous aurons donc besoin d' erreurs asynchrones express. C'est tout ce que nous devons faire. Vous n'avez pas besoin d'obtenir le résultat et de le stocker dans une constante. Maintenant, de retour dans Cars ou JS, nous pouvons supprimer l'appel à Async Middleware et revenir à l'implémentation initiale de notre gestionnaire de route, qui est beaucoup De même, je vais supprimer le deuxième appel au middleware Async Enfin, en haut de la page, je vais également supprimer l'instruction requise. Maintenant, testons cela et vérifions-nous qu'il fonctionne correctement. De retour dans le terminal, je vais lancer notre application Fairwheels Maintenant, dans les facteurs, je vais chercher toutes les voitures. Ce point de terminaison fonctionne donc. Maintenant, je vais arrêter Manga DB. Donc, ici, dans le terminal Manga Di B, arrêtons cela avec le nom de service principal Manga DB , puis envoyons une autre demande au serveur pour qu'il l'envoie à nouveau. Cela va prendre un petit moment. Très bien, voici la réponse à laquelle nous nous attendions : une erreur 500 avec ce message. Cela vérifie donc que ce module que nous avons installé a correctement déplacé le contrôle d'un gestionnaire de route vers notre fonction de gestion des erreurs Vous pouvez donc voir que l'utilisation erreurs Express Async est très, très simple Et c'est l' approche que je suggère pour gérer les erreurs asynchrones dans les gestionnaires de route express Toutefois, si ce module ne fonctionne pas pour votre application pour une raison quelconque, vous devez revenir à cette autre approche et utiliser la fonction de middleware asynchrone 7. Erreurs de journalisation: Il s'agit de notre intergiciel d'erreur. Maintenant, comme je vous l'ai déjà dit, dans chaque application d'entreprise, nous devons enregistrer les exceptions émises dans l'application. Plus tard, nous revenons, examinons le journal et voyons quels sont les domaines de l'application que nous pouvons améliorer. Dans cette conférence, je vais donc vous présenter une bibliothèque de journalisation très populaire appelée Winston Voici donc le Winston sur NPM. La version actuelle est 3.17. Et comme vous pouvez le constater, il y a eu plus de 13 millions de téléchargements hebdomadaires. C'est une bibliothèque très populaire et riche en fonctionnalités. Commençons donc. Ici, dans le terminal, NPM installe Winston Magnifique. Revenons maintenant à la page NPM Ici, vous pouvez voir que la méthode recommandée pour utiliser Winston est de créer votre propre enregistreur Et ci-dessous, nous avons un exemple de code pour commencer. Je vais donc simplement copier ce code et le modifier en fonction de notre application. Copiez tout cela et collez-le ici dans arrodt Js. En haut, nous avons notre module Winston. Ensuite, nous avons notre enregistreur, qui est créé à l'aide de cette méthode de création d'enregistreur Il contient un objet avec peu de propriétés, de niveau, de format, de méta par défaut et de transports. Permettez-moi donc de vous expliquer comment cela fonctionne. Tout d'abord, nous avons le niveau de journalisation. Le niveau contrôle donc quels journaux doivent être traités. Cela signifie qu'il filtre les journaux par gravité. La gravité de tous les niveaux est donc supposée être numériquement croissante du plus important au moins important Cela signifie que si nous avons une erreur, elle a une gravité de zéro et elle a la priorité la plus élevée. De même, nous en avons un, info, STDP et verbs debug et silly avec une sévérité de six, et il a Ici, nous avons défini le niveau par défaut sur info, ce qui signifie que tous les messages d'information, avertissement et d'erreur seront retardés Et si nous définissons le niveau sur les verbos, tous les messages des verbes et des niveaux supérieurs seront verrouillés Ensuite, nous avons le format. Un format est donc utilisé pour personnaliser l'affichage des journaux. Il s'agit d'un texte brut, d'un objet JCN ou d'un horodatage Et il existe d'autres formats, ceux-ci sont implémentés sous forme de journal, un module distinct de Winston, et vous pouvez consulter ce module pour voir tous les formats disponibles Ici, nous allons utiliser le JCNFMat et nous n'avons pas besoin de cette Maintenant, cet objet enregistreur possède un tableau de transports. Un transport est donc essentiellement un support de stockage pour nos journaux. Il définit donc où les journaux sont envoyés. Winston est livré avec quelques moyens de transport de base. Il s'agit de la console pour enregistrer les messages sur la pile de console et protocole HTTP pour appeler un point de terminaison SDDB pour la journalisation des Il existe également des plugins pour Winston. Il existe d'autres modules NPM pour la journalisation des messages dans Mongo DB et COS DB, une autre base de données non SQL populaire Il existe également un plugin pour enregistrer les messages dans Redis et Loge, qui est un service d'analyse et de surveillance des journaux très populaire pour les applications d'entreprise Nous allons maintenant utiliser deux transports différents, l'un pour enregistrer les messages dans un fichier et l'autre pour les connecter à la console. Permettez-moi donc de changer celui-ci en console. Et nous n'avons pas besoin de cette propriété de nom de fichier ici. Notre enregistreur est prêt à être utilisé, et si vous souhaitez simplement avoir un fichier de journaux au format JSON, cette quantité de code est suffisante pour le faire Cependant, Winston ne se limite pas à cela. Il est également possible de définir un format personnalisé et un niveau personnalisé pour chaque transport séparément. Et n'importe quel nombre de formats peuvent être combinés en un seul format à l'aide de la combinaison de points de format. Je vais donc utiliser quelques formats dans nos transports, puis les combiner pour une meilleure expérience. Laissez-moi vous montrer comment procéder. Tout d'abord, supprimons ce niveau et ce format par défaut. Maintenant, sur la console, je souhaite utiliser des couleurs pour enregistrer les niveaux en fonction du mappage personnalisé. Pour cela, nous pouvons utiliser format coloriser et le combiner avec un format simple Ici, ajoutez un format de propriété, puis nous appelons la méthode combinée, la combinaison de points au format Winston Dot et transmettons simplement les formats que nous voulons combiner Donc Winston Dot Format Dot Dot Dot Dot Dot Dot Dot Dot Simple Nous voulons également lui donner des informations sur le niveau. Donc, comme je l'ai déjà mentionné, tous les messages d'info one et de niveau d'erreur seront enregistrés sur la console. C'est ça. De même, nous pouvons personnaliser notre transport de fichiers. Comme vous pouvez le constater, le niveau personnalisé est déjà défini sur erreur. Génial. Ici, nous voulons rendre les journaux plus lisibles en ajoutant la date et l'heure actuelles. Cela peut être fait en combinant les formats horodatage et JCN. Alors, encore une fois, j'appelle Combine. Et puis passez wstin point forma dot Time STAMP et instin point fam point JCN Ce faisant, nous avons ajouté un horodatage à chaque erreur susceptible de se produire dans l'objet JSN Enfin, nous devons utiliser cet enregistreur dans notre intergiciel d'erreurs Nous appelons donc logger point log. Ensuite, nous passons un objet avec un niveau de propriété, que nous pouvons définir sur error ou vous pouvez simplement utiliser la méthode d'assistance aux erreurs pour enregistrer directement l'erreur. Comme ça. Il ne nous reste plus qu'à transmettre le message d'erreur. Nous avons donc défini la propriété du message sur err point message. Maintenant, pour le démontrer, passons à cars dot js. Ici, dans l'itinéraire Get Cars, je vais générer une erreur. Alors lancez une nouvelle erreur, impossible de récupérer les voitures. Imaginons donc que quelque part dans l'application, une erreur soit générée avec l'implémentation actuelle. Notre intergiciel d'erreur détectera cette exception. Il l'enregistrera à l'aide de Winston et renverra l' erreur 500 au lien Alors testons cela. Je vais lancer l'application, Norman Beautiful. Maintenant, de retour dans Postman, envoyons une requête get au point de terminaison de la voiture D'accord. Voici donc notre erreur interne de serveur. Maintenant, si vous regardez la console, nous avons une erreur car nous avons utilisé la méthode d'erreur par points de Winston, et sa couleur est rouge Et voici le message d'erreur que nous avons envoyé, nous pas pu récupérer les voitures Il s'agit donc du transport par console que nous avons personnalisé sur l'enregistreur Maintenant, dans notre projet, vous pouvez voir ici que nous avons ce nouveau fichier, le journal des points d'erreur. Nous avons ici un objet JSON avec quelques niveaux de propriétés, dont le message d'erreur ne peut pas récupérer les voitures et l'horodatage Ainsi, à l'avenir, vous pourrez interroger le fichier journal et peut-être extraire uniquement les erreurs à une date précise. C'est donc une vue d'ensemble. Nous appelons simplement logger point error ou l'une des méthodes auxiliaires. Et en fonction du transport que nous avons configuré, Winston enregistrera le message donné Dans la prochaine conférence, je vais vous montrer comment vous connecter à Mongo DB 8. Connexion à MongoDB: C'est bon. Maintenant, laissez-moi vous montrer comment enregistrer des messages sur Manga Deb. La connexion à Mangaib est rendue assez simple avec un autre package NPM, assez simple avec un autre package NPM, Winston Mangaib. Alors, installons-le. Installez Winston Mangaib par NPM. La version 6.0 0.0. Assurez-vous donc d'avoir exactement la même version. Sinon, ce que je vais vous montrer ne fonctionnera pas dans votre système. Retour dans E Js Lors de la dernière conférence, nous avons ajouté des transports personnalisés de fichiers et de consoles. Nous allons maintenant ajouter un nouveau transport Manga Divi. Tout d'abord, nous devons aller au sommet. Après avoir chargé Winston, nous devons charger Winston Manga DB require Winston Manga require Winston Et ici, nous ne nous soucions pas de ce qui est exporté depuis ce module. Nous avons juste besoin de l'exiger. D'accord, nous pouvons venir ici et appeler logger point at new Winston Dot at new Winston Dot transporte Manga B. Nous transmettons un objet d'options Vous trouverez ici quelques propriétés que vous pouvez consulter dans la documentation. Celui que vous devez définir est DB. Nous l'avons donc définie sur la chaîne de connexion de notre base de données, Manga DB holland 127.0 0.0 0.142 7017 fair wheels Maintenant, dans un scénario réel, vous souhaiterez peut-être séparer votre journal de votre base de données opérationnelle. C'est une décision qui varie d'un environnement à l'autre. Ici, nous allons utiliser la même base de données pour enregistrer nos erreurs. C'est bon, on en a fini avec ça. Maintenant, nous n'avons pas besoin d' apporter d'autres modifications. Donc, la prochaine fois qu'il y aura une erreur dans l'application parce que nous avons un autre transport, Winston enregistrera automatiquement notre erreur dans Mongadib Lancez donc à nouveau l' application. Et de retour dans Postman, envoyez une demande au terminal de la voiture Jetons maintenant un coup d'œil à MongoAV Compass. Voici donc notre base de données Fairwheel. Rafraîchissons-le. Nous pouvons voir que nous avons un nouveau journal de collecte, et c'est le message qui nous manquait. Voici donc l'horodatage. Le niveau est défini sur erreur. Et voici le message, impossible d'aller chercher des voitures. Dans la dernière conférence, j'ai parlé de la définition d'un niveau personnalisé pour chaque transport séparément. Alors ici, vous voulez peut-être uniquement verrouiller les erreurs dans Mongoib Vous ne souhaitez pas stocker de messages d'information ni de messages de débogage Si tel est le cas, dans l'objet options, vous définissez également la propriété level sur error. Ainsi, seuls les messages d'erreur seront enregistrés. Maintenant, comme nous l'avons indiqué précédemment, si vous dites cela à info, étant donné que le niveau d'information a une priorité de deux et se situe au troisième niveau de journalisation, seuls l'avertissement d'erreur et les messages d'information seront enregistrés. Rien d'autre que des informations ne sera enregistré dans Manga Divi. 9. Exceptions non attrapées: Désormais, cet intergiciel d'erreur que nous avons ajouté ici ne détecte que les erreurs qui se produisent dans le cadre du pipeline de traitement des demandes Cela est donc propre à Express. Si une erreur est générée en dehors du contexte d'Express, ce middleware ne sera pas utilisé Laisse-moi te montrer. Au bas de ce fichier, après l'exportation, je vais lancer une nouvelle erreur. Alors lancez une nouvelle erreur, quelque chose a échoué au démarrage. Cette erreur est donc renvoyée en dehors du contexte du traitement d'une demande. Cela ne fait pas partie du contexte d'Express. Alors maintenant, lorsque j' exécuterai cette application, vous verrez que cette erreur bloquera le processus et que Winston ne pourra pas l' enregistrer dans le journal Pour vérifier cela, laissez-moi accéder à notre fichier journal, supprimer tout ici, enregistrer maintenant dans le terminal. Lancez notre application. Norman, d'accord, vous pouvez donc voir que notre application s'est écrasée, et voici notre erreur. Quelque chose a échoué au démarrage. Et si vous regardez le fichier journal, vous pouvez voir qu'il n' y a rien ici. Ainsi, si vous déployez cette application en production, ne fonctionnera pas et vous n'aurez aucun moyen de savoir ce qui s'est passé si vous n'avez accès à la console sur le serveur. C'est là qu'intervient Winston. Il vous permet de détecter et d' enregistrer les exceptions non supprimées sans effort Dans cette conférence, je vais donc vous montrer comment gérer correctement les exceptions non détectées dans un processus à nœuds C'est à un niveau supérieur. Ce n'est pas lié à l'expression. Maintenant, de retour dans EOD ou Js, ici, lors de la création de votre enregistreur, ajoutez la propriété d'un gestionnaire d'exceptions et transmettez-lui un tableau contenant une instance de transport Donc des gestionnaires d'exceptions. Nous l'avons défini sur un tableau où nous transmettons une instance de transport, nouveau Winston point transporte un fichier de points Il prend un objet avec un nom de fichier de propriétés. Et ici, nous voulons enregistrer les exceptions non coupées dans un fichier séparé Permettez-moi donc d'appeler cela un journal des points d'exceptions. Et c'est tout. Facile, non ? Et si vous avez déjà configuré un enregistreur et que vous souhaitez activer la gestion des exceptions ultérieurement ? Cela ne pose aucun problème. Vous pouvez utiliser la méthode de gestion des points des exceptions. Laisse-moi te montrer. Je vais donc le recommander et ci-dessous, après avoir défini notre enregistreur, nous appelons logger point exceptions point handle et transmettons l'instance de transport comme nous le faisions Donc, le nouveau fichier à points de transport. Exceptions relatives au nom de fichier, décalage par points. Cette approche est désormais idéale pour apporter de la flexibilité à mesure que votre application évolue. Enfin, nous ne voulons pas que notre application plante après avoir enregistré l'exception non coupée Par défaut, Winston quitte le processus après avoir enregistré une exception non détectée Vous pouvez désactiver ce comportement en définissant la propriété exit on error sur falls lors de la création de votre enregistreur Ici, après les gestionnaires d' exceptions, nous définissons exit en cas d'erreur sur falls, ou vous pouvez l'attribuer dynamiquement comme ceci Le point du logger en cas d'erreur est faux. Et permettez-moi de commenter celui-ci. Maintenant, de retour dans le terminal, exécutons-le encore une fois. Notez que cette fois, le processus ne s'est pas arrêté car nous avons détecté l'exception ici. Le processus s'arrête donc si vous ne détectez aucune exception OK ? Jetons maintenant un coup d'œil à notre fichier journal des exceptions. Vous pouvez voir notre message d'erreur, quelque chose a échoué au démarrage. Avec Winston, vous pouvez facilement gérer les exceptions non supprimées et contrôler le comportement de nos applications inattendues Dans la prochaine conférence, nous examinerons les rejets de promesses non gérés 10. Refus non gérés: Lors de la dernière conférence, nous avons parlé de la gestion des exceptions non détectées Ainsi, s'il existe une exception dans votre application et que vous ne l' avez pas détectée à l'aide d'un bloc de cache, vous pouvez utiliser cette propriété de gestionnaire d'exceptions de l'enregistreur pour l'enregistrer dans un fichier à l'aide Tout comme pour les exceptions non détectées, Winston facilite la mise en cache et l'enregistrement des rejets non gérés Avec la configuration actuelle, un rejet non géré sera également enregistré dans notre fichier journal des exceptions sans faire planter l'application Laisse-moi te le montrer. Donc, ici, dans error point Js, nous lançons une exception. Remplaçons cela par une promesse rejetée. C'est une promesse si constante. Nous avons défini ce paramètre pour promettre un point, rejeter et transmettre un objet d'erreur avec un message, promesse rejetée. Imaginez donc que ce processus représente le résultat d'une opération asynchrone telle un appel à une base de données ou à un service TDP distant, Nous avons donc une promesse rejetée. Et comme je vous l'ai déjà dit, pour les promesses, soit nous les appelons, puis nous devons appeler catch pour nous assurer de gérer les rejets, soit si nous utilisons la syntaxe Async et await, nous attendons la promesse, mais nous devrions la mettre dans un block de cache try pour détecter les exceptions ou les Dans ce code, nous avons une promesse, et je vais appeler puis passer une simple console de rappel point log D. Mais je ne vais pas appeler le cache Nous aurons donc un rejet non traité. Maintenant, si vous lancez l'application Nomon, notre application fonctionne correctement. Et si vous consultez le fichier journal des exceptions, voici notre promesse de rejet non traitée rejetée Winston l'a donc automatiquement détectée comme une exception non détectée et l'a enregistrée sur exceptions point log IL. Cependant, avec Winston, vous disposez un gestionnaire de rejet de propriété pour gérer séparément les pour gérer Laissez-moi vous montrer comment faire. Ici, vous pouvez activer la gestion des rejets lors de la création de votre enregistreur Ainsi, tout comme nous ajoutons des gestionnaires d' exceptions, nous pouvons ajouter des gestionnaires de rejet et leur transmettre une gamme d'encens pour le transport Donc, les gestionnaires de rejet, définissez-le sur un tableau. Ensuite, nous passons devant une nouvelle pile de points Winston Dot Transports. Il prend un objet avec un nom de fichier. Maintenant, je veux enregistrer les refus séparément. Je vais donc l'appeler rejections point log, et c'est tout Cette configuration écrit un fichier journal à points dédié à tous vos rejets non gérés points dédié à tous vos rejets Et si vous avez déjà configuré votre enregistreur et que vous souhaitez gérer les rejets de promesses ultérieurement ? Tout comme la gestion des exceptions, Winston fournit la méthode de gestion des rejets. Permettez-moi donc de le commenter ci-dessous. Juste après avoir appelé logger point exceptions, nous appelons logger point rejections point handle et transmettons simplement à une instance de transport new Winston point ransport point filename file filename reactions point lag Cette approche vous permet d'ajouter un transport spécifique pour les rejets, même après l'initialisation de votre enregistreur Testons-le donc à nouveau dans le point JS d'index du nœud terminal. C'est bon. Regardez cet avertissement, un rejet non traité. Et voici notre erreur. Maintenant, si vous regardez le journal, nous avons un nouveau journal à points des rejets de fichiers Écoutez, voici notre rejet non géré de la promesse, et cette fois, il n'est pas enregistré dans le fichier journal des exceptions Maintenant, avec la version actuelle de node, ce rejet de promesse non géré devrait mettre fin au processus de nœud Mais comme vous pouvez le constater, ce processus est toujours en cours. Nous sommes connectés à Mongo DB. Cela s'est produit à cause de la propriété exit en cas d'erreur dans notre enregistreur, que nous avons définie sur falls Ainsi, qu'il s'agisse d'une exception non détectée ou d'une réaction non gérée, il est recommandé mettre fin au processus du nœud Vous devez donc sortir d'ici, car à ce stade, votre processus peut être dans un état impur meilleure pratique consiste donc mettre fin au processus et à le redémarrer pour nous assurer de démarrer avec un état propre. Maintenant, vous vous demandez peut-être, si nous mettons fin au processus, comment allons-nous le redémarrer en production ? Eh bien, il existe des outils pour cela, que nous appelons des gestionnaires de processus. Et à l'avenir, nous allons examiner l'un d'entre eux. Je vais donc modifier ce code, et nous supprimons simplement la propriété exit en cas d'erreur, car par défaut, Winston se ferme après avoir enregistré une exception non détectée ou un rejet non géré Une question que vous pourriez vous poser est de savoir si vous devez enregistrer les messages dans un fichier ou dans une base de données telle que Manga Div. Les opinions divergent à ce sujet, mais je pense personnellement que vous devriez utiliser les deux moyens de transport, car chaque transport a ses forces et ses faiblesses. Manga Di B ou d'autres bases de données sont utiles pour interroger des données. Ainsi, si vous souhaitez créer une application cliente pour interroger votre journal, il est beaucoup plus facile d' interroger les données dans Mongo DB plutôt que dans un fichier plat comme celui-ci Cependant, il est possible que votre serveur de base de données Mongo tombe en panne ou que vous ne puissiez pas vous y connecter pour une raison quelconque Dans ce cas, il est préférable d'utiliser le système de fichiers car le système de fichiers est toujours disponible. Dans un environnement de production, rejets de promesses non gérés peuvent passer inaperçus Ainsi, nous avons créé une piste d'audit indiquant ce qui s'est mal passé et pourquoi. Et c'est ainsi que l'on gère les refus non gérés avec Winston Qu'il s'agisse d'exceptions absolues ou de refus de promesses, Winston vous aide à maintenir visibilité et la fiabilité 11. Extraire des routes: Très bien, voici le code en index ou en JS. Le principal problème que nous avons ici est l'absence de séparation des préoccupations. Il se passe tellement de choses ici, et c'est pourquoi nous avons un grand nombre d' instructions obligatoires en haut de ce module. En dessous, vous pouvez voir que nous avons un code de configuration. Ensuite, nous avons quelque chose de complètement différent, qui consiste à se connecter à la base de données Mongo Di Ba Ensuite, nous passons à la configuration de nos itinéraires dans divers intergiciels Ce sont là des préoccupations différentes. Ils ne doivent pas être mélangés dans un seul fichier ou un seul module. Dans ce module, nous ne devons qu'orchestrer ces préoccupations Les détails les concernant doivent donc être déplacés vers différents modules. Par exemple, les détails de la configuration des itinéraires ou les détails de la connexion à base de données Mongo DB doivent être séparés Dans cette conférence, nous allons donc nous concentrer sur l' extraction des routes dans un module distinct Créons donc un nouveau dossier appelé initialize. Ici, je vais ajouter un nouveau fichier routes point JS, et ici nous devrions exporter une fonction. Donc le module point Exports. Nous lui attribuons une fonction. Maintenant, dans cette fonction, je vais ajouter tout le code pour configurer nos itinéraires et autres intergiciels Donc, de retour dans index ou Js, je vais couper tout le code et le déplacer ici. Regardez donc les dépendances ici. Nous dépendons des objets d' application à exprimer, tous ces routeurs, tels que les entreprises, les clients, etc. Donc, de retour dans l'index ou Js en haut de la ligne 14, voici comment nous créons l'objet de l'application. Nous devrions en avoir une seule instance dans l' ensemble de l'application. En d'autres termes, nous ne voulons pas charger Express puis l'appeler pour créer un objet d'application dans notre nouveau module. Nous voulons donc envoyer une référence à cette application à ce nouveau module. Cette fonction doit donc prendre app comme argument. D'accord ? Maintenant, de retour dans index ou Js, nous avons ici l'objet de l'application. Nous pouvons charger notre nouveau module qui est des routes initialisées. Cela renvoie une fonction, nous l'appelons donc et lui transmettons l'objet de l'application. C'est ça. C'est tout ce que nous avons à faire. Maintenant, nettoyons ce module. Donc, tous ces routeurs que nous avons importés ici, comme les entreprises, les clients, etc., devraient tous être déplacés vers notre nouveau module car nous ne les avons référencés nulle part ailleurs dans le module d'index Alors réduisez ici, collez-les sur le dessus. Nous avons ajouté la plupart des dépendances. Nous avons également besoin d'Express et du middleware d'erreur. Nous pouvons donc charger l'Express sur le dessus, const Express. Exige Express. Maintenant, pour ce qui est du middleware d'erreur, je vais le retirer de index ou de Js car c'est le seul endroit où vous faites référence à cette le seul endroit où vous faites référence Voici notre intergiciel d'erreur. Réduisez le nombre de routes ou de JS, et ajoutons-le ici. Maintenant, revenons à index ou à Js, vous pouvez voir que le noyau de ce module est déjà beaucoup plus court. Nous n'avons plus autant d'instructions requises, et l'implémentation est également un peu plus propre. Enfin, revenons au module routes, nous devons changer les chemins d'accès à ces routeurs car le dossier des routes ne se trouve pas dans le dossier initialisé Donc, chaque fois que nous aurons une barre oblique périmétrique, je vais la remplacer par une J'ai donc sélectionné ici ces deux personnages. Dans le code VS, nous pouvons activer l'édition multi-curseurs. Je maintiens les touches Ctrl et D enfoncées sous Windows. Si vous utilisez un Mac, le raccourci est probablement Command D. Donc, vous voyez, je sélectionne plusieurs instances puis nous pouvons toutes les remplacer en une seule fois. Donc, point final. Terminé. 12. Extraire la logique de la capture: Voici notre intergiciel Error Js. Dans cette conférence, nous allons déplacer tout le code de configuration de journalisation avec un module différent. C'est tout ce qui est lié à Winston et à la gestion des promesses rejetées et des exceptions non prises Donc, dans le dossier initialisé, ajoutons un nouveau fichier en enregistrant point js, puis en saisissant à nouveau point js d'erreur Prenez tout ce code pour configurer Winston. Récupérez-le et déplacez-le vers logging point s ici. Maintenant, nous devons exporter cet enregistreur, donc le module point Exports Et nous voulons l'appeler Logger. Alors logger, nous l'avons défini sur Logger. Revenons maintenant à l'index point js. Je voudrais également déplacer cette instruction require pour gérer les erreurs asynchrones dans Express Je préfèrerais le mettre dans notre module de journalisation, qui traite de la gestion et de la journalisation des erreurs. Coupons-le à partir d'ici et collons-le dans le module logging dot js. Enfin, nous devons revenir à index point js et charger le module de journalisation. Require initialise la journalisation. Notez que je l'ai mis en premier. Donc, juste au cas où nous aurions une erreur lors du chargement d'autres modules, pour nous assurer de verrouiller cette erreur et de mettre fin au processus. Nous en avons donc terminé avec cette refactorisation en tant qu'exercice. Je veux que vous déplaciez tout le code pour gérer l'initialisation de la base de données vers un module séparé appelé dbdt Js Vous aurez ma solution lors de la prochaine conférence. 13. Extraire la logique de la base de données: Ici, dans index point JS, c' est le seul code dont nous disposons pour l' initialisation de la base de données Donc, ici, dans le dossier initialisé, ajoutons un nouveau fichier, dw point JS Et ici, nous allons exporter une fonction. Donc le module point Exports. Nous lui attribuons une fonction. Et puis déplacez tout le code d' initialisation de la base de données ici Maintenant, je vais apporter quelques modifications ici. Tout d'abord, lorsque nous nous connectons, je ne veux pas faire de consultation dans le journal. Je préfère enregistrer cela comme un message informatif en utilisant Winston Donc, en haut, chargeons notre enregistreur pour exiger la journalisation. Et nous devons déstructurer l'enregistreur, donc l'enregistreur Canst Cebrass. Alors pourquoi le restructurons-nous ? Si vous vous souvenez, dans le point de journalisation js, nous avons attribué l'objet logger en tant que propriété du module point exports Pour accéder à la propriété de l' enregistreur, vous devez donc la déstructurer Je l'ai fait exprès pour un petit rappel. Revenons maintenant à db dot js. Comme nous avons maintenant notre enregistreur, nous pouvons remplacer cette console qui enregistre par logger point info Nous devons également supprimer cette méthode de cache car si nous ne pouvons pas nous connecter à Mongo Di B, nous voulons enregistrer cette exception et terminer le processus Avec l'implémentation actuelle, nous gérons cette promesse rejetée ici même, et nous ne faisons qu' afficher ce message sur la console. Nous n'enregistrons donc pas cela. Nous n'allons pas mettre fin au processus. Je l'utilise ici spécifiquement à des fins de démonstration, mais avec la nouvelle implémentation, nous n'en avons pas besoin. Supprimons donc ceci et enfin, nous devons importer la mangouste par le haut Je vais le retirer du module indexé ou Js. Donc, de retour en indexé ou en Js en haut, je vais supprimer cette ligne pour importer mangouste, puis la mettre ici Voici donc notre module de base de données. Vous pouvez voir que le code est très clair, très court. Nous avons une seule responsabilité. Nous n'avons pas trop de choses mélangées. Enfin, nous devons charger ce module en index ou en Js. Donc ici, je vais appeler require initialize DV. Ici, nous obtenons une fonction, c' est pourquoi nous l'appelons. Vérifions-le maintenant avec notre implémentation actuelle. Si nous ne parvenons pas à nous connecter à la base de données lors de l' initialisation de l'application, cette exception sera enregistrée et le processus sera arrêté. Ouvrez donc un nouveau terminal. Je vais arrêter le processus Mongo DB avec le nom de service d' arrêt Mongo Et puis revenons à notre fenêtre de terminal, node, indexed ou Js. Voici donc notre rejet non géré Le processus est terminé. Et si vous regardez le journal à points des rejets, nous pouvons voir que le rejet est enregistré ici. Magnifique. C'est pourquoi je vous ai dit nous devrions supprimer la méthode de cache ici et laisser notre gestionnaire d'erreurs global gérer cette promesse rejetée Voici votre prochain exercice. Je veux que vous reveniez à index ou à Js et extrayiez tout le code pour gérer la configuration dans un module séparé. Je parle donc plus précisément de ces quelques lignes où nous recherchons les paramètres de configuration essentiels lors de l' initialisation de l'application Vous verrez ensuite ma solution. 14. Extraire la logique de configuration: C'est bon. Commençons par ajouter un nouveau fichier dans le dossier initialisé Donc, le point de configuration est. Encore une fois, nous exportons une fonction. Maintenant, de retour dans index ou Js, nous reprenons tout le code pour enregistrer les paramètres de configuration dans ce nouveau module. Nous avons donc ici une dépendance à ce module de configuration. Je vais donc l'obtenir à partir de index point js et le charger en haut de ce module. OK, donc si nous n'avons pas ce paramètre de configuration, nous ne voulons pas enregistrer quelque chose sur la console. Nous voulons plutôt enregistrer cela comme une erreur fatale dans notre journal. Ainsi, au lieu de faire une erreur par point dans la console et de sortir du point de traitement, il est préférable de lancer une exception, puis notre infrastructure actuelle détectera cette exception, l' enregistrera et terminera le processus. Nous lançons donc une nouvelle erreur et utilisons le message d'erreur. De plus, il est recommandé toujours lancer des objets d'erreur au lieu de chaînes, même si vous pouvez le faire en JavaScript. Parce que lorsque vous lancez un objet d'erreur, cette trace de pile sera disponible pour que vous puissiez la consulter ultérieurement. Si vous lancez une chaîne contenant le message d'erreur, vous n'aurez pas la trace de la pile. OK, c'est donc une autre bonne pratique à connaître. Enfin, revenons à index ou à Js et chargeons ce nouveau module. Exigez donc une initialisation, une configuration flash. C'est une fonction, c'est ainsi que nous l'appelons. Maintenant, testons-le. Avant cela, je dois démarrer le service Manga DV. Donc, de retour dans le terminal, lançons le nom du service de démarrage Manga DV OK, maintenant nous devons repartir à zéro. Fermez donc tous les terminaux, ouvrez un nouveau terminal comme celui-ci et exécutez nod index point JS. Bien, le processus est donc terminé, mais rien n'est enregistré sur la console. si vous regardez ce fichier, vous pouvez voir pourquoi notre application s'est écrasée. Erreur Patel, la clé secrète JWD n'est pas définie. C'est une bonne chose pour un environnement de production. Mais si vous donnez cette application à un nouveau développeur et qu'il l'exécute, il n'a aucune idée de ce qui se passe. Ainsi, dans notre implémentation actuelle, nous utilisons uniquement un transport de fichiers pour les exceptions non détectées Nous devrions donc également ajouter un transport de console pour afficher les exceptions non détectées sur la console Donc, nouvelle console de transport Winston Dot. Et c'est tout. Revenons au terminal et exécutons l'application une fois de plus. Vous pouvez voir que la raison pour laquelle notre application a échoué est que nous n'avons pas défini de clé privée JWT Maintenant, je veux te montrer quelque chose. Revenez donc à l'index dot js. Regardez le fichier JS à points d'index. Nous n'avons que 13 lignes de code ici. Tu te souviens de ce que nous avions avant ? Je pense que nous avions 30 à 40 lignes de code avec une très mauvaise séparation des préoccupations. Avec cette nouvelle refonte, nous ne faisons qu'une chose : configurer l'application Les détails de la journalisation, les détails des itinéraires, les détails de la base de données et d'autres aspects sont délégués à d'autres modules. Dans la pratique, il s'agit d'un principe de responsabilité unique. Bien qu'il soit encore possible de le refactoriser, nous pouvons déplacer cette configuration de joy et ce code ici, qui est chargé de gérer la configuration du serveur et de le démarrer Je vous le laisse donc en tant que mission de cette section.