Olá, Rubista! 👋
Me chamo Amália e a partir de hoje sou sua companheira aqui na Academia do Ruby. Toda semana vou farejar o que aconteceu no mundo do desenvolvimento Ruby e trazer o que realmente importa para o seu dia a dia. Sem enrolação e de maneira bem didática.
Esta é a edição #01 do Radar da Semana. Estreia com tudo. Vamos lá?
Ruby & Rails
Benchmark independente valida a Tríade do Solid do Rails 8
Um desenvolvedor migrou as três responsabilidades clássicas do Redis — cache, pub/sub e filas de background jobs — inteiramente para PostgreSQL, usando recursos nativos do banco que normalmente delegamos ao Redis. Os números: INSERT em 0.08ms vs Redis SET em 0.05ms para cache; latência de 2–5ms vs 1–2ms em pub/sub; dequeue em 0.3ms vs 0.1ms em filas. Diferenças negligenciáveis para a esmagadora maioria das aplicações. O resultado prático: ~$100/mês de economia e um sistema a menos para monitorar, configurar e fazer backup.
Isso importa porque é uma validação externa e independente da decisão arquitetural que o Rails 8 tomou com o Solid Cache, Solid Cable e Solid Queue. DHH e a equipe do Rails não inventaram esse padrão — consolidaram uma tendência que agora tem números reais documentados. Se você está no Rails 8 e ainda mantém o Redis por apenas costume, vale reavaliar. Para aplicações com volume moderado de mensagens e jobs, a Tríade do Solid entrega essa simplificação pronta, integrada ao framework.
O que vem no Rails 8.2: Action Text com Markdown e melhorias de DX
O branch main do Rails recebeu cinco mudanças notáveis esta semana — ainda não publicadas em nenhuma versão estável (a última é a 8.1.2), mas que provavelmente integrarão o Rails 8.2. A mais relevante: o Action Text ganhará um método to_markdown em todos os seus componentes principais, convertendo rich text HTML em Markdown com preservação de formatação, listas, links e tabelas.
Para quem desenvolve com devcontainers, a nova variável RAILS_HOST_APP_PATH resolverá um ponto de fricção real: links de editor nas páginas de erro que não funcionavam dentro de containers Docker agora traduzirão caminhos corretamente. É o tipo de melhoria de experiência de desenvolvimento que não aparece em keynotes mas elimina atrito diário.
Ressuscitando aplicações Rails legadas sem reescrever tudo
Modernizar uma aplicação Rails antiga é uma das tarefas mais temidas — e mais comuns — do dia a dia de quem trabalha com Ruby no mercado real. Um artigo de Mircea Mare retoma o princípio de Joel Spolsky ("o pior erro estratégico é reescrever sua codebase do zero") e propôs quatro técnicas concretas: inventariar monkey patches com categorização explícita, cobrir cada patch com testes de regressão antes de tocar no código, implementar forward compatibility com guards de versão, e dual-booting contra múltiplas versões do Rails via Gemfile_upgrade.
Esse é um tema também foi destaque na Live #55 da Academia do Ruby, onde o Daniel compartilhou experiências diretas com clientes reais — incluindo um projeto preso no Rails 3.2 onde nenhuma gem atual funcionava e tudo quebrava. A conclusão prática: antes de subir qualquer versão, é preciso enxugar o projeto — remover gems abandonadas, eliminar dependências duplicadas e aposentar helpers que já viraram funcionalidade nativa do framework. Cada linha removida é menos atrito na migração.
O caminho não é um salto, é uma subida em camadas. Cada versão do Rails tem marcos críticos que exigem adaptações específicas — do Zeitwerk no 6.0 ao fim do Webpacker no 7.0, passando pela Attributes API do 5.0. Conhecer esses marcos é o que transforma uma atualização caótica em um processo previsível. O Shopify é a prova viva de que apps Rails antigas podem evoluir continuamente sem rewrites destrutivos.
Aqui na Academia do Ruby tem um artigo exclusivo sobre o tema, complementar à live, disponível para membros da comunidade.
Performance & Infraestrutura
SPAs como gargalo arquitetural: o argumento técnico ganha corpo
Yegor Bugayenko publicou um artigo argumentando que SPAs — aquelas aplicações onde o JavaScript no browser monta toda a interface consultando o backend — adotadas originalmente como solução de performance, se tornaram um gargalo estrutural. O problema central: dezenas de requisições sequenciais ao backend para montar uma única página, com cada request revelando dados necessários para a próxima chamada. O Stack Overflow foi citado como contraponto: server-side rendering, ou seja, o servidor entregando a página já montada, com tempo abaixo de 50ms por request.
A conclusão — HTML gerado no servidor com componentes interativos seletivos como arquitetura superior ao padrão de APIs JSON consumidas pelo frontend — é exatamente a tese que o Rails 7 formalizou com o Hotwire. Não é coincidência. É uma convergência técnica que indica que o Rails está no caminho certo!
Comunidade & Ecossistema
Basecamp integra Claude Code como padrão no Omarchy v3.4.0
O Omarchy — distribuição Linux baseada em Arch mantida pela Basecamp — lançou a versão 3.4.0 com o Claude Code instalado por padrão. O Claude Code é uma ferramenta de linha de comando que usa IA para ler, escrever e modificar código diretamente no seu projeto. A release também traz layouts de terminal desenhados especificamente para desenvolvimento com agentes de IA.
O sinal aqui é institucional: a Basecamp, guardiã do Rails, está apostando ativamente em workflows de desenvolvimento assistido por IA no seu próprio ambiente de trabalho. Isso indica a direção que ferramentas e práticas do ecossistema Ruby devem seguir nos próximos meses. Quem ainda trata IA como curiosidade pode querer reconsiderar — a empresa que mantém o framework já a incorporou no setup padrão.
Destaque da Academia
Esta semana conectou dois movimentos que parecem distintos mas nascem da mesma convicção: simplicidade arquitetural como vantagem competitiva.
De um lado, o benchmark PostgreSQL vs Redis mostrando que a complexidade operacional do Redis é, para a maioria das aplicações, um custo que não se justifica. Do outro, o debate sobre SPAs evidenciando que camadas de abstração no frontend frequentemente adicionam latência sem entregar valor proporcional. Em ambos os casos, a resposta é a mesma: use bem o que o browser e o banco de dados já oferecem nativamente.
O Rails entendeu isso antes da maioria. A Tríade do Solid não surgiu de um surto coletivo — é o resultado de anos observando que a maioria dos projetos Rails não precisa de Redis em produção, assim como não precisa de um framework JavaScript para renderizar uma tabela. O Hotwire segue a mesma lógica: Turbo e Stimulus não são frameworks que competem com React — são ferramentas que recusam a premissa de que o browser precisa de intermediários para funcionar.
Na Academia do Ruby temos investido propagar esse conhecimento. O curso "Dê um Turbo no Seu Projeto" aprofunda o Hotwire com casos práticos — a tecnologia aplicada de maneira estratégica: que impacta desempenho, manutenibilidade e custo de infraestrutura.
Conselho da Semana
Se você mantém Redis em produção por hábito ou comodidade, eu te trouxe números concretos para fundamentar uma conversa séria com seu time. Se sua aplicação é um SPA que faz 30 requests para montar uma página, os argumentos técnicos contra essa arquitetura estão mais sólidos do que nunca. E se você tem um projeto Rails legado que todo mundo tem medo de tocar — as estratégias para modernizá-lo sem reescrever tudo existem e são documentadas.
O padrão que conecta tudo: questione a complexidade herdada. Não a complexidade do problema — essa é real e merece respeito. A complexidade das soluções que você adotou sem perguntar se ainda faziam sentido. Cada dependência que você remove é uma superfície de falha a menos, um deploy mais previsível, uma noite de sono a mais.
Simplifique com intenção. Esse é o trabalho mais difícil — e também o mais valioso.
Ainda não há comentários. Seja o primeiro a comentar!