5 ms·

> 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 mutab

> 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.

deleted 14y ago
[deleted]
- dasil003 14y ago
  If all your reasons for not using Rails have as little to do with Rails as this, well, you might not want to do any programming at all.
  - deleted 14y ago
    [deleted]
  - moe 14y ago
    He does touch a valid concern though. I know people have largely moved to using remote services to send their mail. However, if you're about to introduce a queue only for that then a local MTA seems a more sensible choice. A minimal postfix satellite config is 12 lines - not rocket science and robust as a brick.
    - nirvdrum 14y ago
      I currently us a combo because some of our emails are reports that take a bit to compile. So, the async method makes sense there. But every one of our nodes has a local postfix config and transport up to SendGrid. I trust Postfix will do a better job dealing with temporary outages than I will in Ruby. I'd imagine this is great for those on PaaS where they can't just install local software like an MTA, too.
- mattgreenrocks 14y ago
  What? You don't have to modify it to send a query. I was discussing a way of structuring your code such that the scenario I described simply cannot happen. Preventing such silliness ahead of time is what robust engineering is all about.
nirvdrum 14y ago
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.

deleted 14y ago

[deleted]

dasil003 14y ago
If all your reasons for not using Rails have as little to do with Rails as this, well, you might not want to do any programming at all.
- deleted 14y ago
  [deleted]
- moe 14y ago
  He does touch a valid concern though. I know people have largely moved to using remote services to send their mail. However, if you're about to introduce a queue only for that then a local MTA seems a more sensible choice. A minimal postfix satellite config is 12 lines - not rocket science and robust as a brick.
  - nirvdrum 14y ago
    I currently us a combo because some of our emails are reports that take a bit to compile. So, the async method makes sense there. But every one of our nodes has a local postfix config and transport up to SendGrid. I trust Postfix will do a better job dealing with temporary outages than I will in Ruby. I'd imagine this is great for those on PaaS where they can't just install local software like an MTA, too.
mattgreenrocks 14y ago
What? You don't have to modify it to send a query. I was discussing a way of structuring your code such that the scenario I described simply cannot happen. Preventing such silliness ahead of time is what robust engineering is all about.

nirvdrum 14y ago

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.