Vanilla Rails Jobs

Jobs are thin wrappers (3-5 lines). ALL business logic lives in models.

The Pattern

# Model concern - WHERE THE LOGIC LIVES
module Card::ClosureNotifications
  extend ActiveSupport::Concern

  included do
    after_update :notify_watchers_later, if: :just_closed?
  end

  # _later: Enqueues the job
  def notify_watchers_later
    Card::ClosureNotificationJob.perform_later(self)
  end

  # _now: Contains ALL business logic
  def notify_watchers_now
    watchers.each do |watcher|
      CardMailer.closure_notification(watcher, self).deliver_now
      Notification.create!(user: watcher, card: self, action: 'closed')
    end
  end

  private
    def just_closed?
      saved_change_to_status? && closed?
    end
end

# Job - ONLY delegates (3 lines)
class Card::ClosureNotificationJob < ApplicationJob
  def perform(card)
    card.notify_watchers_now
  end
end

Why Jobs Stay Thin

Testability: Test _now synchronously (no job infrastructure needed) Reusability: Call _now in console, tests, anywhere Debuggability: Stack traces point to model, not job framework

Naming Convention

Flow: Callback → _later → enqueue job → job calls _now → logic executes

Red Flags - STOP and Fix

If you see ANY of these, you're doing it wrong:

• Job longer than 5 lines (except ActiveJob config like retry_on)
• Business logic in job (queries, conditionals, loops)
• Job creates/updates records
• Job sends emails directly
• Job calls multiple models directly
• No _later/_now naming
• Passing IDs to job instead of objects
• Logic split between job and model
• Job has error handling beyond retry_on/discard_on
• Model missing _now method ("I don't need it")

ALL of these mean: Move logic to model. Job should only delegate.

Common Mistakes

Examples: Wrong vs Right

❌ WRONG: Fat job with business logic

class Card::ClosureNotificationJob < ApplicationJob
  def perform(card_id, closer_id)
    card = Card.find(card_id)
    card.watchers.each do |watcher|
      CardMailer.closure_notification(watcher, card).deliver_now
      Notification.create!(user: watcher, card: card, action: 'closed')
    end
    card.update!(last_notification_sent_at: Time.current)
  end
end

Problems: 12 lines of logic, re-queries by ID, hard to test, not reusable, no _later/_now

✅ RIGHT: Thin job delegates to model

# Job (3 lines)
class Card::ClosureNotificationJob < ApplicationJob
  def perform(card)
    card.notify_watchers_now
  end
end

# Model (where logic belongs)
def notify_watchers_later
  Card::ClosureNotificationJob.perform_later(self)
end

def notify_watchers_now
  watchers.each do |watcher|
    CardMailer.closure_notification(watcher, self).deliver_now
    Notification.create!(user: watcher, card: self, action: 'closed')
  end
  update_column(:last_notification_sent_at, Time.current)
end

Benefits: Job is 3 lines, testable without jobs, reusable in console

Common Rationalizations (All Wrong)

Edge Cases

Multi-Model: Primary model orchestrates

class User::DigestJob < ApplicationJob
  def perform(user); user.send_digest_now; end
end

def send_digest_now
  cards = boards.flat_map { |b| b.cards.mine(self) }
  DigestMailer.send(self, cards).deliver_now
end

Utility/Cleanup: Use class methods

class Session::CleanupJob < ApplicationJob
  def perform; Session.cleanup_expired_now; end
end

def self.cleanup_expired_now
  where("created_at < ?", 30.days.ago).delete_all
end

Error Handling: ActiveJob retries + model errors

class Card::SyncJob < ApplicationJob
  retry_on ExternalAPI::Error, wait: 5.minutes
  def perform(card); card.sync_to_external_system_now; end
end

def sync_to_external_system_now
  ExternalAPI.update_task(external_id, attributes)
rescue ExternalAPI::Error => e
  errors.add(:base, "Sync failed: #{e.message}")
  raise
end

When You're About to Violate This

STOP if you're thinking:

• "I'll put the logic in the job because it's async work"
• "This job needs to query/update records"
• "The model would get too big"
• "It's clearer to have everything in one place"
• "I don't need the _later/_now pattern for this simple case"
• "This spans multiple models, no natural home"
• "This is a utility job, no model exists"
• "Error handling belongs in jobs"
• "I don't need _now because I won't call it directly"

ALL of these mean: You're about to write a fat job. Stop. Put logic in model.

Quick Check

Good job checklist:

• 3-5 lines total
• Only calls one model method
• Receives model instance (not ID)
• No queries, conditionals, or loops
• Model has _later method
• Model has _now method with logic (ALWAYS, even if only async path)

If ANY checkbox fails, refactor: move logic to model.