Ruby on Rails é um framework para construir aplicações web em Ruby. A diferença dele não está no que permite fazer, e sim no que ele decide por você: estrutura de pastas, conversa com o banco de dados, rotas, filas, envio de e-mail e onde os testes moram já vêm resolvidos e iguais em todo projeto.
Este texto mostra o que é convenção sobre configuração e o que ela custa, onde Rails é a escolha certa e onde não é, como ele se compara a Django e Laravel, a objeção do tamanho do mercado e por que é a stack em que a Northern constrói.
O que é, e o que ele decide por você
Quase nenhum projeto web parte da linguagem pura. Entre a linguagem e o produto existe um framework, e escolher a linguagem é, na prática, escolher o framework dela: Python para web é Django, PHP é Laravel, Ruby é Rails. Na rotina de um time, essa escolha decide mais que a sintaxe.
O que já vem pronto no Rails, e que em outros lugares é decisão de projeto:
- Acesso ao banco de dados, com as tabelas representadas como classes e a evolução do banco versionada em arquivos que acompanham o código.
- Rotas e organização do código, com um lugar previsível para cada coisa.
- Autenticação e sessão, sem escolher biblioteca de terceiro para a tarefa mais comum que existe.
- Trabalho em segundo plano, para o que não pode travar a tela: envio de e-mail, geração de arquivo, chamada a serviço externo.
- Cache, e-mail, armazenamento de arquivo e testes, cada um com endereço definido.
A consequência prática é que o tempo entre decidir uma funcionalidade e tê-la funcionando na tela é curto, porque nenhuma das perguntas de infraestrutura precisa ser respondida de novo.
Fora do que vem embutido, existe um ecossistema de bibliotecas prontas para o que se repete em todo projeto: cobrança recorrente, geração de PDF, importação de planilha, painel administrativo, autorização por perfil. São peças mantidas há anos e usadas por muita gente, o que importa mais que a quantidade: biblioteca abandonada é dívida, não atalho. A régua para escolher é a data do último lançamento e quantos projetos dependem dela.
Convenção sobre configuração, e o que ela custa
Rails é o mais opinativo dos três frameworks grandes: ele não oferece opções para as decisões de estrutura, já as tomou. Quem conhece Rails encontra o que procura em um projeto que nunca viu, porque o arquivo está onde tem que estar.
A liberdade que se perde é a de organizar cada projeto de um jeito diferente, e vale dizer com clareza que essa perda é real. O ponto é quando ela dói: o custo de cada projeto ter estrutura própria não aparece no primeiro ano, quando o time é o mesmo que escreveu tudo. Aparece no terceiro, quando alguém precisa mexer em código que ninguém do time atual escreveu.
Ou seja, o que a convenção compra não é velocidade no começo. É custo de manutenção estável ao longo do tempo, que é a linha que costuma decidir se um produto continua evoluindo ou congela.
Onde é a escolha certa, e onde não é
| Rails encaixa quando | Rails não é a escolha quando |
|---|---|
| o produto é novo e o time é pequeno | há processamento intensivo de cálculo |
| há muita regra de negócio e operação de cadastro | o sistema precisa de latência muito baixa |
| o prazo até a primeira versão utilizável é curto | o projeto é de dados ou de IA, onde o ecossistema de Python não tem equivalente |
| é provável mudar de direção sem reescrever tudo | o time já é fluente em outra stack |
A última linha da coluna da direita é a mais ignorada. Trocar de framework para ganhar produtividade e perder meses de aprendizado do time é mau negócio mesmo quando o framework novo é melhor no papel. Stack se escolhe uma vez, no começo, ou quando existe motivo grande o suficiente para pagar a migração.
Rails, Django e Laravel
Os três resolvem o mesmo problema e a escolha entre eles raramente é técnica. Rails é o mais opinativo, com o ganho e o custo descritos acima. Django tem a vantagem decisiva de morar no ecossistema de Python, o que importa muito quando o produto tem componente de dados ou de modelo. Laravel tem o maior mercado de profissionais no Brasil e a hospedagem mais barata e disponível.
O critério honesto para decidir entre eles é o do time, não o do framework: em qual deles você consegue contratar, manter alguém e ter um segundo par de olhos quando precisar. Um framework excelente sem ninguém disponível para trabalhar nele é risco, não vantagem. O panorama completo das linguagens está em linguagens de programação.
A objeção do mercado de desenvolvedores
É a crítica legítima e a mais repetida: há menos gente escrevendo Ruby que Python ou JavaScript. Ela pesa menos do que parece, por dois motivos.
O primeiro é que o mercado que importa não é o global: é o de quem você consegue contratar e manter. Número de profissionais no mundo não ajuda quem precisa de duas pessoas boas na sua cidade ou no seu fuso.
O segundo é mais interessante, e é consequência da convenção: quando o framework já tomou as decisões de estrutura, o tempo até um desenvolvedor experiente ficar produtivo em um projeto que ele não escreveu é curto. Isso ataca exatamente o problema que a rotatividade cria, que é o custo de entrada de cada pessoa nova. O caminho prático de contratar está em como contratar desenvolvedores web.
O mito de que serve só para começar
A leitura de que Rails é bom para protótipo e ruim para escala não se sustenta na evidência mais simples: GitHub, Shopify e Basecamp rodam em Rails há mais de uma década, em volume que não tem nada de estágio inicial.
O que essa lista mostra não é a marca das empresas. É que produtividade alta e capacidade de escalar não são coisas que se trocam uma pela outra, e que gargalo de aplicação web quase nunca é a linguagem: é consulta mal escrita ao banco, ausência de cache e trabalho pesado feito na hora em vez de em segundo plano. Nenhum desses três problemas se resolve trocando de framework.
Por que é a nossa stack
É a stack em que a Northern constrói: Ruby on Rails no servidor. O motivo é o mesmo que orienta as nossas outras decisões de projeto: o que limita produto digital novo quase nunca é a velocidade da máquina, e quase sempre é quanto tempo leva para uma decisão virar algo funcionando na tela.
Isso tem consequência direta em duas coisas que o cliente sente. A primeira é o prazo até existir algo que dá para usar e criticar, em vez de slide. A segunda é o custo de mudar de ideia depois da primeira versão, que é o momento em que quase todo produto descobre que precisa mudar.
Como esse cálculo aparece no orçamento está em quanto custa desenvolver um produto digital, o processo de trabalho em volta em desenvolvimento de software, e o recorte que vem antes de qualquer escolha de tecnologia em como definir o escopo do primeiro produto digital. Se a dúvida ainda é entre construir e contratar pronto, o corte está em software house.
Perguntas frequentes
O que é Ruby on Rails?
É um framework para construir aplicações web em Ruby. A diferença dele não está no que permite fazer, e sim no que decide por você: estrutura de pastas, conversa com o banco de dados, rotas, filas, envio de e-mail e onde os testes moram já vêm resolvidos e iguais em todo projeto. Escolher Ruby para web é, na prática, escolher Rails.
O que já vem pronto no Rails?
Acesso ao banco com as tabelas representadas como classes e a evolução do banco versionada em arquivos que acompanham o código. Rotas e organização, com lugar previsível para cada coisa. Autenticação e sessão. Trabalho em segundo plano para o que não pode travar a tela. E cache, e-mail, armazenamento de arquivo e testes, cada um com endereço definido.
O que é convenção sobre configuração?
É o Rails não oferecer opções para as decisões de estrutura, tendo já as tomado. Quem conhece Rails encontra o que procura em um projeto que nunca viu, porque o arquivo está onde tem que estar. A liberdade que se perde é a de organizar cada projeto de um jeito diferente, e essa perda é real.
Qual o custo da convenção?
Perder a liberdade de estruturar cada projeto do seu jeito. O ponto é quando ela dói: o custo de cada projeto ter estrutura própria não aparece no primeiro ano, quando o time é o mesmo que escreveu tudo, e aparece no terceiro, quando alguém mexe em código que ninguém do time atual escreveu. O que a convenção compra não é velocidade no começo, é custo de manutenção estável.
Quando Ruby on Rails é a escolha certa?
Quando o produto é novo e o time é pequeno; quando há muita regra de negócio e operação de cadastro; quando o prazo até a primeira versão utilizável é curto; e quando é provável mudar de direção depois sem reescrever tudo. São as condições da maioria dos produtos digitais em construção.
Quando Rails não é a escolha?
Quando há processamento intensivo de cálculo; quando o sistema precisa de latência muito baixa; quando o projeto é de dados ou de IA, onde o ecossistema de Python não tem equivalente; e quando o time já é fluente em outra stack. Essa última é a mais ignorada: trocar de framework e perder meses de aprendizado é mau negócio mesmo quando o novo é melhor no papel.
Rails, Django ou Laravel?
Os três resolvem o mesmo problema e a escolha raramente é técnica. Rails é o mais opinativo. Django tem a vantagem de morar no ecossistema de Python, o que importa quando o produto tem componente de dados ou de modelo. Laravel tem o maior mercado de profissionais no Brasil e hospedagem mais barata. O critério honesto é o do time: em qual deles você consegue contratar e manter alguém.
Existem poucos desenvolvedores Ruby?
Há menos gente escrevendo Ruby que Python ou JavaScript, e a objeção pesa menos do que parece. Primeiro porque o mercado que importa não é o global, é o de quem você consegue contratar e manter. Segundo porque, quando o framework já tomou as decisões de estrutura, o tempo até alguém experiente ficar produtivo num projeto que não escreveu é curto, o que ataca justamente o custo da rotatividade.
Ruby on Rails escala?
GitHub, Shopify e Basecamp rodam em Rails há mais de uma década, em volume que não tem nada de estágio inicial. O que isso mostra não é a marca das empresas: é que produtividade alta e capacidade de escalar não são coisas que se trocam uma pela outra. Gargalo de aplicação web quase nunca é a linguagem, e sim consulta mal escrita, falta de cache e trabalho pesado feito na hora.
Por que a Northern usa Ruby on Rails?
Porque o que limita produto digital novo quase nunca é a velocidade da máquina, e quase sempre é quanto tempo leva para uma decisão virar algo funcionando na tela. Isso aparece em duas coisas que o cliente sente: o prazo até existir algo que dá para usar e criticar em vez de slide, e o custo de mudar de ideia depois da primeira versão, que é quando quase todo produto descobre que precisa mudar.
