Email templates: local vs AWS

[jpmckinney]

On one hand, storing templates in SES would allow us to change templates without redeploying the app. We would only need to redeploy the app if a template added a new substitution (in which case we would increment the version number in the template name, to avoid storing a template that is incompatible with the deployed app). SES also errors if not all tags are replaced (we had some uncaught typos in afa1aee).

On the other hand, needing to upload templates to S3 when testing templates in development is annoying. Uploading templates is also overhead, for which we have no automation. Notably, we currently have a SES layout + local template pattern. If everything were on SES, we'd need each template to be a full HTML document. (Any other reasons to prefer local templates?)

---

We could get the advantages of SES by:

1. Keeping layouts and partials separate locally.
2. Having a build script that combines the layout with the partials, and uploads them. (No tags will be filled in, in this case.)
3. The templates would follow a filename pattern (ideally matching the MessageType enum – and ideally the mail functions would also match this enum) starting with the environment and ending with a version number, like prod.message-type.es.v123.html.

In terms of SES actions, the build script would:

1. Call ListTemplates.
2. Determine the maximum version of each template whose name matches a local template.
3. Call GetTemplate on each latest version.
4. Compare whether the content is different than the local version. If not, skip that template.
5. Compare the tags in each version.
6. If the tags are the same, replace the template. If the tags are different, upload a newer version.
7. If the local template has no remote version, it is uploaded as v1.

For development, the templates would be written to dev.type.es.v123.html, etc.

Anyway, just an idea, no urgency to develop this.

[jpmckinney]

Noting that images are currently stored in credere-frontend. As noted at https://credere.readthedocs.io/en/latest/aws/cloudfront.html, these image files should not be changed (and if they are, CloudFront needs to be invalidated) and should not be removed (because then old emails will fail to retrieve the image, unless the email was sent after we setup CloudFront and the image is still in the CloudFront cache).

To ease cognitive load, we should probably also establish a naming scheme for images, e.g. message-type.es.v123.png if the image is directly relevant to that message type, or name.es.v123.png if it's generic. The version numbers are necessary for the reasons stated above.