Duas filosofias, um job: Redis ou o banco de dados

Uma fila precisa morar em algum lugar

Um job em segundo plano é uma promessa de fazer algo depois: mandar um email, buscar uma imagem, recalcular uma estatística. Entre o "faça isso depois" do seu código e a hora em que um worker roda o job, essa promessa precisa ficar guardada. O lugar tem de ser durável o bastante para sobreviver a um deploy, uma queda ou um restart. Duas respostas testadas em produção dominam o ecossistema Ruby, e elas discordam sobre onde deve ser esse lugar.

O Sidekiq é a gem que a maioria dos devs Rails imagina quando alguém fala em "jobs em background". Ele guarda a promessa no Redis, um armazenamento chave-valor em memória com que o app conversa pela rede. O Solid Queue, o padrão do Rails 8, guarda no banco relacional (PostgreSQL, neste app) que os seus models já leem e escrevem a cada requisição. O mesmo job, dois lugares para guardar a promessa enquanto ela espera.

Este app roda só o Solid Queue. grep -i sidekiq Gemfile Gemfile.lock não devolve nada, e um grep por redis no Gemfile, no lockfile e em todo arquivo YAML de config/ também volta vazio. Não há conexão com Redis em lugar nenhum deste código para apontar o Sidekiq, mesmo que a gem fosse adicionada amanhã. O curso anterior "Solid Queue: jobs em background" já seguiu um job pelas tabelas do Solid Queue deste app, pelo config/queue.yml e pela conexão da fila. Nada disso se repete aqui.

Em vez disso, este curso monta um retrato da arquitetura do Sidekiq: a API, a dependência do Redis, as novas tentativas e a Web UI. Depois compara cada parte com o que o curso anterior mostrou sobre o Solid Queue deste app. As afirmações sobre o Sidekiq vêm do README, da wiki e do código do próprio Sidekiq, checados antes de serem ditos. As afirmações sobre este app vêm do código dele, checado de novo para este curso. Nenhuma das duas gems é "a certa" em abstrato. São duas respostas para o mesmo problema, e no fim você vai saber que concessões cada uma faz, além da fama.

O que este curso cobre

A aula 2 compara como uma classe de job fica em cada sistema, e por que os jobs deste app sobreviveriam a uma troca de adapter sem mudanças. A aula 3 trata de onde o trabalho enfileirado mora, numa estrutura do Redis ou numa linha do PostgreSQL, e quanto isso custa para operar. A aula 4 compara as novas tentativas automáticas do Sidekiq com o retry_on, que este app declara em alguns jobs e não em outros. A aula 5 mostra como cada sistema roda o trabalho: threads num processo, ou processos de dispatcher e worker. A aula 6 compara a Web UI do Sidekiq com este app, que não tem painel de jobs. A aula 7 coloca as evidências lado a lado para uma decisão de verdade, incluindo o relato do Rails sobre por que o Solid Queue existe e os benchmarks publicados pelo Sidekiq.