A camada de framework acima do backend

O curso de nível Pleno "Solid Queue: arquitetura de jobs", anterior nesta série, examinou as tabelas em que o estado de um job é guardado e reservado. Todas essas tabelas pertencem ao Solid Queue, um backend. Os jobs desta aplicação não são escritos para o Solid Queue, e sim para o ActiveJob::Base, uma camada de framework que fica acima do backend que estiver rodando por baixo.

Um job desta aplicação, inteiro

O app/jobs/ tem várias classes de job. Só a integração com parceiros tem quatro: buscar o ícone do site de um parceiro, anunciar um certificado, entregar um webhook e limpar nonces de handoff vencidos. Este é o menor deles, inteiro:

module Partners
  class FetchSiteIconJob < ApplicationJob
    queue_as :default

    def perform(partner_id)
      partner = ::Partners::Partner.find_by(id: partner_id)
      ::Partners::FetchSiteIconService.call(partner: partner) if partner && !partner.logo.attached?
    end
  end
end

O ApplicationJob herda de ActiveJob::Base, e nenhuma das duas classes menciona o Solid Queue, as tabelas dele ou FOR UPDATE SKIP LOCKED. queue_as e perform são vocabulário do ActiveJob, e funcionam do mesmo jeito seja o backend o Solid Queue, o Sidekiq ou um pool de threads no próprio processo.

A mesma chamada, comportamento diferente por ambiente

A aplicação define o queue_adapter por ambiente em config/environments/*.rb:

# development.rb
config.active_job.queue_adapter = :async

# test.rb / production.rb
config.active_job.queue_adapter = :solid_queue

::Partners::FetchSiteIconJob.perform_later(partner.id), chamado pelo Admin::Partners::SavePartnerService quando um parceiro ainda não tem logo, é uma linha de código. Em desenvolvimento, o :async o roda num pool de threads dentro do processo: sem tabela, sem persistência, e um restart do servidor perde o que ainda estiver na fila. Em teste e produção, o :solid_queue grava uma linha durável em solid_queue_jobs, e um worker a reserva depois. Mesma chamada, mesma classe de job, dois mecanismos diferentes, decididos pelo ambiente e não por algo dentro do FetchSiteIconJob.

Do que trata este curso

Cada aula a seguir examina uma coisa que o ActiveJob::Base oferece: serialização de argumentos, retry_on e discard_on, limits_concurrency, queue_as e callbacks. Cada uma é conferida contra os jobs desta aplicação, a configuração dela e as tabelas do Solid Queue por baixo. O curso não repete os detalhes internos de "Solid Queue: arquitetura de jobs"; esta é a camada acima deles.

Pontos-chave

• O FetchSiteIconJob é escrito todo em vocabulário do ActiveJob; nada nele cita o Solid Queue, as tabelas dele ou o jeito como reserva trabalho.
• A aplicação define o queue_adapter por ambiente: :async em desenvolvimento, :solid_queue em teste e produção.
• A mesma chamada perform_later roda num pool de threads sem persistência em desenvolvimento, e nas tabelas duráveis do Solid Queue em teste e produção.
• Este curso trata da camada de framework que o ActiveJob::Base oferece acima de qualquer backend, apoiado em "Solid Queue: arquitetura de jobs" sem repeti-lo.