Hi @cvkmohan I am not involved in integrating Swoosh into Phoenix. It was a surprise to me as well (that swoosh is entering Phoenix eco system, not that not using Phoenix.Swoosh)
I suppose it’s easy enough to swap swoosh for phoenix_swoosh. And, not everyone uses phoenix_html, which phoenix_swoosh depends on.
Looks good. The extra context about using a dedicated job queue helps a lot.
I’ve added a PR to fix a few minor typos btw Fix a few typos in the docs by nickjj · Pull Request #617 · swoosh/swoosh · GitHub.
FYI José added more reasoning in Build upon async emails section by josevalim · Pull Request #620 · swoosh/swoosh · GitHub
Personally I don’t agree with his latest stance and I think it sets you up for a poor user experience if you follow it. It’s coming at it from the POV of server performance when it’s really both a human and server problem – both are important and I would go as far as saying the human problem is even more important to solve.
For #1, you can’t control how fast or slow another service will respond. Waiting 3 seconds for a response with a busy mouse cursor is a really bad user experience and that’s the user experience you’re going to get if you follow the new docs and run into a situation where your email provider doesn’t respond immediately for reasons you can’t control. Even waiting a few hundred milliseconds is going to be noticeable.
For #2, even with Rails or any Python web framework you can fare pretty well if you run a few processes of your app (web servers in all major frameworks will handle this for you). Even if you were reckless enough to send emails in the request / response cycle, as long as you did it sparingly and you weren’t running at massive scale your server would likely be fine.
I would still never do it tho because I want to be in control for when my web server responds and sending the email in the background is how you get that control.
By the way, with the new docs it reads kind of weirdly now because the new paragraph under the Task example tries very hard to talk the reader out of sending emails asynchronously but then the very next paragraph says if you have a mission critical app and you want to ensure your email gets delivered you should use Oban or Exq.
It basically says “by the way, sending emails in the background is a bad idea because you can’t show anything to the user if it fails but also by the way if you care about sending emails you should send it in the background using something other than the example we just covered”.
It conflicts itself, especially since sending email is almost always very important. That and you could absolutely show error messages to the user while sending emails in the background, it would just need to be done asynchronously. There’s lots of ways to do that.
I think someone who reads this while having this knowledge will gain less trust in your docs because it says a downside of sending emails in the background is you can’t report errors to a user, but you can.
My 2¢
If UI/UX is a problem, it should be solved at the UI/UX level. I always have separated frontend, my request is already async. I’m not super familiar with LV, but I believe there should be ways around bad UX.
RoR and Python (when not using Event loop architecture), on an average server, can work with 10s, maybe 100s concurrent requests. In Elixir, it starts with 1000s.
There are two parts. 1. when async is not necessary, you can do it in sync fashion and can also handle error in sync. 2. If you do do it in async, AND it’s mission critical, you should use a job queue. Maybe the docs can use some further touch up.
See the above section. It can be important AND not async.
This refers to the Task module implementation. With job queues you sure can. Even with Task module, with some dirty tricks you can also report error, though not reliably. Either way there is extra effort required. While in sync fashion, it’s super easy and straightforward.
What people really often miss is, you can do it in sync in Elixir (given it already has a parallel model, like requests), and it can take you pretty far.
If it is a service outage you better show the user for what it is and not hiding it. If your service provider is this bad every once in a while then maybe you should find another.
For small sites the only config making sense is either to use a well known transactional email provider near you or to run your SMTP server on the same host, or at least in the same data center. Either way it is very fast and sending async does not buy you anything. As a library, Swoosh should make the easy things easy, and the hard things possible.
It’s all out of our control. Things happen even to reputable services. DigitalOcean had a few minutes of downtime the other week in NYC3. S3 has gone down in the past, etc. I’m sure certain transactional email providers have have disrupted service once in a while.
A quick search on SendGrid’s status page shows they had mail delays in April 2021 SendGrid Status - Incident History and again in March 2021.
That’s why I think it’s worth it to design your system to be fault tolerant against these things and an easy win there is to send all emails in the background, preferably with a solution that knows how to do intelligent re-trying such as Oban. It gives you the highest chance of success that your email will be delivered and it ensures users get a fast page response since you control the request / response cycle.
Phoenix 1.6.0 is finally out with an RC version. I’ve released phoenix_swoosh 1.0.0-rc.0.
It works with Phoenix 1.6+. And, works with non-phoenix apps!
Hello @princemaple, thanks for your work. ^^
Please I have a question about phoenix_swoosh.
I’m upgrading an old Phoenix project from 1.5 to 1.6 and I want to switch from bamboo_smtp to swoosh_smtp.
With bamboo it was possible to send html emails that fallback in plain text emails when the html is not supported for some reason or another. In other words, I have two templates for all my emails, one with html body and the other with just text body.
Please, with phoenix_swoosh should I be concerned by my emails failing to be sent due to html content, and if yes, is there a working around in such situation ?
You can do the same with swoosh.
An example firezone/apps/fz_http/test/fz_http/mailer_test.exs at 4b67809c9bfc87d54001332904a179e8be804c4a · firezone/firezone · GitHub
And corresponding HTML & text templates firezone/apps/fz_http/test/fz_http/mailer_test/sample_email at 4b67809c9bfc87d54001332904a179e8be804c4a · firezone/firezone · GitHub
It uses Phoenix.View so it does the same thing as Phoenix. Using an atom means rendering all possible formats.