

Rails 4.0 Sneak Peek: Asynchronous ActionMailer - bcardarella
http://reefpoints.dockyard.com/ruby/2012/06/26/rails-4-sneak-peek-async-actionmailer.html

======
evdawg
I think this was the lowest-hanging fruit in Rails. Glad they've finally
addressed it in core. Years of people using job queues just to send mail is
finally over!

But, why doesn't this let me pass objects to Mailer methods? I can't help but
think passing ids and finding the object again on the other side is bad
design.

Myself, over the past few years, instead of a job queue, I have been using a
simple gem called spawn (<https://github.com/tra/spawn>) to fork processes to
asynchronously send mail from Rails. It lets me pass objects around... I hope
that this asynchronous ActionMailer gets this functionality as well!

~~~
mattgreenrocks
> I can't help but think passing ids and finding the object again on the other
> side is bad design.

It is good design. Why? Because you don't want to pass mutable state (read:
your user model) across thread/process boundaries if you can help it. What if
the mailer modifies it? What if the caller modifies it while the mailer is
working with it? It may no longer be valid. Rather than trying to reason about
all possible states it could be in, it's easier just to make the job bootstrap
itself with all the data it needs.

Confining instances to threads is far more sane than using mutexes and locks
or relying on your runtime's GIL to watch out for you.

~~~
nirvdrum
Since you're unlikely to be sharing memory with your background processor,
what you'd really be doing is marshaling the object on enqueue and
unmarshaling on decode. In that case, you're no more susceptible to further
modifications to the data than you would be with a DB lookup.

There of course may be other issues with marshaling. E.g., marshaling of procs
is particularly tricky. But I've been marshaling with sidekiq for the past
couple months and really haven't run into any problems. And it cleaned up the
code a fair bit because I basically treat it as an RPC without any of the
ceremonious DB lookups at the start of every async method.

