Phoenix.Swoosh approaching 1.0

Great work!

How does this compare to Bamboo? Is Swoosh a drop-in replacement for Bamboo? What can one library do that the other can’t?

They are very similar. One is almost a drop in replacement for the other.

I don’t like some of the ideas in bamboo, but I won’t discuss them here as it’s not the topic of the thread. Also I’m heavily biased for obvious reasons

If anyone else would like to chime in about the questions, they are more than welcome to. They would be a lot more objective than I am.

Back when I compared both libraries (about 2 years ago), one of the main reasons I picked Bamboo was it had a deliver_later function built into the library. At the time this felt nice because it was convenient to call that instead of wrapping all of your emails in Task.start or some async solution which is what Swoosh suggests to do.

If you’re coming to Elixir from Ruby or Python you might already have things engrained into your brain like “yes, I want to send all emails in a background task” and Bamboo made that easier out of the box.

But if your project happens to be using Oban already then it’s not a huge amount of extra effort to send mails through that instead of an adhoc Elixir task, which makes both Bamboo and Swoosh pretty even in this regard.

With Phoenix officially including Swoosh now, the decision to use Swoosh is much easier. It’s what I would use in an app being developed today.

Swoosh doesn’t really suggest “Task.start”. It’s just an example. GitHub - swoosh/swoosh: Compose, deliver and test your emails easily in Elixir · GitHub

My belief is that, much like authentication, async job and job queue (more specifically, error handling and retry strategy) are app specific and should be considered thoroughly and made to fit the business logic. And I believe that the job queueing code should be the one that drives the email sending code, not the other way around. Bamboo being too much like rails is one of the reasons I don’t love it. Just like Phoenix is not your application, Swoosh is not your application, or your async driver.

Oban is great. Task.start is also great. Even sync email delivery in request handling process is good enough sometimes. Which one to use is really a matter about what you want to happen when things fail.

Imagine someone who is fairly new to Elixir and hasn’t fully understood the inner workings of the Task module or supervisors and many other things that folks even with a year of Elixir experience might not have touched.

The Swoosh docs puts:

# To send asynchronous emails in Swoosh, one can simply leverage Elixir's standard library:

Task.start(fn ->
  %{name: "Tony Stark", email: "tony.stark@example.com"}
  |> Sample.UserEmail.welcome()
  |> Sample.Mailer.deliver()
end)

It’s directly saying to use this example. Sure it links to the docs for Task and mentions how it’s not really a good idea for mission critical applications but at the same time it doesn’t say what to do when you want these things, but neither of things are approachable to someone new to Elixir.

I very much remember reading this as a newcomer to Elixir and being put off by this because I wasn’t sure why a library would recommend doing something that’s considered questionable, especially since I was using robust queueing libraries for 5+ years in Ruby and Python beforehand.

Whether or not Bamboo’s deliver_later is better than Task.start isn’t even taken into account here. It’s the message sent from the docs to the user’s brain. Bamboo’s docs didn’t leave me thinking its deliver_later isn’t adequate in a real application.

Exactly. Swoosh’s default of sending emails in process is saner for the smaller sites. I have a SMTP server on the same host and it can queue/resend emails.

The whole point was to lead the reader to explore more about how to handle async tasks properly in Elixir, and build what’s most suitable for themselves.

Please take a look at the official docs for Task and Task.Supervisor for further options.

Note: it is not to say that Task.start is enough to cover the whole async aspect of sending emails. It is more to say that the implementation of sending emails is very application specific. For example, the simple example above might be sufficient for some small applications but not so much for more mission critical applications. Runtime errors, network errors and errors from the service provider all need to be considered and handled, maybe differently as well. Whether to retry, how many times you want to retry, what to do when everything fails, these questions all have different answers in different context.

The “it depends” tone is intentional.

I guess the takeaway is, we didn’t suggest a good generic safe catch-all solution. I’ll mention job queue and Oban in the docs. So if one doesn’t know what they want, they can fallback to the safest way.

EDIT: I’ve updated the docs.

Thanks for creating this library. I’ve integrated it recently and it was very nice - everything is well thought out and the documentation is great.

One thing I found myself wanting is a way to combine the Logger and Local adapters. I ended up doing it by having a function that debug-logs the email body always before sending the email, and configuring the app to use the Local adapter in dev, which worked well enough, for others who may want the same.

Thank you for changing the docs!

@princemaple - One surprise when I was checking out the 1.6-dev branch of phoenix is, it uses only swoosh - not phoenix.swoosh. Any specific reason, for this half-way integration?