Надійне надсилання SMTP-листів у Node.js

Під час схвалення кампанії, зміни балансу чи сповіщення про безпеку облікового запису запит у Node.js не має чекати на поштовий сервер. Якщо ретранслятор працює повільно, дія, яку виконує користувач, може завершитися тайм-аутом; якщо застосунок повторить запит, він може надіслати те саме повідомлення двічі. Надійніше для продуктивного середовища записувати сповіщення разом із бізнес-подією, а потім доручити фоновому процесу доставити його через SMTP.

Перенесіть надсилання листів за межі обробки запитів

Уявімо криптовалютну рекламну мережу, де кампанія переходить зі статусу «очікує» у статус «схвалена». Застосунок має швидко зафіксувати цю зміну статусу, а транзакційні та маркетингові повідомлення надіслати асинхронно. Він не повинен чекати на встановлення SMTP-з’єднання, перш ніж відповісти рекламодавцю.

Записуйте завдання на надсилання листа в таблицю бази даних або надійну чергу в межах тієї самої транзакції, що й зміну статусу. Фоновий процес зчитує завдання зі статусом очікування та надсилає листи через ретранслятор. Така черга email-повідомлень у Node.js відокремлює доступність застосунку від доставки пошти: тимчасовий збій ретранслятора може затримати сповіщення, але не скасує схвалення й не заблокує дію на панелі керування.

Якщо ви додаєте SMTP-ретранслятор для Node.js до наявного сервісу, зосередьтеся насамперед на межі між застосунком і фоновим процесом, а не на поштовій бібліотеці. Якщо ви з’ясовуєте, як налаштувати SMTP у Node.js, почніть із цієї межі та визначте, як застосунок створюватиме завдання для надсилання. Платформа Email & messaging може забезпечити SMTP-з’єднання для транзакційних повідомлень, але застосунок усе одно має визначати, коли створюється повідомлення, як працюють повторні спроби та що робити, якщо результат доставки невідомий.

Створюйте одне завдання сповіщення для кожної бізнес-події

Створюйте завдання під час фіксації відповідної події, а не щоразу, коли завантажується сторінка чи користувач повторно надсилає запит до API. Призначайте завданню стабільний ключ події, наприклад ідентифікатор кампанії разом із переходом між статусами та версією. Забезпечте унікальність цього ключа, щоб дубльовані запити не створювали кілька листів про схвалення, що очікують на надсилання.

Корисний запис завдання містить одержувача, ідентифікатор шаблону, мінімальний набір даних для формування повідомлення, кількість спроб, час наступної спроби та статус. Не зберігайте в ньому облікові дані SMTP чи зайві відомості про обліковий запис. Якщо адресу одержувача можна змінити до надсилання, заздалегідь визначте, яку адресу використовувати: зафіксовану на момент події чи поточну підтверджену адресу облікового запису. Чітко задокументуйте це правило.

Надсилайте лист лише тоді, коли він відповідає реальній зміні статусу. Фоновий процес не має робити висновок про схвалення на основі застарілих даних у черзі. Перед надсиланням важливого сповіщення він може перевірити поточну версію події або завантажити відповідний запис. Так клієнт не отримає повідомлення про схвалення кампанії, якщо її одразу після цього призупинили.

Налаштуйте SMTP-ретранслятор у фоновому процесі Node.js

Використовуйте підтримуваний SMTP-клієнт, наприклад Nodemailer, а дані для з’єднання зчитуйте зі змінних середовища фонового процесу, а не зберігайте у вихідному коді. У прикладі нижче використано типовий порт для надсилання пошти; налаштуйте порт і параметри TLS відповідно до даних, наданих для вашого облікового запису.

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

Як адресу відправника вкажіть адресу, дозволену для вашої конфігурації надсилання, і використовуйте окремі облікові дані для фонового процесу, а не логін адміністратора. Не записуйте в журнали повний текст повідомлення, пароль чи відповідь автентифікації. Перевірка під час запуску допоможе виявити неправильні налаштування, але не гарантує, що конкретний одержувач прийме пізніше надісланий лист.

Повторюйте спроби після тимчасових збоїв, не створюючи шквалу листів

Розрізняйте типи помилок, а не повторюйте всі спроби з однаковим інтервалом. Після тимчасового збою з’єднання або відповіді сервера про надмірне навантаження можна повторити спробу, поступово збільшуючи інтервали. Неправильні облікові дані, некоректні адреси одержувачів та інші стійкі помилки конфігурації чи адреси потрібно розслідувати, а не намагатися виправити частими повторами. Установіть максимальну кількість спроб, а завдання, для яких її вичерпано, переведіть у статус, доступний для перевірки оператором. Повторні спроби надсилання листів Nodemailer налаштовуйте з урахуванням цих обмежень і типу помилки.

Використовуйте оренду завдань або аналогічний механізм захоплення, щоб два процеси Node.js не надсилали одночасно те саме завдання з черги. Коли фоновий процес захоплює завдання, зафіксуйте час завершення оренди: якщо процес зупиниться, інший зможе забрати завдання після її завершення. Тривалість оренди має перевищувати звичайний тайм-аут надсилання; збільшуйте її, якщо формування чи доставка повідомлення можуть тривати довше.

SMTP не може гарантувати справжню доставку рівно один раз на рівні застосунку. Ретранслятор може прийняти повідомлення, але з’єднання може перерватися, перш ніж фоновий процес отримає підтвердження. Повторна спроба в такому разі може призвести до дубліката; якщо ж позначити повідомлення як надіслане до його прийняття, воно може загубитися. Використовуйте стабільні ключі подій, щоб не створювати дублікати завдань, обмежуйте кількість повторних спроб і враховуйте, що таку невизначеність не завжди можна усунути автоматично.

Розгортайте зміни поетапно й під контролем

Перш ніж перемикати продуктивний трафік, створіть тестові завдання в середовищі, відмінному від продуктивного, і перевірте, чи може фоновий процес пройти автентифікацію, сформувати очікуваний вміст і записати статуси успіху та помилки. Потім увімкніть фоновий процес для одного типу сповіщень із низьким ризиком. Порівнюйте кількість бізнес-подій, завдань у черзі та успішно надісланих листів: зростання черги може виявити проблему з фоновим процесом або конфігурацією ще до того, як ви перенесете критично важливі сповіщення.

• Під час розгортання використовуйте однакову схему повідомлень у вебзастосунку та фоновому процесі.
• Забезпечте ідемпотентне створення завдань, перш ніж запускати кілька екземплярів фонового процесу.
• Відстежуйте час очікування в черзі, кількість повторних спроб, постійні помилки та стан фонового процесу.
• Передбачте ручний спосіб повторного запуску перевірених завдань із помилками, а не надсилайте навмання всі невдалі повідомлення.

Коли фоновий процес запрацює стабільно, приберіть пряме надсилання через SMTP з обробників запитів, щоб усі ці повідомлення надсилалися одним контрольованим способом. Якщо ви використовуєте платформу Email & messaging як ретранслятор, вона забезпечує передавання через SMTP, а черга, правила для подій, політика повторних спроб і операційний контроль залишаються вашою відповідальністю. Такий розподіл обов’язків корисний, коли події облікового запису потрібно швидко зафіксувати навіть під час короткочасних перебоїв із поштою, але він не скасовує потреби в моніторингу та чітких правилах для затриманих сповіщень.