Solid Queue: apoiado em banco de dados
O curso examina como Solid Queue, Solid Cache e Solid Cable se conectam ao banco numa aplicação Rails. Cada um declara o próprio connects_to, então todo processo mantém quatro pools de conexão: primary, queue, cache e cable. Em desenvolvimento e teste, esses pools apontam para quatro bancos Postgres separados. Em produção, primary, queue e cable dividem um banco, e o cache tem o próprio. As aulas tratam também do custo em conexões dessa forma, de como o db:prepare acha cada arquivo de schema e do motivo da diferença entre ambientes.
O que você vai aprender
- ✓Como o connects_to dá a cada gem Solid o próprio pool de conexão
- ✓Por que desenvolvimento e teste usam quatro bancos Postgres separados
- ✓Por que a produção divide um banco entre primary, queue e cable e separa o cache
- ✓Quanto custam, em conexões, pools a mais num mesmo servidor Postgres
- ✓Como o db:prepare carrega o arquivo de schema de cada papel e para que serve o migrations_paths
- ✓Por que a contagem de pools e a de bancos são perguntas independentes
connects_to e quatro pools de conexão reais
O curso de nível Pleno "Solid Queue: arquitetura de jobs" examinou onze tabelas: solid_queue_jobs, as reservas, as linhas de concorrência. Nenhuma delas é acessada pelo ApplicationRecord. Elas ficam atrás do SolidQueue::Record, outra classe base, noutra conexão. Esta aula examina essa separação no…
Ler a aula completa grátis →Currículo
7 aulasconnects_to e quatro pools de conexão reais
Mostra que Solid Queue, Solid Cache e Solid Cable usam o próprio connects_to, criando quatro pools de conexão separados.
Dev e teste: quatro bancos físicos separados
Desenvolvimento e teste dão a cada papel um banco Postgres próprio, o que impede joins e transações entre eles.
Produção: três papéis compartilham um banco
Em produção, primary, queue e cable dividem um banco, e o cache ganha o próprio por causa dos backups.
Ainda quatro pools compartilhando um banco: o custo real
O Rails ainda cria um pool por papel quando os papéis dividem um banco, o que custa conexões Postgres a mais.
migrations_paths: como o schema-load acha o arquivo certo
Explica como o db:prepare carrega o schema de cada papel e por que os três diretórios de migrations_paths ainda não existem.
Por que isolar, se produção não isola
Compara o isolamento em desenvolvimento e teste com o compartilhamento em produção, e a troca por trás de cada escolha.
Juntando tudo: um connects_to, duas formas reais
Separa a contagem de pools da contagem de bancos e apresenta o desafio ConnectsToPlanner, que modela as duas perguntas.