6 ms·
interesting - not sure if it's really needed though - I've used Redis and Resque before and found it's performance was blisteringly fast. (Resque was made by Gi
by edbloom 14y ago
interesting - not sure if it's really needed though - I've used Redis and Resque before and found it's performance was blisteringly fast. (Resque was made by Github https://github.com/blog/542-introducing-resque https://github.com/blog/542-introducing-resque)
- bradly 14y agoIt isn't about speed or choice of queue, it's about a standerized API for working with queues so you can focus on developing your application domain. You will still be able to use Resque or Sidekiq or DJ or anything else, there will just be a standard API for all of them to use.
- Empact 14y agoAlso, it's an ecosystem feature. If a library or a component of rails (e.g. ActionMailer) wants to process something in a background queue, the choice doesn't have to be between a host of bad options: * Forcing a dependency on a particular queue * Writing a wrapper for all possible queues * Falling back to queue-less behavior in the absence of a detected queue They just use the Rails queue and it works on whatever real-world queue the user picks. Definitely good infrastructure IMO.
- ecoffey 14y agoI think the point is to provide an abstraction layer, so that the community has some common feature set and protocol expectations when we're discussing different technical solutions to queuing.