A supervisor will restart supervised processes that crash, which could be caused by any number of things, like a hard drive failure, a temporary network outage, memory corruption, etc. If a process is not supervised, it just means in the case where that happens, nothing will be tracking it to start a new process in its place, so whatever that process was going to do will not occur.
softrage
dimitarvp
Yeah, that’s my reason as well. I don’t think users are interested in a random popup 30 seconds after they made an action on the website that says “sorry, we were unable to send you an email”. This is one of the things that’s expected to always eventually succeed, even if it’s one hour later. So yeah, definitely spawn a process to send the email – or delegate it to a background task library.
2
derek-zhou
GCP is that slow? In my Elixir application (hosted on a cheap VPS on hostwind) sending a short email sync vs async via swoosh/sendgrid only have a diff of about 10 ms, from the point of view of access log. Sending through a exim server on localhost is actually somewhat slower; gen_smtp is known for its adherence to the spec, not for speed, and that clocks in about 15ms.
0
dimitarvp
A lot of mail providers don’t guarantee quick responses, in my historical experience. It is not deemed as something you should put on a hot code path / user-visible delay in the UI.
0
derek-zhou
If I care about the result, being slow occasionally is still better than the silent failures.
If I don’t care that much, like for an one way 3rd party api call that is nice to have but ok to fail, I will just use phoenix pubsub to broadcast to a background genserver and do the remote call there. It is async, but still not spawning on the spot.
0
dimitarvp
I am not sure what we’re arguing about, network problems happen all the time, cloud providers have downtime all the time. 
If we go with Oban then you’d get configurable retries for free. If we use our own supervised Tasks then we can just use a recursive function with a retries argument that can have a cap – it’s practically almost the same.
In both ways error handling is mostly a luxury. Obviously if there’s a hard requirement that the users must be notified of a failure to deliver email to them (within e.g. 5 minutes), then that’s a whole different story. But I haven’t had such requirements ever (although I am sure they do exist).
0
derek-zhou
Of course. My point is, if it is something I depend on, I’d like it to fail flat on my face if it ever fails.
Case in the point: A few year ago, I have a system that often failed to deliver emails that contained the one time code for login purpose. (It was mis-configuration of some sort) I was grilled for it badly.
To recap, there are 3 ways to send emails:
- just send it in process
- spawn and send
- throw it out to a background job with pubsub, or oban if I want scalability or persistence across reboot.
1 has the easier error handling and is often fast enough. 3 has the latency and throughput advantage, 2 has none.
0