My original reasoning for using SES is/was simple:
A dedicated purpose-built transactional email system that has bounce/failure detection.
Cheapest by far and with a generous "free tier" means we can send 62k emails / month for FREE before paying a penny ... see: https://aws.amazon.com/ses/pricing/
Fully customisable and usable from AWS Lambda, again "free tier".
These reasons are still technically valid. But they miss one important fact: setup complexity!!
We ended up needing a whole separate repo for this: https://github.com/dwyl/aws-ses-lambda
Which we considered reasonably well-documented/maintained ...
But doesn't have an AWS CloudFormation script to automate the setup ...
so it's still a manual process with several steps.
What if there was a dramatically simpler way of doing this?
What if when setting up the auth app for the first time, the admin person
was able to sign-in with their Google Account e.g. hello@app.io
and then the auth app stored a token to send emails on behalf of the admin using their Gmail?!
This would solve so many issues in one step!
Instead of having to waste time setting up all the enhanced verifications in a 3rd party email service,
Google handles the deliverability!!
Replies!!
If people receiving an email from our App want to reply they can, easily!
And that reply ends up in our collective inbox. Not in the AWS SES black hole.
This is totally fine during MVP, we definitely won't have more than 500 signups per day.
For reference, this is 15,000/month ... any bootstrapped startup would dream of this!!
But what happens on a day that our App is mentioned on HackerNews, ProductHunt, Reddit or YouTube...?
Well, we build a "waiting list" feature https://github.com/dwyl/app/issues/304 that would store all the details and send the emails as soon as resources were available.
It recently occurred to me while reading the
swoosh
Adapters docs: https://hexdocs.pm/swoosh/Swoosh.Adapters.Gmail.html#content 👀 That I'm over-thinking/complicating things by usingAWS SES
for sending emails ... 💭My original reasoning for using
SES
is/was simple:62k emails / month
for FREE before paying a penny ... see: https://aws.amazon.com/ses/pricing/AWS Lambda
, again "free tier".These reasons are still technically valid. But they miss one important fact: setup complexity!! We ended up needing a whole separate repo for this: https://github.com/dwyl/aws-ses-lambda Which we considered reasonably well-documented/maintained ... But doesn't have an
AWS CloudFormation
script to automate the setup ... so it's still a manual process with several steps.What
if
there was a dramatically simpler way of doing this? Whatif
when setting up theauth
app for the first time, theadmin
person was able to sign-in with theirGoogle
Account e.g.hello@app.io
and then theauth
app stored a token to send emails on behalf of theadmin
using theirGmail
?! This would solve so many issues in one step!Simplified Setup
Consider the list of environment variables on the current
/init
screen: https://authdemo.fly.dev/initADMIN_EMAIL
would be populated by this step so we would never see the error described in #270EMAIL_APP_URL
would no longer be needed, i.e. no longer a separate app! ref: https://github.com/dwyl/email/issues/77Enhanced Deliverability
Instead of having to waste time setting up all the enhanced verifications in a 3rd party email service, Google handles the deliverability!!
Replies!!
If people receiving an email from our
App
want to reply they can, easily! And that reply ends up in our collective inbox. Not in theAWS SES
black hole.Limitations?
Google has a daily sending limit of
500
emails.https://www.google.com/search?q=gmail+outbound+sending+limit+daily
This is totally fine during
MVP
, we definitely won't have more than500
signups per day. For reference, this is15,000/month
... any bootstrapped startup would dream of this!! But what happens on a day that ourApp
is mentioned onHackerNews
,ProductHunt
,Reddit
orYouTube
...? Well, we build a "waiting list" feature https://github.com/dwyl/app/issues/304 that would store all the details and send the emails as soon as resources were available.