Email Deliverability Backend Tool
Email Deliverability Backend Tool
The polling mechanism functions by routinely checking each associated inbox to verify if the email containing a specific test code has arrived. This process is handled by the `pollOnce` function in `src/services/poller.js`, which checks each inbox using respective client services (`gmailClient` for Gmail and `outlookClient` for Outlook) for the code. If found, it updates the inbox's received status and associated metadata. Completion is determined when all inboxes confirm receipt, transitioning the test status to 'completed', calculating a deliverability score, and sending a report to the user. Failure to complete within the defined timeout period results in a 'failed' status .
The system's scalability is achieved through its use of modular and microservice-based scripts. The backend employs a model-controller architecture, using Express.js for routing, Mongoose for database models, and separate services for polling and email sending, which effectively compartmentalizes logic and tasks. Additionally, `setInterval` function in `poller.js` ensures that polling is non-blocking, allowing multiple tests to proceed simultaneously without halting the system's responsiveness. Environment configurations, such as multiple refresh tokens and separate routes for inboxes and tests, permit handling increased loads as usage scales .
The backend system incorporates several error handling mechanisms. For instance, during test creation in `src/routes/tests.js`, missing user email data returns a 400 error. The server encounters errors saving a test, logging 'Create test error' and responding with a 500 status. Similar handling exists for starting tests and retrieving test data, providing 404 errors for not found instances and logging specific error messages, e.g., 'Start test error' . In the polling mechanism, errors in message checking are logged at the `checkInboxForCode` function, suggesting robustness in tracking and managing issues across different parts of the system operations .
Nodemailer is utilized in the backend system to send emails as part of the email deliverability tests. Specifically, the `emailSender` module uses Nodemailer to set up an SMTP transport using credentials, allowing the service to send email reports upon the completion of tests. Nodemon, on the other hand, is a development dependency that facilitates development by automatically restarting the node application when file changes are detected, thus increasing developer efficiency and providing immediate feedback .
The backend service initializes an email deliverability test by creating a test entry in the database with a unique test code and user email. This is managed by the endpoint described in the `src/routes/tests.js` file, where the test creation includes setting up predefined inboxes and saving the test with a 'pending' status. Polling for email deliverability involves continuously checking the associated inboxes to determine whether the email with the test code has arrived. The polling process, described in `src/services/poller.js`, starts asynchronously; if polling is successful and all emails are confirmed received (reflected in the 'Inbox' folder), the test status is marked as 'completed', and an email report is generated and sent to the user. If the test times out without retrieving all emails, the status changes to 'failed' .
The backend service uses environment variables to handle sensitive API credentials and tokens securely. In `package.json`, relevant credentials like API keys and client secrets are stored in a `.env.example` file. These environment variables are loaded into the application through the `dotenv` package, preventing sensitive data from being hard-coded in the source files. This practice reduces the risk of exposing credentials in version control systems and ensures they are kept out of reach from unauthorized access .
The essential environmental settings include `PORT`, `BASE_URL`, `MONGODB_URI`, API keys and client secrets for Gmail and Outlook (`GMAIL_CLIENT_ID`, `OUTLOOK_CLIENT_ID`, etc.), SMTP configuration details (e.g., `SMTP_HOST`, `SMTP_USER`, `SMTP_PASS`), `FROM_EMAIL`, and polling intervals (`POLL_INTERVAL_MS`, `POLL_TIMEOUT_MS`). These local configurations, outlined in `.env.example`, are significant as they guide the server's listening port, define necessary database and email client connections, and streamline email operations while managing test execution timing effectively .
The backend system adopts a clear versioning strategy, defined by specific version numbers or caret (^) indicating compatibility with versions not below but possibly above the specified number, e.g., `