Rails 8 acelera carregamento de i18n e torna rotas thread-safe

A edição mais recente do This Week in Rails, assinada por Vipul A M no blog oficial do Rails, traz um conjunto de mudanças que interessa diretamente a quem roda aplicações Rails em produção no Brasil, onde internacionalização e concorrência costumam ser dor recorrente. Vale destacar duas frentes: performance de i18n e thread-safety no roteamento.

i18n mais rápido no boot

A mudança que mais chama atenção para apps brasileiros é o "Stop filtering i18n paths on initialize". O commit remove um trabalho redundante de path-globbing durante a inicialização do i18n. Segundo a fonte, numa aplicação com milhares de arquivos de locale o tempo de carga caiu de 400 ms para cerca de 250 ms.

Parece pouco em números absolutos, mas o contexto importa. Boot time impacta cold start em ambientes serverless, tempo de deploy em rolling releases e a experiência de desenvolvimento (cada rails console ou restart economiza esse tempo). Para apps que carregam pt-BR mais um punhado de outros idiomas com muitos arquivos de tradução espalhados, o ganho é real. Quem tem uma árvore de locales enxuta provavelmente nem vai notar, e tudo bem: é uma otimização que só brilha no volume.

Lazy route loading agora é thread-safe

O outro ponto crítico é o "Make lazy route loading thread-safe". O estado de desenho das rotas deixou de ser um booleano simples e passou a ser um flag de três estados protegido por um Monitor reentrante. Isso corrige uma condição de corrida em que threads concorrentes podiam despachar requisições contra um conjunto de rotas ainda meio desenhado.

O detalhe importa para quem usa servidores multithread como Puma com vários threads por worker, cenário comum em produção. Uma race no roteamento é o tipo de bug que aparece de forma intermitente, difícil de reproduzir e que some quando você adiciona logging. Fechar essa janela no framework poupa horas de investigação improdutiva.

Na mesma linha de concorrência, a edição traz avanços em compatibilidade com Ractors: thread_mattr readers e writers passam a funcionar dentro de Ractors (removendo a memoização da chave por thread, com acesso ainda na casa dos nanossegundos), e o middleware de controllers ficou Ractor-safe via abordagem copy-on-write. Ractors ainda são território experimental para a maioria dos times, mas o framework se preparando é sinal de direção.

Releases de segurança: prioridade máxima

Antes das melhorias de performance, uma nota que não deve passar batida: saíram as versões 7.2.3.2, 8.0.5.1 e 8.1.3.1. São releases de segurança que corrigem uma possível leitura arbitrária de arquivos e execução remota de código no processamento de variantes do Active Storage. A recomendação da fonte é direta: atualize o quanto antes. Se seu app manipula uploads de imagem com variantes (praticamente qualquer app com avatar ou thumbnail), esse é o item de maior prioridade da lista.

Limpezas e deprecações que valem anotar

O restante do changelog é composto de refinamentos que, somados, reduzem atrito no dia a dia:

• Resolução de template em uma passada: o Rails passa a encontrar o melhor match e vincular locals só para o vencedor, em vez de ordenar e vincular todos os candidatos. Menos trabalho por render.
• returning: com coluna única: agora aceita um nome de coluna simples e devolve o valor direto, sem forçar o desempacotamento de um array de um elemento.
• Deprecações no Active Record: predicados de TransactionState (fully_committed? e afins) dão lugar a committed?, rolledback? e completed?; argumentos posicionais de #insert cedem a returning:; e o argumento binds de to_sql, há tempos ignorado, agora emite aviso.
• Logs de SQL mais legíveis: binds com cast passam a aparecer com marcadores posicionais como $1 em vez de [nil, value], deixando clara a posição de cada valor no EXPLAIN.

Trade-off ao atualizar

O recado prático: separe as duas decisões. Os patches de segurança são não negociáveis e devem entrar rápido, com atenção ao changelog do Active Storage. Já as deprecações do Active Record pedem uma varredura no código antes do salto para o 8.1, principalmente se seu app usa os predicados de TransactionState ou chamadas posicionais de #insert. Nada disso quebra hoje, mas planejar a migração agora evita retrabalho depois. A semana teve 25 contribuidores, um lembrete de que boa parte desse polimento vem de melhorias incrementais da comunidade, não de features de manchete.

Fonte: Ruby on Rails Blog