Setting Up Background Jobs with Solid Queue in Property Web Builder: A Complete Guide

Property Web Builder uses Solid Queue as its production-grade background-job engine, requiring only the gem installation, a database migration, and setting config.active_job.queue_adapter = :solid_queue in production to begin processing jobs via the standard Rails Active Job API.

Property Web Builder leverages Solid Queue to handle intensive background processing like video generation and email delivery without external dependencies such as Redis. By integrating this database-backed job adapter (version ~> 1.0), the application gains reliable, production-ready concurrency using PostgreSQL for persistence and scheduling. This guide covers the complete setup process according to the etewiah/property_web_builder source code.

Core Architecture and Installation

Gem Dependency

Solid Queue is declared in the Gemfile at line 242, pinning the dependency to version 1.0:

# Gemfile (line 242)

gem "solid_queue", "~> 1.0"

Running bundle install adds the Active Job adapter and necessary binaries to the project.

Database Schema Setup

After installing the gem, the migration 20251209180729_create_solid_queue_tables.rb creates the full schema Solid Queue requires for operation. This includes tables for solid_queue_jobs, solid_queue_processes, solid_queue_executions, pauses, semaphores, and recurring tasks. These tables handle persistence, deduplication, scheduling, and concurrency control without external data stores.

Configuration Files

Production Environment Adapter

In config/environments/production.rb at line 65, Rails is instructed to route all ActiveJob calls through Solid Queue:

# config/environments/production.rb (line 65)

config.active_job.queue_adapter = :solid_queue

Development and test environments retain the default async adapter, ensuring background jobs only run via Solid Queue in production.

Worker and Dispatcher Settings

The config/solid_queue.yml file defines runtime behavior for dispatchers and workers per environment. Dispatchers poll the database for ready jobs using configurable polling_interval and batch_size values. Workers fetch jobs from specific queues (configured via queues: "*" or named arrays) and execute them in thread pools sized by the threads parameter.

The production configuration defines dedicated queues for high-priority email, notifications, default work, and low-priority batch jobs, each with tuned thread counts and polling intervals. Solid Queue monitors worker health via the solid_queue_processes table; heartbeats enable automatic recovery of stalled jobs.

Creating and Enqueuing Jobs

Defining Job Classes

Jobs subclass ApplicationJob and specify their target queue using queue_as. In app/jobs/generate_listing_video_job.rb, the implementation looks like this:

# app/jobs/generate_listing_video_job.rb

class GenerateListingVideoJob < ApplicationJob
  queue_as :default   # optional; matches a worker's `queues` entry

  def perform(video_id:, website_id:)
    # Heavy-weight video generation logic…

  end
end

Enqueueing with perform_later

Any service object or controller can enqueue work using perform_later. The call is persisted to solid_queue_jobs and picked up by a dispatcher:

# Anywhere in the application (e.g., a service object)

GenerateListingVideoJob.perform_later(
  video_id:   video.id,
  website_id: website.id
)

For high-priority mailers, assign a specific queue that matches a dedicated worker in solid_queue.yml:

class MailerJob < ApplicationJob
  queue_as :mailers   # matches the high-priority mailers worker

  def perform(user_id)
    # send email…

  end
end

MailerJob.perform_later(user.id)

Scheduling Future Jobs

Solid Queue supports delayed execution via the Active Job set API, creating a row in solid_queue_scheduled_executions:

RefreshPropertiesViewJob.set(wait: 5.minutes).perform_later(website_id: 42)

The dispatcher monitors scheduled_at timestamps and moves jobs to the ready queue when the wait period expires.

Summary

• Solid Queue provides database-backed background processing in Property Web Builder via the standard Rails Active Job interface.
• Installation requires the gem in Gemfile (line 242), running the migration 20251209180729_create_solid_queue_tables.rb, and setting config.active_job.queue_adapter = :solid_queue in config/environments/production.rb (line 65).
• Runtime behavior is controlled through config/solid_queue.yml, which defines dispatcher polling intervals, batch sizes, and worker thread pools for specific queues.
• Jobs are defined by subclassing ApplicationJob and using queue_as, then enqueued with perform_later or scheduled with set(wait: ...).

Frequently Asked Questions

What database tables does Solid Queue create in Property Web Builder?

According to the migration 20251209180729_create_solid_queue_tables.rb, Solid Queue creates tables including solid_queue_jobs (for job records), solid_queue_processes (for worker heartbeats), solid_queue_executions (for tracking attempts), and solid_queue_scheduled_executions (for delayed jobs). These tables manage persistence, concurrency, and recovery without requiring Redis.

How do I configure separate worker pools for different job priorities?

Edit config/solid_queue.yml to define multiple worker blocks, each specifying a queues array (e.g., [mailers] or [default]) and a threads count. The production configuration separates high-priority mailers from low-priority batch work by assigning distinct workers to specific queues with appropriate thread pool sizes.

Can I schedule a job to run at a specific time instead of immediately?

Yes. Use the standard Active Job API: YourJob.set(wait: 10.minutes).perform_later(args). Solid Queue stores this in solid_queue_scheduled_executions and automatically promotes it to the ready queue when the scheduled_at timestamp is reached, as implemented in the Property Web Builder source.

Why does Property Web Builder use Solid Queue only in production?

The adapter is explicitly set to :solid_queue only in config/environments/production.rb (line 65). Development and test environments use the default async adapter to avoid database overhead and simplify debugging, ensuring background jobs run instantly during local development without the Solid Queue polling infrastructure.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}