TL;DR: Name your class after it’s arguments, and the queue by the class name.
Naming Active Jobs and Queues is tricky, it’s pretty easy to get yourself into a pickle of queue names that are vague & classes that are unclear.
Recently I was looking through the Rails Active Storage documentation, I noticed they had given the class
ActiveStorage::AnalysisJob the queue
active_storage_analysis. Looking a bit deeper I noticed they had followed this pattern in the other Active Storage job classes, and Action Mailbox Active Job classes.
I really liked this pattern, and started applying it to my rails projects. Here are the two strategies which led to much cleaner code.
Naming the Active Job class
app/jobs folder and seeing an unorganized mess is a little intimidating. I started using the first argument (most often a Active Record model), then what it’s doing as the second aspect of the name.
For example, if you have a job that took the User model and enriched the data you had on it, you’d end up with something like:
# In app/jobs/user/enrichment_job.rb class User::EnrichmentJob < ApplicationJob queue_as :user def perform(user) # Do some magic. end end
Naming the queues
It’s pretty tempting to dump everything into the
default queue, but that can become problematic when quick running jobs get stuck waiting for a slower job to finish.
I use the approach of naming my queues based on the class name, using each namespace as a level of Granularity. For example:
# In app/jobs/user/enrichment_job.rb class User::EnrichmentJob < ApplicationJob # Group them by the folder name queue_as :user # Be more specific if I want to run it in a dedicated worker. # queue_as :user_enrichment end