Out of the box async operations

[jwoertink]

I've had this idea for a bit now, but I wonder if it would be of any interest to others for having operations that could be ran asynchronous out-of-the-box....

We have this capability with Carbon's deliver_later_strategy. This allows you to decide if you just want to use spawn or if you want to use a background worker like Mosquito or Sidekiq.

My idea for Avram would be the same thing. There would be an Avram::AsyncOperationStrategy or something with the default being set to spawn. Then someone could make a separate Avram::AsyncOperation::MosquitoStrategy. I'm not totally sure how it would work for Save/DeleteOperation, but at least the regular ones could have run and run_later.

For example:

Avram.configure do |setting|
  setting.run_later_strategy = Avram::AsyncOperation::MosquitoStrategy
end

SendApplicationEvent.run_later(params) do |operation, value|
  # runs later
end

SendApplicationEvent.run(params) do |operation, value|
  # runs now
end

Does this sound like a good idea? Or doing too much and just let developers handle this when they want?

[robacarp]

In a past life we used a system similar to Operations, and it looked like this:

# contrived example is contrived
class BigDealContext < BaseContext
   inputs :user, :deal

   def perform
      user.make_a_deal deal
   end

   def later
     user.notify_dealio if deal.succeeded?
   end
end

And honestly I underestimated the power of that pattern when we built it so much. There are so many situations you can defer just a bit of logic out to the background and speed up your app. We were using sidekiq to run processes and we had one "later context runner" sidekiq job which handled sorting out the context and deserializing the parameters and other mumbojumbo. The ability to asynchronize a bit of code quickly, easily and offload it to some non-request-cycle portion of the app easily is a game changer.