princemaple
Phoenix.Swoosh approaching 1.0
Hi all,
I’m close to making a 1.0 release for Phoenix.Swoosh.
With this release, Phoenix.Swoosh will work in any project in addition to Phoenix projects, thanks to the Phoenix.View extraction.
It’s a little awkward to ask for feedback right now, because at this moment the lib most likely has conflicts with current Phoenix apps (< 1.6), as the original Phoenix.View is still there.
However, I’d ask anyway. If you are interested, please take a look at the code changes and let me know what you think. Thanks!
Also, if you are thinking about starting a new project that isn’t a phoenix app, and need to send emails with some templates, it’s now the perfect time to test it.
Most Liked
princemaple
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!
princemaple
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.
princemaple
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.startis 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.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








