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
swooshAdapters docs: https://hexdocs.pm/swoosh/Swoosh.Adapters.Gmail.html#content 👀 That I'm over-thinking/complicating things by usingAWS SESfor sending emails ... 💭My original reasoning for using
SESis/was simple:62k emails / monthfor 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 CloudFormationscript to automate the setup ... so it's still a manual process with several steps.What
ifthere was a dramatically simpler way of doing this? Whatifwhen setting up theauthapp for the first time, theadminperson was able to sign-in with theirGoogleAccount e.g.hello@app.ioand then theauthapp stored a token to send emails on behalf of theadminusing theirGmail?! This would solve so many issues in one step!Simplified Setup
Consider the list of environment variables on the current
/initscreen: https://authdemo.fly.dev/initADMIN_EMAILwould be populated by this step so we would never see the error described in #270EMAIL_APP_URLwould 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
Appwant to reply they can, easily! And that reply ends up in our collective inbox. Not in theAWS SESblack hole.Limitations?
Google has a daily sending limit of
500emails.https://www.google.com/search?q=gmail+outbound+sending+limit+daily
This is totally fine during
MVP, we definitely won't have more than500signups per day. For reference, this is15,000/month... any bootstrapped startup would dream of this!! But what happens on a day that ourAppis mentioned onHackerNews,ProductHunt,RedditorYouTube...? 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.