Bastidores: por que escolhemos Rails e Hotwire para os nossos produtos

Toda escolha de tecnologia é uma escolha de trade-off. Quando decidimos a stack para os produtos da Destrava, o critério não foi "o que está em alta", foi "o que nos deixa entregar um produto completo — agenda, cadastro, painel, notificação — sem multiplicar a complexidade do time".

Um back-end e um front-end que conversam sem fricção

Rails continua sendo uma escolha sólida para isso: convenções bem estabelecidas, um ORM maduro e um ecossistema que cobre autenticação, jobs em background e geração de relatórios sem exigir que a gente reinvente essas peças a cada novo produto.

O Hotwire (Turbo + Stimulus) entra para resolver a parte de interface reativa sem exigir uma API separada e um front-end em outro framework. Agenda que atualiza sozinha, formulário que valida sem recarregar a página, painel de fila em tempo real — tudo isso com uma fração do código que uma arquitetura com API REST completa e SPA exigiria.

Onde isso aparece nos produtos

Essa escolha está presente nos três produtos que já construímos:

• Na Barbearia, a agenda e o painel financeiro atualizam em tempo real sem recarregar a página.
• Nas Clínicas, o prontuário e a agenda multi-profissional se beneficiam de uma base sólida de autorização e multi-tenancy.
• No GFila, o painel de fila em tempo real depende diretamente da capacidade do Hotwire de atualizar a tela conforme o estado muda no servidor.

O ganho real

O resultado prático é um ciclo de desenvolvimento mais curto entre "identificamos o problema do cliente" e "o cliente está usando a solução em produção" — que é, no fim, o que importa para quem está esperando o sistema resolver um problema real do negócio.