You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. [email protected]
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!
EMAIL_APP_URL would no longer be needed, i.e. no longer a separate app! ref: 2023 Rebuild? email#77
Enhanced 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 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 dwyl/app#304 that would store all the details and send the emails as soon as resources were available.
The text was updated successfully, but these errors were encountered:
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 using
AWS 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?What
if
when setting up theauth
app for the first time, theadmin
personwas able to sign-in with their
Google
Account e.g.[email protected]
and then the
auth
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 stepso we would never see the error described in Feat: Auth Setup Wizard
#discuss
#270EMAIL_APP_URL
would no longer be needed, i.e. no longer a separate app! ref: 2023 Rebuild? email#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 the
AWS 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 is
15,000/month
... any bootstrapped startup would dream of this!!But what happens on a day that our
App
is mentioned onHackerNews
,ProductHunt
,Reddit
orYouTube
...?Well, we build a "waiting list" feature dwyl/app#304 that would store all the details and send the emails as soon as resources were available.
The text was updated successfully, but these errors were encountered: