Lançamento do Rails 7.1

• Ao usar config.load_defaults 7.1, a serialização padrão de ActiveSupport::MessageVerifier e ActiveSupport::MessageEncryptor muda de Marshal para ActiveSupport::JSON, e mensagens Marshal existentes continuam podendo ser lidas
• ActiveRecord::Base.serialize passa a não usar YAML por padrão, e o comportamento anterior pode ser restaurado com config.active_record.default_column_serializer = YAML
• Um novo formato de cache 7.1 foi adicionado e é usado como padrão em novos apps; apps existentes podem ativá-lo com config.load_defaults 7.1 ou config.active_support.cache_format_version = 7.1
  • Itens gravados nos formatos de cache 6.1 ou 7.0 podem ser lidos no formato 7.1
  • Em rolling deploys do Rails 7.1, é preciso manter o formato de cache na primeira implantação e ativar o formato de cache 7.1 em uma implantação posterior
• As serializações :message_pack e :message_pack_allow_marshal foram adicionadas a MessageEncryptor, MessageVerifier e config.active_support.message_serializer, exigindo a gem msgpack >= 1.7.0
• ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration, e objetos de criptografia do Active Record passam a evitar exposição de segredos em inspect, e a proteção contra XSS em ActionView::Helpers e ERB::Util foi reforçada
• has_secure_password ganha validação password_challenge e o método #{attribute}_salt, e authenticate_by foi adicionado para reduzir ataques de enumeração baseados em tempo conforme a existência da conta
• O suporte a chaves primárias compostas e chaves estrangeiras compostas foi ampliado no Active Record, incluindo suporte à sintaxe de tupla em where, ordenação em lote por chave composta e inferência de chave primária composta no schema
• O suporte a PostgreSQL recebe comandos de migração para renomear enums, adicionar valores e alterar valores, além de exclusion constraint, unique constraint, opção de índice INCLUDE e suporte a índices NULLS [NOT] DISTINCT
• O adaptador SQLite3 passa a indicar ganho médio de desempenho de 2× com Write-Ahead-Log normal syncing mode, tamanho de journal limitado, shared memory buffer e shared cache, e o modo strict strings, que desativa literais de string com aspas duplas, vem ativado por padrão
• A iteração em lote por tabela inteira no Active Record agora usa range iteration por padrão para melhorar o desempenho; em testes no PostgreSQL com 10 milhões de registros, foram apresentados resultados de querying 253s→30s, updating 288s→124s, deleting 268s→83s
• Connection pooling passa a vir ativado por padrão em MemCacheStore e RedisCacheStore; para desativar, é necessário definir pool: false na configuração do cache store
• Foi adicionado um adaptador para o cliente de banco de dados Trilogy, permitindo usar adapter: trilogy ou DATABASE_URL no formato trilogy://
• O formato padrão de tags de ActiveRecord::QueryLogs foi alterado para o formato SQLCommenter, e o formato anterior pode ser usado com config.active_record.query_log_tags_format = :legacy
• Entre os itens descontinuados e removidos estão o uso do singleton ActiveSupport::Deprecation, SafeBuffer#clone_empty, o argumento rewhere de #merge, deferrable: true em add_foreign_key, TestFixtures#fixture_path, além da limpeza de várias configurações e APIs deprecated do Active Record
• ActionView::TestCase.register_parser foi adicionado aos testes de Action View para registrar parsers do resultado renderizado, com :html e :json fornecidos como parsers padrão

[GN⁺]

Opiniões do Hacker News

• Rails é excelente e agora está melhor do que nunca
  No começo da carreira eu usava principalmente Django e Laravel; depois migrei para o trabalho de front-end que é comum hoje em dia e, este ano, voltei a pegar um projeto com Rails + Hotwire
  Fiquei sinceramente impressionado com o quanto tudo ficou simples, e é uma pena que a maioria tenha esquecido que poderia ser tão fácil assim. Também assusta pensar que quem está entrando no setor agora talvez nunca experimente essa simplicidade
  Se você nunca usou Rails ou desistiu depois de ouvir coisas como “PHP é feio / Rails morreu / JavaScript é bagunçado”, recomendo ignorar por um momento o que os outros dizem e experimentar com a mente aberta
  Talvez não seja a melhor opção para um ambiente em que 1.000 engenheiros trabalham no mesmo repositório, mas para equipes pequenas ele não tem concorrentes e está muito à frente das alternativas. Sinceramente, talvez o Laravel chegue perto de ser tão bom quanto

  • Eu também colocaria Phoenix LiveView nessa lista
    Em velocidade de desenvolvimento inicial, acho que Rails sempre vence. As convenções são tão densas e bem projetadas que quase nada chega perto. Laravel está se aproximando, mas na minha opinião ainda não chegou lá
    Por outro lado, o LiveView escala melhor em todos os sentidos. Ele também traz muita coisa de fábrica, como autenticação, acesso a banco de dados, filas de tarefas, mailers e ferramentas completas de teste; quase não é preciso escrever JavaScript diretamente; e ainda há a excelente máquina virtual BEAM
    No mínimo, é bom que todos esses projetos estejam lutando por “dar um passo atrás”. No trabalho uso React e Relay e, mesmo tendo usado JavaScript no front-end por muito tempo e achando que me viro razoavelmente bem, há obstáculos demais a superar, e isso cansa
  • Comparando com Django, é interessante que, pelo menos hoje, eu não os veja no mesmo nível. Fico curioso se há motivos concretos para preferir Rails a Django
  • Gosto de Rails, mas no meu país quase ninguém usa, e as empresas que usam procuram desenvolvedores praticamente de nível mago
    Como não consigo emprego, também não consigo acumular experiência suficiente e, no fim, acabo sendo superado por esses magos. Às vezes essas vagas ficam abertas por mais de 12 meses
    Em vez disso, como há demanda, estou espalhando mais JavaScript pelo mundo
  • Um bom número de desenvolvedores Rails que conheço migrou para ember.js. Isso porque ember.js também é um framework baseado em convenções, e não um em que inúmeros plugins de terceiros vivem quebrando
    Estruturalmente, gosto da abordagem do ember-data. Há muita coisa que pode ser automatizada em operações como left joins/right joins de conjuntos de dados, e ele também tem um servidor de mocks integrado
    Mas talvez por funcionar bem demais, ele não pareça tão empolgante quanto outras coisas
    https://emberjs.com/

• Atualizei um app Rails 7.0 de 13.000 linhas para 7.1 e, tirando as diferenças entre 7.0 e 7.1[0], tudo funcionou mudando apenas 1 linha do código de configuração de testes
  Em termos de um caminho de upgrade fácil, considero um sucesso. Agora a parte divertida é refatorar alguns trechos para usar os novos recursos do 7.1
  Se houver interesse, também atualizei para 7.1 um app de exemplo Rails / Docker https://github.com/nickjj/docker-rails-example
  Embora o Rails 7.1 inclua um Dockerfile, ainda há muitas opções para acrescentar, como usar Docker Compose para criar uma experiência que funcione diretamente em desenvolvimento e produção e incluir Postgres, Redis, Action Cable, Sidekiq etc.
  [0]: https://railsdiff.org/7.0.8/7.1.0

• Estou tentando migrar uma codebase Rails 6 bem grande, cheia de React, para uma nova abordagem “não” JavaScript usando Hotwire. Me desejem sorte
  Rails é ótimo quando você segue os padrões, mas, no momento em que sai deles, vira uma terra de sofrimento

  • Estou trabalhando em uma codebase Rails 7 relativamente recente. No começo passamos a usar Stimulus, mas, por alguns motivos, estamos considerando migrar para React
    Para contratar engenheiros de front-end, o conjunto de candidatos com React é várias ordens de grandeza maior. Também está ficando cada vez mais difícil encontrar pacotes de JavaScript vanilla para tarefas comuns e envolvê-los em controllers Stimulus do que encontrar pacotes React
    O Stimulus também não oferece exatamente uma forma de escrever testes unitários de controllers. No React, dá para usar jest e react-test-renderer como de costume
    Além disso, a recente polêmica sobre TypeScript no Turbo não passou confiança quanto à manutenção de longo prazo do ecossistema Hotwire
    Ainda não tomamos uma decisão. É claramente uma vantagem que o Stimulus pareça uma forma muito “à la Rails” de escrever código de front-end, especialmente para equipes pequenas que já conhecem Rails
  • A ideia de que “Rails é bom se você segue os padrões e doloroso se sai deles” vale para todos os frameworks
    Se a aplicação é relativamente simples e se encaixa bem no jeito do framework, o framework é ótimo. Se você precisa de uma configuração mais complexa e flexível, deve olhar para bibliotecas
  • Perdi a confiança na integração JavaScript do Rails
    Hoje faço renderização do lado do servidor com slim, ou faço apenas API e separo o front-end
    O Rails mudou de direção vezes demais ao tentar lidar com JavaScript: CoffeeScript, pré-compilação de assets, webpack etc.
  • Eu não recomendaria migrar um front-end React existente para Hotwire ao mesmo tempo que faz o upgrade do próprio Rails. Acho melhor primeiro atualizar de forma independente até o Rails 7.1
    Para referência, a forma de lidar com JavaScript de aplicações single-page no Rails 7+ também é muito mais sensata do que antes. Na prática, você usa a ferramenta de build que quiser separada do app Rails
    Durante o desenvolvimento, é preciso rodar algo como yarn build --watch junto com rails s, mas, pessoalmente, acho que não é ruim e fica muito mais simples
    Minha empresa cria software para automatizar upgrades de Rails e também oferece um serviço completo que faz upgrades de Rails por você. Se tiver interesse, entre em contato em steve (at) infield.ai ou gere um plano gratuito de upgrade de Rails em https://app.infield.ai/users/sign_up. Não precisa de cartão de crédito
    Mais detalhes em https://docs.infield.ai/docs/creating-an-upgrade-path
  • Recomendo experimentar https://vite-ruby.netlify.app/guide/rails.html
    No meu caso, encaixou quase diretamente como substituto do webpack

• Gosto de Rails e o uso de forma intermitente desde o Rails 2
  É um framework muito bom e, para alguém como eu, que às vezes precisa colocar um site no ar, é realmente o caminho de menor resistência
  Mas o processo de configurar um notebook novo para rodar Rails é sofrido. Precisa de node, e aí precisa de npm. Como sou desenvolvedor de back-end, não sei bem como configurar node nem em que ordem fazer as coisas
  Como não é algo que faço com frequência, toda vez parece uma batalha. No fim eu consigo, mas nunca tenho certeza de por que finalmente tudo se encaixou
  Seria bom ter um instalador que ajustasse tudo que é necessário de uma vez para o rails simplesmente funcionar. O instalador do rvm configura o rails em cima do ruby, mas não configura o sistema node por baixo

  • Um gerenciador de versões chamado asdf é bom para gerenciar nodejs. Nunca usei com Ruby
    https://asdf-vm.com/
  • Entendo a frase “sou desenvolvedor de back-end, então não sei configurar node”
    O Node é conhecido principalmente como ferramenta de front-end, e o Rails também o usa para isso, mas, pelo que me lembro, o Node foi criado, pelo menos no início, para levar o runtime JavaScript ao back-end
    Mesmo sem gerenciador de pacotes, no Windows é simplesmente node.exe; pelo que sei, basta baixar e descompactar o npm e colocar node e npm na variável de ambiente PATH
  • Toda a premissa do Rails 7 é justamente remover a dependência de node
  • Nunca usei Rails, então fiquei curioso: queria saber por que “Ruby on Rails” precisa de nodejs
    E instalar node é bem fácil. Na verdade, fácil demais. Eu gostaria que fosse muito mais difícil e exigisse um diploma
  • A comunidade Ruby/Rails é uma das melhores e mais acolhedoras que já vi. Mas o pior nela, de longe, é o ódio a JavaScript
    JavaScript é só uma ferramenta, como qualquer outra. Gostando ou não, é uma ferramenta muito importante e, gostando ou não, vai continuar por aí por muito tempo
    Com um pouco de mente aberta e aprendendo pelo menos o básico, as coisas vão ficar mais fáceis

• Espero que Rails + HTMX, junto com um pouco de JavaScript espalhado apenas nas páginas muito interativas, volte a ganhar força
  Usar Rails com Slim/HAML é realmente prazeroso. Se quiser, também dá para facilitar renderizações parciais com bibliotecas como ViewComponents. Somando web components a isso, dá para criar páginas bastante interativas e, se realmente for necessário em uma página específica, também dá para usar React
  HATEOAS reduz bastante a complexidade da aplicação. Ainda assim, se você precisar de uma API, também é muito fácil responder a diferentes tipos MIME e, se quiser, pode até compartilhar o mesmo endpoint
  Pela minha experiência, a maioria das aplicações que usam React na verdade não precisa de React de jeito nenhum. Usam React por causa de alguns menus pop-up
  Então, se começarem a surgir apps grandes sem React, ou com muito pouco React, espero que algumas pessoas percebam o quanto nossas aplicações hoje são desnecessariamente complexas
  Mas já estou vendo gente dizer “todo mundo usa React, então precisamos mudar para React”. Dá vontade de suspirar
  Sonhar não custa

• O anúncio oficial está aqui: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
  Há um pouco mais de detalhes em alto nível, e estou animado para experimentar algumas das novidades. Em especial, os novos métodos de consulta assíncrona parecem ser bem úteis para ganhos rápidos de performance

• Rails no backend não recebe todo o reconhecimento que merece
  Mas, no lado do frontend, foi uma bagunça por muito tempo

  • Não discordo de que “o lado do frontend foi uma bagunça por muito tempo”, mas o próprio frontend também foi uma bagunça por muito tempo
    Hoje é prazeroso trabalhar com a combinação Rails 7.1 + Hotwired + Importmaps
    Mas foi preciso esperar até que os navegadores tivessem bom suporte ao menos a ES6 e Import Maps
    Pela data deste artigo, https://web.dev/import-maps-in-all-modern-browsers/ anunciou em 28 de março de 2023 que importmaps podiam ser usados em todos os navegadores modernos
    Então, até agora não havia como evitar Webpack, Yarn e outras ferramentas auxiliares de JavaScript
    Agora que temos importmaps e o suporte dos navegadores a ES6 já é bom o suficiente, https://caniuse.com/?search=es6, dá para escrever JavaScript moderno quase sem ferramentas adicionais
  • Concordo. Quais seriam as opções aqui? Rails em modo somente API?
  • Gosto dos novos recursos do Hotwire. Fico curioso para saber do que você não gosta no frontend

• Algumas semanas atrás, um amigo brincou: “Se uma release do Rails foi anunciada e você não abriu o PR de upgrade, isso realmente aconteceu?”
  Bom, agora é hora de abrir o PR. Mesmo que eu tenha que empilhá-lo atrás do PR para 7.0 que está parado há meses

• Pela minha experiência, muitas equipes têm dificuldade para criar uma base de código limpa com ActiveRecord

• Espero que não me batam por isso, mas ainda uso Rails 4.2 e estou satisfeito
  Ele oferece tudo de que preciso para trabalhos de SaaS backend sem JavaScript, ou com pouco JavaScript, que faço por conta própria ou para empresas B2B, e roda até em VPS de baixo custo
  Se alguém tiver tempo para responder, tenho curiosidade: por que eu deveria fazer upgrade?

  • Eu também uso versões antigas. Primeiro, é preciso verificar se você consegue subir pelo menos até a versão de patch/minor mais recente
    O principal problema de versões antigas são vulnerabilidades nas gems associadas. Por exemplo, talvez não seja possível atualizar nokogiri sem um upgrade major do Rails
    Dito isso, a maioria dos apps não faz, por exemplo, parsing complexo de XML, então muitas dessas vulnerabilidades não se aplicam. Por isso é preciso algum trabalho de manutenção para verificar se está seguro. Também é comum aplicar monkey patches para evitar bugs
    Fazer upgrade melhora a segurança e reduz o tempo de manutenção. Mas também é preciso considerar o custo de upgrades constantes. Outro fator é que versões novas podem dar suporte a Rubies mais rápidos
    Em geral, quando crio um app Rails, uso a release mais recente, mas depois não atualizo as versões do Rails a menos que algo deixe de funcionar em sistemas novos porque o app é popular ou muito antigo
  • Você deve fazer upgrade por causa da segurança