Локализованные тексты лучше хранить в отдельном i18n-модуле по назначению, а сервис отправки должен лишь выбирать и доставлять готовое сообщение.
нужно сообщение на разных языках сохранить в спец константе откуда мы можем это брать и вызывать для себя как покайф, где лучше хранить все эти переменные
Локализованные тексты лучше хранить в отдельном i18n-модуле по назначению, а сервис отправки должен лишь выбирать и доставлять готовое сообщение.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
нужно сообщение на разных языках сохранить в спец константе откуда мы можем это брать и вызывать для себя как покайф, где лучше хранить все эти переменные
Лучше не в utils/aws и не в user.schema.
Рекомендую: src/i18n/
src/i18n/ email-confirmation.ts ← константа + getEmail index.ts ← реэкспорт, чтобы имп
Почему так: • это копирайт/локали, не AWS и не модель юзера • можно потом кидать туда push/SMS/ошибки без путаницы • импорт простой: from '../i18n' или from '../i18n/email-confirmation'
Как юзать: • константу EMAIL_CONFIRMATION_MESSAGES — если нужен сырой словарь • функцию getEmailConfirmationMessage(lang, code) — если сразу готовый subject/text
AwsSesService просто импортирует оттуда — место
Ответ
Локализованные тексты лучше хранить в отдельном i18n-модуле по назначению, а сервис отправки должен лишь выбирать и доставлять готовое сообщение.
Например, src/i18n/email-confirmation.ts экспортирует словарь и функцию getEmailConfirmationMessage(lang, code). Задайте тип поддерживаемых языков и fallback, отделите шаблон от пользовательских значений. AWS-сервис и модель пользователя не должны становиться хранилищем всех текстов приложения.