Is your feature request related to a problem? Please describe.
Currently, the templates that are used to send e-mails, are being stored in AWS as part of their SES templates feature, and we use the AWS api to create, update, delete and list templates.
The code for the CRUD operations reside in the storage/templates
package, we'll want to move that to the upper layer. Our API endpoints for the templates
resource should remain roughly the same, except maybe the List
operation, we should adapt it to be the same as the rest of the paginated resources.
The templates that are created, are being used as part of the campaign operation. When we create a campaign we associate a template, to be rendered as an e-mail message when we send it to each subscriber. Templates are used as a way to send personalized e-mail to the customers, the subject and body can contain unique values that are personalized for each recipient.
Describe the solution you'd like
Let's start with the storage. A template consists of:
Text and html parts are the actual body, we can have an html template or send just a plain text message. Here are some example values:
{
"name": "MyTemplate",
"subject": "Greetings, {{.name}}!",
"html": "<h1>Hello {{.name}},</h1><p>Your favorite animal is {{.favoriteanimal}}.</p>",
"text": "Dear {{.name}},\r\nYour favorite animal is {{.favoriteanimal}}."
}
The html and text part must be a valid golang template i.e. parsable by the text/template
package.
The table should look something like this:
Name |
Type |
Nullable |
id |
bigint unsigned primary key |
false |
name |
varchar(191) |
false |
subject |
varchar(191) |
false |
text_part |
text |
true |
The HTML part will be stored on s3 instead of the database since it's more suiting that way. We'll figure out the name of the bucket and folder later on. In case the user wants to send only a text email, not a fancy HTML one, we can skip that part.
Next up is the storage interface and implementation. Currently, this resides in the storage/templates
, we should refactor this into our existing Storage interface, and re-implement all CRUD operations with the new store methods. We should also include tests since we don't have them because currently, it is a simple AWS API wrapper.
The final step, and probably the hardest one, is to refactor the send operation to use the templates from our end instead of the SendTemplatedEmail
and SendBulkTemplatedEmail
APIs.