
Si vous êtes comme moi, bon nombre de vos projets de passe-temps et exemples de portefeuille sont mis en œuvre à Heroku. Comme Github Pages, il est intéressant d’héberger votre projet car il est gratuit. Contrairement aux pages Github, il peut héberger un serveur dans Heroku. Je l'utilise donc chaque fois que j'ai besoin d'un emplacement libre pour implémenter une application à pile complète.
Il existe, bien sûr, un piège: votre dyno gratuit Heroku (instance de machine virtuelle) fera une sieste chaque fois que vous avez passé 30 minutes ou plus sans recevoir de trafic Web.
Un utilisateur essayant de charger une application avec un dynamomètre en veille subira un temps d'attente pouvant aller jusqu'à dix secondes, ce qui est un temps suffisant pour permettre à de nombreux utilisateurs de conclure que leur application est en panne et de continuer. Ceci est particulièrement vrai dans les cas où Heroku utilise pour afficher son travail, tel qu'un projet de portefeuille.
Une solution facile pour Nodejs
Heureusement, il est très facile de garder votre banc d'essai éveillé avec seulement quelques lignes de code. J'ai utilisé Nodejs, parce que c'est la langue dans laquelle mon backend est écrit. Dans un souci de réutilisation, j'ai créé un petit module, même si une simple fonction suffit.
J'ai utilisé la commande
setTimeout [19659008] de Node pour envoyer une requête HTTP à mon application à intervalles réguliers de moins de trente minutes, empêchant ainsi le banc d'essai de dormir. Pourquoi ne pas utiliser setInterval
à la place? Il se répète automatiquement et serait un peu plus concis, après tout. Cela pourrait certainement être le cas, mais j'ai vu des récits selon lesquels setInterval
peut être problématique . Bien qu'il soit certainement peu probable que mon cas d'utilisation rencontre ce type de problème, il est également apparu que la gestion des erreurs était plus facile avec setTimeout, comme vous le verrez.
J'ai appelé ma petite fonction utilitaire
wakeUpDyno
et utilisé une déclaration modules.export
pour la déclarer comme exportation par défaut du module. J'avais juste besoin d'installer une dépendance: node-fetch
bien que toute bibliothèque de noeuds faisant des requêtes HTTP fonctionne. La fonction a deux paramètres,
url
- adresse dyno (chaîne) - e intervalle
- durée, en minutes, que notre fonction attendra entre vos requêtes HTTP. (un entier) setTimeout
est appelé de l'intérieur wakeUpDyno
en passant à la fois une fonction de rappel anonyme et le temps d'attente en millisecondes entre les appels (temps en minutes - intervalle - multiplié par 60 000 ms / min). Ensuite, pour réactiver le banc d'essai, j'ai inséré la requête HTTP dans la fonction de rappel et l'a invoquée avec l'argument
url
. const fetch = requiert ( "node-fetch" );
const wakeUpDyno = ( url, intervalle ) => {>
const millisecondes = intervalle * 60000 ;
setTimeout ( () => {
recherche (url);
}, millisecondes);
};
module .exports = wakeUpDyno;
Cela permet de réveiller un dynamomètre endormi, mais contrairement à
setInterval
setTimeout
ne sera exécuté qu'une seule fois. Ensuite, elle a dû faire appeler à nouveau la fonction après avoir terminé sa demande fetch
. Je me suis dit que si un appel de reprise échouait, l'exécution de la fonction n'atteindrait jamais mon appel récursif et le programme se terminerait avec une erreur. J'ai donc décidé d'intégrer la demande de récupération
à l'intérieur d'un bloc try ... catch
suivi d'un bloc ... enfin
qui contient l'appel récursif. De cette manière, la fonction se rappellera, que l'appel précédent fetch
échoue ou non. const HTTP = require ( "HTTP" );
const wakeUpDyno = ( url, intervalle ) => {>
setTimeout ( () => {
preuve {
HTTP.get (url, () => {
console .log ( `Effectuer une requête HTTP vers $ {url} ... ')
});
}
capture (err) {
console .log ( `Erreur lors de l'extraction de $ {url} ` );
}
enfin {
wakeUpDyno (url, intervalle);
}
}, intervalle);
};
module .exports = wakeUpDyno;
À cette époque, mon utilitaire était fonctionnel, mais je voulais également ajouter un paramètre facultatif
callback
et attribuer également au paramètre [19659007] intervalle une valeur par défaut de 25 minutes. En cas d'échec, j'ai imbriqué l'invocation de
callback
dans un autre essai ... capture ... enfin [19659008] situé dans le bloc d'origine ... enfin
. J'ai déplacé l'appel récursif dans wakeDyno
vers le deuxième bloc le plus imbriqué ... enfin
pour exécuter quel que soit le succès du rappel
.
Donc, mon code final ressemble à ceci:
const fetch = require ( "node-fetch" );
const wakeUpDyno = ( url, interval = 25 callback ) => {
const millisecondes = intervalle * 60000 ;
setTimeout ( () => {
preuve {
console .log ( `setTimeout appelé.» );
// Demande HTTP GET à l'URL du banc d'essai
search (url) .then ( () => console .log ( `Getting $ {url} .` ));
}
capture (err) { // capture des erreurs de récupération
console .log ( `Erreur lors de la récupération $ {url} : $ {err.message}
Je réessayerai dans $ {intervalle} minutes ... `);
}
enfin {
preuve {
rappeler (); // exécute le rappel s'il est passé
}
capture (e) { // erreur de rappel
rappeler? console .log ( "Erreur de rappel:" message électronique): null ;
}
enfin {
// refait tout cela
return wakeUpDyno (url, intervalle, rappel);
}
}
}, millisecondes);
};
module .exports = wakeUpDyno;
Pour l'utiliser,
je l'exigerai
dans mon projet et l'invoquerai au démarrage de mon serveur Express, comme suit: const express = requiert ( ] "express" );
const wakeUpDyno = requiert ( "wokeDyno.js" ); // mon module!
const PORT = 3000 ; // le port de votre choix
const DYNO_URL = "https://howimadeathing.herokuapp.com" ; // url de votre dynamomètre
const app = express (); // instanciez l'application Express
app.listen (PORT, () => {
wakeUpDyno (DYNO_URL); // démarrera une fois le serveur démarré
})
Et c'est tout! Une fois que je l'ai chargé sur Heroku, cela a fonctionné exactement comme prévu et mon application n'a pas dormi depuis!
Petit avertissement pour ce projet: Heroku permet aux utilisateurs de disposer d'un nombre limité d'heures de dynamomètre gratuites par mois. Si plusieurs applications exécutent cet utilitaire, vous pouvez en manquer! Pour cette raison, lors d'une prochaine itération de ce module, j'ai l'intention d'autoriser la programmation de manière à ce que les heures dynamiques puissent être rationnées plus efficacement.
Veuillez, me contacter avec des commentaires ou des corrections. Vous pouvez accéder au référentiel Github pour ce projet, ici .
[ad_2]