Rails para Tudo - A força do Rails para tudo

• O Rails 8 é muito útil para projetos em pequena escala e desenvolvedores solo
• Com o guia de introdução mais recente, é possível construir um app em nível de produção com facilidade
• A melhoria do SQLite permite montar um ambiente de banco de dados robusto sem a necessidade de um servidor adicional
• Os geradores integrados de integração contínua e autenticação aprimoram a eficiência do desenvolvimento e a segurança
• O método de implantação simples via Kamal permite operar o serviço de forma rápida e segura

---

Visão geral

• Com base na experiência de uso do Rails 8, ele é um excelente framework web para projetos pequenos e desenvolvedores individuais
• A construção rápida, implantação eficiente e módulos integrados destacam vantagens de produtividade frente a frameworks concorrentes

Qualidade do guia atualizado

• O guia mais recente, Getting Started with Rails, é estruturado para que iniciantes consigam montar um app de produção
• Embora o processo de instalação do Ruby ainda seja complexo, seguindo as instruções do guia é possível construir um serviço sólido com autenticação, cache, rich text, integração contínua e banco de dados
• Seu ponto forte é oferecer fundamentos e recursos em nível de serviço real, em vez de um simples “Hello World”
• Para quem não está familiarizado com o Rails, ele se torna o melhor ponto de partida

O SQLite sozinho é suficiente

• O SQLite já é uma ferramenta excelente por padrão, mas até então era difícil configurá-lo para produção
• Antes era necessário instalar gems adicionais, mas no Rails 8 ele pode ser usado com confiabilidade em ambiente de produção sem trabalho extra
• Não é necessário subir PostgreSQL ou um servidor separado, e com solid cache não há necessidade de servidor Redis
• É possível operar o serviço apenas com Rails e SQLite, maximizando a simplicidade de implantação e eficiência de custos

Integração contínua (CI) fácil

• O fato de um alerta de falha de integração contínua (CI) chegar logo após o commit inicial mostra que o Rails 8 já fornece uma configuração padrão de CI integrada
• A integração com o GitHub Actions acontece sem configuração extra, e é possível receber 2.000 minutos gratuitos de tempo de execução por mês
• Para desenvolvedores solo, isso representa um tempo bastante generoso

Introdução do gerador de autenticação

• Gems de autenticação existentes, como Devise, eram poderosas, mas a complexidade de configuração as tornava um pouco difíceis para iniciantes
• No Rails 8, foi adicionado um gerador de autenticação simples que permite implementar facilmente o fluxo de login no console, bastando adicionar usuários já existentes
• O código gerado é simples e de leitura fácil, facilitando o entendimento para quem está começando

Implantação rápida e simples com Kamal

• O Kamal fica responsável pelo processo de deploy; basta editar parcialmente o arquivo deploy.yml e seguir o passo a passo para colocar o app em funcionamento em ambiente SSL imediatamente
• A experiência de deploy de web apps é mais rápida do que conectar SSL no GitHub Pages
• A combinação de integração contínua (CI) e deploy fácil é um dos pontos que mais se destacam no Rails 8
• Seguir apenas o guia de introdução já permite uma experiência de desenvolvimento alinhada com as melhores práticas mais recentes

Conclusão

• O Rails continua sendo um framework poderoso e em evolução
• Se você está pensando em um novo projeto neste ano, vale a pena considerar desenvolver com Rails 8

[aer0700]

Ultimamente vi muita publicação sobre SQLite, e agora até chegou a ponto de ser SQLite para tudo.
Isso pode ser chamado de um renascimento do clássico?

[GN⁺]

Comentários do Hacker News

• Ultimamente tenho usado o Spring Boot e a stack Micronaut, chegando até no frontend com React. O modelo omakase (tudo pronto e inclusivo) do Rails está me parecendo muito valioso. Até recursos simples que vêm do backend, como validação de formulário ou mensagens flash, não são resolvidos diretamente pelo framework, então preciso implementar ou procurar terceiros. O Rails já resolve de antemão problemas que 90% dos apps web enfrentam. Não dá para dizer que é perfeito, mas na maioria das vezes o que vem embutido basta, e dá para substituir quando necessário.
  • O Spring Boot já traz quase tudo de validação de formulário e você já consegue usar com anotações.
• Tanto o Rails quanto o Django são ótimos frameworks. Já fiz apps críticos em Python também. Mas fico com vontade de ir para Go em desenvolvimento de monólito grande, porque sinto que o sistema de tipos e a concorrência do Go são mais fortes. O problema é que o ecossistema Go não conseguiu criar um ecossistema de frameworks como Rails ou Django. Go é melhor para ferramentas de rede ou CLI, mas para construir uma app full-stack rápido eu ainda escolho Rails ou Django. Então eu não consigo sentir que “Rails acabou”.
  • Com ferramentas como o ogen, dá para gerar quase tudo automaticamente a partir de um documento OpenAPI: roteador estático, validação de request/response, monitoramento do Prometheus, tracing do OpenTelemetry etc. Também gera código de cliente e de webhook. Autenticação é só adicionar um recurso. Com sqlc e pragma user_version do SQLite, fica fácil ter código de DB tipado e migrations. Adicionar SQLite é só importar duas linhas no main.go. O template padrão do Go já dá conta de bastante processamento de texto no frontend, e com embed os assets estáticos entram fácil no binário. O deploy também fica muito simples: faz go build e só move o binário. Com ferramentas de geração de código, o desenvolvimento de backend em Go ficou bem rápido e simples.
  • Eu também queria uma stack completa de tipos estáticos e, mais claro do que Go ou Rust, a resposta certa foi ASP.NET. A Microsoft anda divulgando muito produto novo (ex.: Aspire.NET), mas na prática, o .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) é que é realmente “bateria incluída” e confiável. Exige uma virada de mentalidade para OOP e DI, mas para quem já tem experiência não é um problema grande.
  • O problema do ecossistema Go não é só mindset anti-framework, mas também anti-recursos modernos. Java, Kotlin, Scala, C#, F#, etc. também são ótimos para ferramentas de rede ou CLI. Hoje, o AOT do Java também não depende de licença comercial e o .NET também não está amarrado ao Windows.
  • Recomendo o Encore. Especialmente na integração com PaaS (como a combinação NextJS+Vercel), é muito forte. Vai ser um pouco diferente dos princípios centrais do Go, mas para equipe pequena ou desenvolvedor solo é uma escolha ótima. Se quiser, dá para fazer deploy por BYOC ou subir a camada de API direto com a stdlib sem estresse. No frontend ainda é melhor usar NextJS ou Remix/RR7, mas a geração automática do SDK cliente TypeScript facilita muito a integração. Encore também tem integração de PR com Vercel, o que é uma vantagem grande.
  • O que mais se aproxima de uma experiência parecida com Django em Go é o beego, que é até decente. Mas ainda não dá para dizer que atingiu maturidade de Rails ou Django.
  • Tenho um projeto em Go agora e estou satisfeito com a qualidade do código. A IA ajudou bastante a superar a barreira de entrada do framework. Ainda assim, penso que Rails é mais intuitivo para serviços orientados ao cliente, enquanto django é melhor para ferramentas internas e trabalho com dados.
  • Em Ruby, com Sorbet dá para fazer checagem de tipos, e a funcionalidade de concorrência com suporte a Fiber está quase completa. O novo servidor web Falcon está sendo construído em Fiber. Ainda não está no nível do Puma, mas em breve vai ficar pronto para uso de verdade.
  • O autor da linguagem Stanza escreveu um texto com um insight de que, para ter um framework forte (como Rails), a própria linguagem precisa de certos pré-requisitos. O fato de Go ou Java não terem esse tipo de framework é resultado de limitações da linguagem (ou do programador), de forma combinada.
  • O Go, originalmente, não foi orientado a frameworks full-stack desse tipo (Rails/Django).
  • Node/Express fica mais adequado para picoserviço local, e ASP.NET WebAPI/MVC é o backend ideal para mim.
  • O goravel dev também vale uma tentativa.
• Seguindo os Rails Guides do começo ao fim dá para lançar um serviço de verdade com autenticação, cache, rich text, CI e DB. Mas, embora seja adequado para gigantes como GitHub e Airbnb, em startup inicial pode ser perda de tempo adicionar tudo desde o começo, como autenticação do Devise, turbo e testes. Turbo traz vantagem de página mais rápida, mas às vezes conflita com recursos do devise e aumenta o tempo de desenvolvimento. Se a app ainda está na validação inicial de ideia antes do lançamento, para não ser app bancário/médico, dá para postergar testes ou CI sem grandes problemas. Não caia no viés de padrão (usar algo só porque existe), e recuse com firmeza o “não vou usar isso agora” quando algo não for necessário.
  • Se você vai montar um app SaaS, começar com templates especializados de Rails como Jumpstart Pro ou Bullet Train pode economizar meses de desenvolvimento. Elas já vêm com pagamentos, autenticação e outros recursos base, e expansão depois é tranquila.
  • Eu discordo da postura sobre testes. Mesmo uma app pequena ganha tempo se tiver código de teste. CI normalmente termina com um arquivo de umas 20 linhas; eu já copiei isso de projeto antigo.
  • CI é um elemento que acelera o desenvolvimento. Vale adicionar no início do projeto.
  • Gostaria de saber em que ponto vale migrar de Flask/Express/Sinatra/Gradio/Hono para Rails.
• O Rails novo está muito mais “brilhante” do que antes, e me deixa feliz. Mantive apps diversos por 12 anos desde o Rails 2.3, e hoje o Rails tem cara de Pokémon evolutivo totalmente diferente. O Rails Upgrade Guide é tão bem organizado que deu para seguir a atualização de uma vez sem grandes refatorações. Não é totalmente compatível com versões anteriores, mas o ponto positivo é que a mudança fica bem documentada. Houve muito avanço em anexar arquivos com ActiveStorage, e embora a migração para Webpacker tenha dado um pouco de trabalho, com Import Maps parece mais fácil. Planejo atualizar para 8.1 este ano.
  • Faz 4 anos que, para um cliente com orçamento apertado, aceitei cutback de pagamento e escolhi manter uma app Rails antiga (época do Ruby 2.3). No final, fiquei muito satisfeito porque ficou realmente fácil atualizar ou adicionar recursos.
• Tenho um projeto open source em Rails que atendo sozinho e dá para suportar 120 mil pessoas por mês; concordo bastante com o que foi dito. Além disso, o recurso de anexos do ActiveStorage é excelente. No deploy usei principalmente o Dokku, mas estou ansioso para experimentar o Kamal. O Rails segue evoluindo, e o Ruby está ficando cada vez mais rápido.
  • Se você gosta de Dokku, já testou Cloud Native Buildpacks? Com ele dá para gerar imagem OCI na hora.
• Para aprender Ruby, como o peso de desenvolvimento web não é grande para mim, o que eu conhecia era essencialmente só Django. Fico curioso para saber quais diferenças há entre os dois frameworks.
  • Tenho bastante experiência em ambos os ecossistemas (recentemente fiz menos Rails). Django é amarrado ao Python, Rails ao Ruby/gems, então o impacto do ecossistema é importante. O Django admin CMS é claramente mais forte que no Rails, e muitas organizações construíram todo o CMS interno em django. O Rails tem CLI de scaffolding enorme, então criar CRUD é realmente rápido. Rails é mais de alto nível de abstração e define bastante estrutura e arquitetura, enquanto no Django há muito mais escolhas próprias. Rails se prende mais em DRY e prevenção de código duplicado. Quem prioriza intuição pythonic pode achar a “mágica” do Rails pesada, e quem vem do Rails pode achar a repetição no Python meio crua. Essencialmente os estilos são diferentes.
  • Se eu fosse fazer uma app web (produto para consumidor), eu escolheria Rails primeiro. Sinto que é mais fácil chegar ao scaffolding e ao rollout de mercado (não tenho experiência real em serviço em grande escala). Para ferramentas internas, trabalho com dados ou georreferenciamento, python/django é melhor.
  • A maior diferença é python versus ruby. O ecossistema Python é enorme e o Django já tem autenticação e admin embutido.
  • No ambiente de testes, penso que a experiência em Rails é melhor. Rails já entrega configuração de CI junto com geração automática de testes.
  • Penso que o Django Admin é empiricamente bem mais flexível e fácil de usar do que alternativa no lado Ruby. Já em testes e roteamento, Rails é melhor e tem convenções fortes. Prefiro ActiveRecord+arel ao ORM do Django. (Pessoalmente, escrever código Ruby me parece mais divertido que Python.)
  • Aprender Ruby não é tão difícil e Rails já oferece muito mais estrutura e convenções prontas do que Django.
• Muita gente tem quase um apego de amor por Rails; eu não consigo sentir esse nível e às vezes fico até com inveja. Toda linguagem/framework tem seu fandom, mas no caso Rails o entusiasmo parece um pouco mais especial.
  • Também tenho bastante incômodo com algumas convenções do Rails, mas tentar ter produtividade parecida no backend JavaScript é quase impossível. Por outro lado, quando fico encarregado de código Rails, vejo bastante caso de implementação repetida de funcionalidades nativas do Rails (ex.: Active Job) sem necessidade real. Seguir convenções tende a ser sempre mais eficiente.
• Usei SQLite em produção e no fim sofri por causa de migração. Por exemplo, para adicionar restrição NOT NULL em coluna existente, precisa reescrever a tabela inteira com uma tabela temporária.
  • O SQLite também não tem ADD CONSTRAINT etc., e como não suporta linguagem PL ou stored proc simples, acaba exigindo roundtrip para a linguagem host o tempo todo, especialmente em linguagens estaticamente tipadas.
  • Eu acho que não vou abrir mão do Postgres tão fácil. Ainda assim, foi um progresso positivo ver o sqlite3 entrar como opção de primeira classe no Rails.
  • A recomendação padrão do Rails de sqlite como substituto do redis também é só de startup pequena. Se mais pra frente você vai migrar para outro DB, não recomendo começar com sqlite, porque migration sempre vira dor de cabeça.
  • No Rails, a maior parte dá para gerenciar com ActiveRecord validation, mas há limite para refletir restrições fundamentais.
• O guia de instalação do Ruby é meio complicado. Depois de 15 anos, montei um blog Jekyll e sofri um pouco com uso de gem e afins. Também teve falha minha, mas senti que seria melhor se fosse mais fácil de lidar. Mesmo assim isso me fez querer retomar Ruby.
  • Setup precisa ser fácil para todo mundo. Aprendi Jekyll rápido, porque já tinha Ruby e RubyGems no meu ambiente.
• Se for usar só SQLite, vale olhar para litestack. Não usei ainda, mas pretendo migrar meu projeto pessoal de Postgres para litestack. A performance no benchmark é muito impressionante.
  • Com o Rails 8 tendo fortalecido muito o sqlite, fico curioso se o litestack ainda é necessário. Quero entender qual é a diferenciação.