✉️ Separate Email into an Independent Service #39
Labels
discuss
Share your constructive thoughts on how to make progress with this issue
enhancement
New feature or enhancement of existing functionality
epic
A feature idea that is large enough to require a sprint (5 days) or more and has smaller sub-issues.
T1d
Time Estimate 1 Day
technical
A technical issue that requires understanding of the code, infrastructure or dependencies
Context
As described in dwyl/app#267,
email
is very important to the success of our App.At present the Email section of the
README.md
https://github.com/dwyl/auth#email indicates thatauth
uses SES and Bamboo for sending email. It informs people that they need to have environment variables forSMTP_USERNAME
,SMTP_PASSWORD
,SES_SERVER
andSES_PORT
and links to dwyl/learn-phoenix-framework/sending-emails.md for more detail.This is good for a barebones MVP that just needs to show a PO/PM that "email works",
but it is not a long-term solution to for reliably sending email because:
The Problem 😕
a) We are sending
email
in a "fire and forget" manner expecting them to automagically reach their target recipient. But we all know there is a lot more toemail
deliverability than simply sending theemail
.How do we know it was actually delivered to the recipient?
b) We don't have any end-to-end tests for
email
so we have no way of knowing it's working other than to manually test sending an email to ourselves. Manual testing gets old fast.c) Assuming the
email
is successfully delivered we have no way of knowing if it was opened/read.We have no metrics for how effective our email is so we cannot be data-driven.
d) What happens when the
email
bounces or worse there is a complaint about our service? Our deliverability rating will plummet and along with it the fate of our App.e) We are forced to maintain
email
related code in theauth
App which is really not the "focus" of theauth
App. Email should be a single function invocation that delegates to a dedicated service.All of these issues lead us to believe that there is a much better way of doing
email
.Proposed Solution 💡
Instead of using
Bamboo
and writingElixir
code to sendemail
,we build a separate service that has only one job
email
. 💌Given that we are already using Amazon Simple Email Service (SES) for sending our
email
,why not make the
email
service aLambda
Function that we can invoke from any App or Programming Language?Advantages 🎉
email
Lambda function/service is much easier to test and maintain.that in turn allows people to create
email
templates in Handlebarswhich is arguably a simpler and more beginner-friendly templating language than EEx.
auth
can delegateemail
and focus on the one thing it needs to do; authenticate people.delivery
,bounce
&complaint
see: https://docs.aws.amazon.com/ses/latest/DeveloperGuide/notification-contents.html
All events/notifications will be fed back to the Auth App and the status of the
email
will be recordedso that the team can see the delivery, bounce, open and clickthrough rate metrics! 📈
email
system can more easily be used and improved upon by the community.Downside? 😞
The downside of having a separate project/function for
email
is that it's another thing to think about (and hold in your head) from the developer's perspective.I feel this is minor given that a developer is already invoking a Bamboo function,
the only difference will be we invoke a Lambda function with the same data.
Todo
dpl
📦Elixir
: Invoke AWS Lambda Function from Elixir aws-ses-lambda#8delivery
&bounce
Create SES topic for bounced emails aws-ses-lambda#1There is obviously a lot more we can do with
email
and that's part of the reason we want to split it out into it's own independent service. But this is all we need for theauth
service for now.This will allow us to get back to focussing on building our App. 📱
The text was updated successfully, but these errors were encountered: