O que é Rails: gems, Gemfile e convenção sobre configuração

Rails é um framework web em Ruby construído em torno de um princípio: convenção sobre configuração. Em vez de você decidir e configurar onde cada arquivo mora, como uma tabela se chama, qual método um controller deveria ter pra criar um recurso — Rails já decidiu, e segue essa decisão em todo projeto Rails do mundo. Isso tem um preço (menos flexibilidade) e um ganho enorme (qualquer pessoa que já viu um projeto Rails sabe onde procurar coisa em outro projeto Rails, sem ler configuração nenhuma).

Antes de tudo: o que é uma "gem" e como um projeto Rails nasce

Ruby chama uma biblioteca instalável de gem — o mesmo conceito de um pacote npm no mundo JavaScript. O próprio Rails é distribuído como gem: instalar Rails na máquina é, literalmente, instalar mais uma biblioteca Ruby.

gem install rails
rails new minha_api --api

rails new minha_api --api não cria uma pasta vazia — ele gera a estrutura inteira de pastas da seção seguinte, já com um Gemfile populado. --api pede a variante enxuta pra API (sem as partes de gerar HTML no servidor, que uma API não usa).

Gemfile e bundler: como as dependências do projeto são geridas

Todo projeto Rails tem um arquivo Gemfile na raiz — é a lista de todas as gems (bibliotecas) que o projeto depende, mais ou menos como um package.json lista as dependências de um projeto Node/Next.js.

gem "rails", "~> 7.1.3"
gem "pg", "~> 1.5"          # driver do Postgres
gem "puma"                  # servidor de aplicação

group :development, :test do
  gem "rspec-rails"          # só instalado em dev/test, nunca em produção
end

Depois de editar o Gemfile — seja criando o projeto do zero, seja adicionando uma gem nova mais pra frente (nas próximas lições você vai adicionar devise e cancancan assim) — você roda bundle install. O Bundler lê o Gemfile, resolve qual versão exata de cada gem (e de cada dependência delas) instalar sem conflitar entre si, baixa tudo, e escreve o resultado em Gemfile.lock.

bundle install

O Gemfile.lock é o que faz o projeto instalar exatamente as mesmas versões na sua máquina, na do seu colega e no servidor de produção — sem ele, cada instalação poderia puxar uma versão diferente de cada gem e um bug "só acontecer" num lugar. Por isso ele é versionado no git, e oGemfile sozinho nunca é o suficiente pra reproduzir o ambiente.

A convenção que mais aparece: nome no plural/singular

Model:      Produto        (classe, singular, PascalCase)
Tabela:     produtos       (banco, plural, snake_case)
Controller: ProdutosController (plural)
Rota:       /produtos      (plural)

Você não escreve essa relação em lugar nenhum — Rails deduz a tabela a partir do nome do model automaticamente. Isso só quebra se você tentar nomear algo fora do padrão, e nesse caso você teria que configurar manualmente o que, no caminho convencional, é automático.

A estrutura de pastas também é convenção

app/
  models/          → regra de negócio + acesso a dado (ActiveRecord)
  controllers/      → recebe requisição HTTP, decide o que fazer
  serializers/       → formata o model em JSON pra resposta da API
  services/          → lógica que não cabe num model nem controller sozinho
config/
  routes.rb          → mapeia URL + verbo HTTP → controller#action
db/
  migrate/           → histórico versionado de mudanças no schema do banco

Compare com o Next.js: lá, pasta define rota; aqui, pasta define papel (model, controller, service...) e um arquivo separado (routes.rb) mapeia URL pra controller. São filosofias diferentes de organização, e as próximas lições mostram cada uma dessas pastas na prática.