diff options
| author | David Heinemeier Hansson <david@loudthinking.com> | 2014-05-19 13:13:30 +0200 |
|---|---|---|
| committer | David Heinemeier Hansson <david@loudthinking.com> | 2014-05-19 13:13:30 +0200 |
| commit | c69dda49880df94c7243e9dc5fcf43a223769f43 (patch) | |
| tree | b31f56603305f26c279b788c718b1eb8fca206d9 | |
| parent | afb3d4f9e5820cb8f5cd4502e1d0525044ac6ef2 (diff) | |
| download | rails-c69dda49880df94c7243e9dc5fcf43a223769f43.tar.gz rails-c69dda49880df94c7243e9dc5fcf43a223769f43.tar.bz2 rails-c69dda49880df94c7243e9dc5fcf43a223769f43.zip | |
Add justification
| -rw-r--r-- | README.md | 7 |
1 files changed, 7 insertions, 0 deletions
@@ -10,6 +10,13 @@ that makes it easy to turn any mailing into a job for running later. That's one of the most common jobs in a modern web application: Sending emails outside of the request-response cycle, so the user doesn't have to wait on it. +The main point is to ensure that all Rails apps will have a job infrastructure +in place, even if it's in the form of an "immediate runner". We can then have +framework features and other gems build on top of that, without having to worry +about API differences between Delayed Job and Resque. Picking your queuing +backend becomes more of an operational concern, then. And you'll be able to +switch between them without having to rewrite your jobs. + ## Usage |