Envoyer des e-mails en arrière-plan avec Node.js et SMTP

Une approbation de campagne, une modification de solde ou une alerte de sécurité du compte ne devrait pas obliger une requête Node.js à attendre qu’un serveur de messagerie réponde. Si le relais est lent, l’action côté utilisateur peut expirer ; si l’application relance la requête, elle risque d’envoyer le même message deux fois. Pour envoyer des e-mails en arrière-plan avec Node.js de façon plus sûre en production, enregistrez la notification en même temps que l’événement métier, puis laissez un processus d’arrière-plan l’envoyer via SMTP.

Sortez l’envoi des e-mails du chemin de la requête

Pour un réseau publicitaire crypto, prenons l’exemple d’une campagne qui passe du statut « en attente » au statut « approuvée ». L’application devrait enregistrer rapidement ce changement d’état et envoyer les транзакційні та маркетингові повідомлення sans attendre qu’une connexion SMTP aboutisse pour répondre à l’annonceur.

Enregistrez une tâche d’envoi d’e-mail dans une table de base de données ou une file d’attente durable pour e-mails transactionnels, dans le cadre de la même transaction que le changement d’état. Un processus d’arrière-plan récupère les tâches en attente et les envoie via le relais. Cela dissocie la disponibilité de l’application de la livraison des e-mails : une panne temporaire du relais peut retarder la notification sans annuler une approbation ni bloquer une action dans le tableau de bord.

Si vous ajoutez un relais SMTP avec Node.js à un service existant, considérez la séparation avec le processus d’arrière-plan comme le principal choix de conception, plutôt que la bibliothèque de messagerie. La plateforme de messagerie peut fournir la connexion SMTP pour les messages transactionnels, mais votre application doit toujours déterminer quand créer un message, comment gérer les tentatives et que faire lorsque la livraison est incertaine.

Associez une seule tâche de notification à chaque événement métier

Créez la tâche lorsque l’événement sous-jacent est enregistré, plutôt que de la générer à chaque chargement de page ou à chaque nouvelle tentative d’une requête API. Attribuez-lui une clé d’événement stable, par exemple l’identifiant de la campagne associé à la transition d’état et à sa version. Imposez l’unicité de cette clé afin que des requêtes en double ne créent pas plusieurs e-mails d’approbation en attente.

Une tâche utile contient le destinataire, l’identifiant d’un modèle, les données minimales nécessaires à la génération du message, un compteur de tentatives, une date de prochaine tentative et un statut. Évitez d’y stocker des identifiants SMTP ou des informations de compte superflues. Si l’adresse du destinataire peut changer avant l’envoi, déterminez si la tâche doit utiliser l’adresse enregistrée au moment de l’événement ou l’adresse actuellement vérifiée du compte, et définissez clairement cette règle.

Faites en sorte que l’e-mail généré corresponde à un changement d’état réel. Le processus d’arrière-plan ne doit pas déduire qu’une campagne est approuvée à partir de données obsolètes dans la file d’attente. Avant d’envoyer une alerte sensible, il peut vérifier la version actuelle de l’événement ou charger l’enregistrement concerné. Vous éviterez ainsi d’annoncer à un client que sa campagne a été approuvée si elle a été mise en pause juste après.

Configurez le relais Node.js dans le processus d’arrière-plan

Pour configurer SMTP avec Nodemailer, utilisez un client maintenu et récupérez les paramètres de connexion dans l’environnement du processus d’arrière-plan plutôt que de les enregistrer dans le code source. L’exemple ci-dessous utilise le port d’envoi courant ; adaptez le port et les paramètres TLS aux identifiants fournis pour votre compte.

const nodemailer = require("nodemailer");

const port = Number(process.env.SMTP_PORT || 587);

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port,
  secure: port === 465,
  requireTLS: port !== 465,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  }
});

async function sendCampaignNotice(message) {
  return transporter.sendMail({
    from: process.env.MAIL_FROM,
    to: message.to,
    subject: message.subject,
    text: message.text,
    html: message.html
  });
}

Définissez l’expéditeur sur une adresse autorisée pour votre configuration d’envoi et utilisez des identifiants distincts pour le processus d’arrière-plan au lieu de réutiliser ceux d’un compte administrateur. N’affichez jamais dans les journaux le message complet, le mot de passe ou la réponse d’authentification. Une vérification au démarrage peut détecter des paramètres invalides, mais elle ne garantit pas qu’un destinataire donné acceptera un message envoyé ultérieurement.

Relancez les échecs temporaires sans provoquer une avalanche d’e-mails

Classez les erreurs au lieu de relancer toutes les tentatives au même rythme. Une erreur de connexion temporaire ou une réponse du serveur indiquant que le service est occupé peut justifier de nouvelles tentatives avec des délais croissants. Des identifiants invalides, des adresses de destinataire mal formées et d’autres problèmes persistants de configuration ou d’adresse nécessitent une vérification, pas des tentatives rapprochées. Fixez un nombre maximal de tentatives et placez les tâches ayant atteint cette limite dans un état que les opérateurs pourront examiner.

Utilisez un bail de traitement, ou un mécanisme équivalent, afin que deux processus Node.js ne puissent pas envoyer simultanément la même tâche en attente. Lorsqu’un processus prend en charge une tâche, enregistrez l’expiration du bail ; s’il s’arrête, un autre processus pourra reprendre la tâche à l’expiration du bail. Prévoyez une durée de bail supérieure au délai d’expiration habituel de l’envoi et prolongez-la si la génération ou la livraison du message risque de prendre plus de temps.

SMTP ne peut pas garantir une livraison exactement une fois dans votre application. Le relais peut accepter un message alors que la connexion échoue avant que votre processus reçoive la confirmation. Une nouvelle tentative peut alors produire un doublon ; marquer le message comme envoyé avant son acceptation risque au contraire de le perdre. Utilisez des clés d’événement stables pour empêcher la création de tâches en double, limitez le nombre de tentatives et acceptez que cette situation d’incertitude particulière ne puisse pas toujours être résolue automatiquement.

Déployez le changement par étapes contrôlées

Avant de basculer le trafic de production, envoyez des tâches de test depuis un environnement hors production et vérifiez que le processus peut s’authentifier, générer le contenu attendu et enregistrer les états de réussite et d’échec. Activez ensuite le processus pour un type de notification peu risqué. Comparez le nombre d’événements métier, de tâches mises en file d’attente et d’envois terminés ; une file qui s’allonge peut révéler un problème de processus ou de configuration avant que vous ne déplaciez des alertes critiques.

• Pendant le déploiement, conservez le même schéma de message pour l’application web et le processus d’arrière-plan.
• Rendez la création des tâches idempotente avant de lancer plusieurs instances du processus.
• Surveillez l’ancienneté des tâches dans la file, le nombre de tentatives, les échecs définitifs et l’état du processus.
• Prévoyez une procédure de relance manuelle pour les échecs examinés, au lieu de renvoyer aveuglément toutes les tâches en échec.

Une fois le processus stabilisé, supprimez les envois SMTP directs des gestionnaires de requêtes afin de centraliser l’envoi de ces messages. Si vous utilisez la plateforme de messagerie comme relais, elle prend en charge l’envoi SMTP ; la file d’attente, les règles liées aux événements, la politique de nouvelles tentatives et le suivi opérationnel restent de votre responsabilité. Cette répartition est utile lorsque les événements de compte doivent être enregistrés rapidement, même en cas de brèves interruptions de la messagerie, mais elle ne dispense ni de la surveillance ni de définir clairement la gestion des notifications retardées.