Email-processor
Overview
The Email Processor is a separate application withing the precomposer developed in Nest.js and operates as a central hub for managing email communications within the platform. It functions based on a reactive, event-driven architecture. The application subscribes to commercetools events, enabling it to respond in real-time to various activities. For instance, when a new order is created, commercetools triggers an alert to our application, initiating the process of sending the appropriate message.
Email Templates
Initial creation
Upon the application's startup, a check is performed to verify the availability of templates on the configured SendGrid account. If none of the required templates are found, it creates new ones based on predefined generic templates located within the project structure. Subsequently, upon successful creation on SendGrid, a reference ID for every template is stored in a local (cluster) MongoDB database.
A mechanism regularly (every ten minutes) verifies existence of the needed templates on SendGrid against the stored references. If a template is missing (perhaps deleted accidentally or intentionally by a SendGrid user), its corresponding reference is also removed from the MongoDB. In such cases, restarting the application triggers the recreation of templates from the base templates in the project structure.
Manual updates
The initially created templates can be modified and updated by adding new versions through the SendGrid UI or API. As the ID and the template (instance) remain constant while the active version changes, the user can freely change the content.
Sending emails
The process of sending emails involves two phases.
-
The first phase encompasses the preparation of the template, which includes
- determining the subject of the message,
- locating the reference to the SendGrid template, downloading the template from SendGrid,
- and then dynamically inserting data into the template in place of placeholders using handlebars syntax.
-
The second phase is the actual dispatching of the email. In this stage, the rendered content from the first step is used to create the email, ready to be sent out to the given recipients. This two-step approach ensures that each email is both accurately tailored to the specific context and efficiently dispatched, maintaining the seamless flow of communication on the platform. Also, if needed, it is easy to change the template platform and the email sending platform independently.
Architecture
The Email processor has the following structure (see also diagramm below):
Main modules
Email-sender module - This module is dedicated to sending emails via a designated service provider, currently employing SendGrid for this purpose.
SendGrid-template-handler module - This module facilitates interaction with SendGrid, managing the synchronization of templates between our internal database and SendGrid's service. It also retrieves the currently active template from SendGrid for use.
Webhook module - Processes messages from the commercetools extension and initiates the templating and sending process. Essentially, this is the entry point of the application.
Template render module - Responsible for the dynamic rendering of email templates, this module adeptly populates templates with specific, context-relevant data using handlebars.
Helper modules
Bootstrap-template-initializer module - This module is responsible for triggering the storage of predefined templates during the app startup, if missing from database.
Healthcheck module - This module provides an essential endpoint to monitor the application’s operational status.
Shared module - This shared resource includes a logging service and a configuration service, both of which are integral and accessible across all modules.
Template-storage module - Responsible for storing references to the templates saved on SendGrid using the mentioned MongoDB.