Wysyłka e-maili w tle w Node.js przez SMTP

Zatwierdzenie kampanii, zmiana salda czy alert dotyczący bezpieczeństwa konta nie powinny sprawiać, że żądanie w Node.js czeka na serwer pocztowy. Jeśli serwer przekaźnikowy działa wolno, żądanie obsługujące użytkownika może przekroczyć limit czasu. Jeśli aplikacja ponowi żądanie, może wysłać tę samą wiadomość dwukrotnie. Bezpieczniejszym rozwiązaniem produkcyjnym jest zapisanie powiadomienia razem ze zdarzeniem biznesowym, a następnie przekazanie go do wysłania przez SMTP w tle.

Przenieś wysyłkę e-maili poza ścieżkę obsługi żądania

W przypadku sieci reklamowej związanej z kryptowalutami rozważ kampanię, której status zmienia się z oczekującej na zatwierdzoną. Aplikacja powinna szybko zatwierdzić tę zmianę. Nie powinna czekać na nawiązanie połączenia SMTP, zanim zwróci reklamodawcy odpowiedź.

Zapisz zadanie wysłania e-maila w tabeli bazy danych lub trwałej kolejce w ramach tej samej transakcji co zmiana statusu, także dla wiadomości określanych jako „транзакційні та маркетингові повідомлення”. Proces roboczy pobiera oczekujące zadania i wysyła wiadomości przez serwer przekaźnikowy. Dzięki temu dostępność aplikacji nie zależy od dostarczania e-maili: tymczasowa awaria serwera może opóźnić powiadomienie, ale nie cofnie zatwierdzenia ani nie zablokuje działania panelu.

Jeśli zastanawiasz się, jak wysyłać e-maile przez SMTP w Node.js w istniejącej usłudze, potraktuj granicę między aplikacją a procesem roboczym jako kluczową decyzję projektową, a nie wybór biblioteki pocztowej. Platforma Email & messaging może zapewnić połączenie SMTP do wysyłania wiadomości transakcyjnych, ale to aplikacja nadal musi decydować, kiedy utworzyć wiadomość, jak ponawiać próby i co zrobić, gdy nie ma pewności, czy została dostarczona.

Utwórz jedno zadanie powiadomienia dla każdego zdarzenia biznesowego

Utwórz zadanie w chwili zatwierdzenia zdarzenia, zamiast generować je przy każdym wczytaniu strony lub ponowieniu żądania API przez użytkownika. Nadaj zadaniu stabilny klucz zdarzenia, na przykład złożony z identyfikatora kampanii, zmiany statusu i wersji. Wymuś unikalność tego klucza, aby zduplikowane żądania nie tworzyły wielu oczekujących e-maili z informacją o zatwierdzeniu.

Przydatny rekord zadania zawiera odbiorcę, identyfikator szablonu, minimum danych potrzebnych do wygenerowania wiadomości, licznik prób, termin kolejnej próby i status. Nie zapisuj w nim danych logowania SMTP ani niepotrzebnych informacji o koncie. Jeśli adres odbiorcy może się zmienić przed wysłaniem, zdecyduj, czy zadanie ma używać adresu zapisanego w chwili zdarzenia, czy aktualnego, zweryfikowanego adresu konta. Jasno określ tę zasadę. Trwała kolejka e-maili w Node.js ułatwia przechowywanie tych zadań i obsługę ich przez procesy robocze.

Powiąż wygenerowaną wiadomość z rzeczywistą zmianą statusu. Proces roboczy nie powinien wnioskować o zatwierdzeniu na podstawie nieaktualnych danych z kolejki. Przed wysłaniem ważnego alertu może sprawdzić aktualną wersję zdarzenia lub pobrać odpowiedni rekord. Dzięki temu klient nie otrzyma informacji, że kampania została zatwierdzona, jeśli chwilę później ją wstrzymano.

Skonfiguruj przekaźnik SMTP w procesie roboczym Node.js

Użyj utrzymywanego klienta SMTP, takiego jak Nodemailer, i pobieraj dane połączenia ze zmiennych środowiskowych procesu roboczego zamiast umieszczać je w kodzie źródłowym. Poniższy przykład korzysta z typowego portu do wysyłania wiadomości. Dostosuj port i ustawienia TLS do danych logowania przekazanych dla Twojego konta.

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
  });
}

Ustaw nadawcę na adres zatwierdzony w używanej konfiguracji wysyłki i użyj osobnych danych logowania dla procesu roboczego, zamiast ponownie wykorzystywać dane administratora. Nie zapisuj w logach pełnej treści wiadomości, hasła ani odpowiedzi uwierzytelniającej. Weryfikacja przy uruchomieniu może wykryć nieprawidłowe ustawienia, ale nie gwarantuje, że konkretny odbiorca zaakceptuje późniejszą wiadomość.

Ponawiaj próby po tymczasowych błędach, nie powodując lawiny e-maili

Klasyfikuj błędy zamiast ponawiać każdą próbę w tym samym tempie. Tymczasowy problem z połączeniem lub odpowiedź serwera informująca o przeciążeniu usługi mogą uzasadniać ponowienie z coraz dłuższymi przerwami. Nieprawidłowe dane logowania, błędne adresy odbiorców i inne trwałe błędy konfiguracji lub adresu wymagają wyjaśnienia, a nie częstych ponowień. Ustal maksymalną liczbę prób i przenoś zadania, które ją wyczerpały, do statusu umożliwiającego ich sprawdzenie przez operatora. Ponawianie wysyłki e-maili SMTP powinno więc uwzględniać rodzaj błędu, limit prób i rosnące odstępy między kolejnymi wysyłkami.

Użyj dzierżawy zadania lub równoważnego mechanizmu przejmowania zadań, aby dwa procesy Node.js nie wysłały jednocześnie tego samego oczekującego zadania. Gdy proces roboczy przejmuje zadanie, zapisz czas wygaśnięcia dzierżawy. Jeśli proces ulegnie awarii, inny może przejąć zadanie po wygaśnięciu dzierżawy. Ustaw jej czas na dłuższy niż typowy limit czasu wysyłki i przedłuż ją, jeśli generowanie lub dostarczenie wiadomości może potrwać dłużej.

SMTP nie zapewnia aplikacji prawdziwej gwarancji dostarczenia dokładnie raz. Serwer przekaźnikowy może przyjąć wiadomość, a połączenie może zostać przerwane, zanim proces roboczy otrzyma potwierdzenie. Ponowienie próby może wtedy spowodować duplikat, a oznaczenie wiadomości jako wysłanej przed jej przyjęciem może doprowadzić do jej utraty. Używaj stabilnych kluczy zdarzeń, aby zapobiegać tworzeniu zduplikowanych zadań, ogranicz liczbę ponowień i zaakceptuj, że tego wąskiego przypadku niepewności nie zawsze da się rozstrzygnąć automatycznie.

Wdrażaj zmiany etapami i pod kontrolą

Zanim przełączysz ruch produkcyjny, wyślij testowe zadania ze środowiska nieprodukcyjnego i sprawdź, czy proces roboczy potrafi się uwierzytelnić, wygenerować oczekiwaną treść oraz zapisać informacje o powodzeniu i błędach. Następnie włącz proces dla jednego rodzaju powiadomień o niskim poziomie ryzyka. Porównuj liczbę zdarzeń biznesowych, zadań w kolejce i zakończonych wysyłek. Narastające zaległości mogą ujawnić problem z procesem roboczym lub konfiguracją, zanim obejmiesz zmianą krytyczne alerty.

• Podczas wdrażania utrzymuj ten sam schemat wiadomości w aplikacji internetowej i procesie roboczym.
• Zapewnij idempotentne tworzenie zadań, zanim uruchomisz wiele instancji procesów roboczych.
• Monitoruj wiek zadań w kolejce, liczbę ponowień, trwałe błędy i stan procesów roboczych.
• Zapewnij ręczną ścieżkę ponownego przetwarzania sprawdzonych błędów, zamiast bezrefleksyjnie ponawiać wszystkie nieudane zadania.

Gdy proces roboczy działa stabilnie, usuń bezpośrednią wysyłkę SMTP z obsługi żądań, aby wiadomości były wysyłane jedną kontrolowaną ścieżką. Jeśli jako serwera przekaźnikowego używasz platformy Email & messaging, platforma obsługuje przekazanie wiadomości przez SMTP. Kolejka, reguły zdarzeń, zasady ponawiania i kontrola operacyjna pozostają jednak po Twojej stronie. Takie rozdzielenie przydaje się, gdy zdarzenia dotyczące konta trzeba szybko zapisywać nawet podczas krótkich przerw w działaniu poczty, ale nie zastępuje monitorowania ani jasnych zasad dotyczących opóźnionych powiadomień.