Rails e Next.js: a combinação perfeita para o desenvolvimento web moderno — Parte 2
Na primeira parte dessa sequência de posts, eu dei um apanhado geral, em formato de metáfora, sobre o que me levou a não utilizar o Ruby on Rails como a única ferramenta de desenvolvimento.
Continuando a série de posts, fico feliz em ver que alguns leitores estão curiosos e me perguntam sobre o que me motivou a seguir essa estrutura de desenvolvimento. Então agora, gostaria de aproveitar a oportunidade e responder algumas delas:
O que tem a ver o Next.js com o React.js?
Alguns leitores me questionaram sobre o uso de Next.js e onde entra o React na história. Por isso, vou listar alguns pontos interessantes:
- Next.js é um framework Javascript que utilizar componentes React para renderizar interfaces web.
- Você não precisa de Rails para desenvolver aplicações com o Next.js e vice-versa.
- Next.js é um framework full-stack, mas existem alternativas mais completas como o Nest.js. No Nest você vai encontrar uma gama maior de ferramentas para o desenvolvimento web. Tais como MVC, ORM, Security, Websocket, etc.
- Eu optei pelo Next.js pois eu só preciso da parte de geração de SPA que ele oferece. Em nenhum momento eu utilizo a parte do Next.js que roda do lado do servidor depois de buildar a aplicação. O que vai pro diretório public do Ruby on Rails, são apenas arquivos Javascript e HTML que rodam do lado do cliente.
Você precisa de um framework Javascript para desenvolver até as aplicações mais simples?
A resposta curta é: não. Mas estamos aqui para entrar em detalhes, certo? Então vamos nos aprofundar um pouco mais.
Hoje uma das principais linguagens para desenvolvimento web é o Javascript.
Não dá pra ignorar que se você busca criar ou manter um sistema web, você vai precisar ter acesso a uma comunidade ativa e facilidade em contratar pessoas especializadas. Dessa forma, escolher uma linguagem como o Javascript pode ser uma boa estratégia.
Assim sendo, eu posso dizer que tendo uma diversidade de tecnologias aplicadas ao seu projeto e utilizar tecnologias que estão entre as top do mercado, você tem uma boa razão por utilizar Ruby on Rails com algum outro framework Javascript.
Além da diversificação de tecnologias, como eu disse no meu post anterior, eu escolhi o React para que eu tivesse a parte de componentização da melhor forma que eu encontrei até o momento. Eu optei por remover a camada de View do Ruby on Rails (ERB, HAML, Slim, Liquid, etc.) e substituí-la pelo Next.js.
Apesar de parecer uma mudança drástica, na verdade se em seu projeto Rails você optou por utilizar React, eu posso te dizer que essa é a forma melhor e mais simples possível.
Outro ponto a se considerar é que não dá pra ter um padrão de desenvolvimento para cada projeto dentro de um mesmo ecossistema. Não estou falando que se um sistema só tem HTML eu tenha que inserir o Next.js na aplicação Rails. Mas se seu sistema possui a necessidade de algum componente dinâmico (uma tabela com AJAX por exemplo), porque não criar (ou importar) esse component com React e compartilhar a mesma alternativa em todos seus projetos? Ao contrário disso, você terá trabalho dobrado para manter dois componentes que fazem a mesma coisa.
Porque não utilizar Hotwire ao invés de React?
Depois de tudo que escrevi no meu primeiro post e na resposta da perguntar anterior, eu acho que não resta muito a se adicionar aqui. Mas caso tenha restado alguma dúvida, vou listar alguns pontos importantes:
- A melhor forma de se componentizar uma aplicação Ruby on Rails é o https://viewcomponent.org/. View Component é uma excelente biblioteca, mas no fim o React se mostrou mais completo.
- Hotwire é algo muito específico do Ruby on Rails e tenho receio de limitar o desenvolvimento do meu projeto com algo que não seja conhecido por uma grande gama de desenvolvedores.
- Hotwire utiliza https://stimulus.hotwired.dev/. Como o próprio site do Stimulus diz, ele é um framework Javascript modesto, ou seja, ele não vai entrar muito além do básico. Eu optaria pelo https://alpinejs.dev/ se eu tivesse interesse em trabalhar gerenciando HTML seguindo uma abordagem parecida mas com mais recursos.
Porque não utilizar https://alpinejs.dev/ ou https://svelte.dev/?
Confesso que ninguém me fez essa pergunta, mas eu mesmo cheguei a pensar que algum framework que, ao invés de apenas gerar HTML, ele também conseguisse trabalhar com o HTML gerado pelo backend. Alpine e Svelte poderiam ser uma alternativa simples e melhor que integrar Next.js ao projeto Rails.
Mas no fim, os mesmo pontos listados como resposta da pergunta ‘Porque não utilizar Hotwire ao invés de React?’, também podem ser considerados aqui.
Como fica o Server-Side Rendering (SSR)?
Esse é um ponto que eu ainda não tenho uma resposta concreta, mas o que eu posso dizer até o momento é que caso eu precise de um SSR, eu optaria por manter o uso do Next.js, mas em um projeto separado executando a aplicação em um servidor Node. Tal como eu descrevi em um outro post com o título ‘Consuming a Rails API with a NextJs client’.
Se eu fosse você trocaria o Ruby on Rails por uma alternativa completa em Javascript.
No meu post anterior eu acredito ter descrito bem minha motivação de não fazer isso. Mas eu confesso que eu demorei alguns anos para que a resposta para essa pergunta ficasse clara o suficiente e possível de se dizer em poucas palavras:
“Eu não vou trocar mais de 10 anos de experiência com Ruby on Rails apenas para ter acesso a uma View melhor.”
De nenhuma forma eu vejo que o Ruby on Rails é inferior perante as alternativas Javascript e eu tenho a certeza que ele me oferece tudo que eu preciso para desenvolver uma API bem estruturada, organizada, segura, estável e escalável.
Isso quer dizer que eu vou manter minha API em uma aplicação Ruby on Rails e toda a parte do frontend vai ficar por conta do Next.js.
No próximo e último post dessa sequência, eu vou detalhar tecnicamente como eu integrei o Rails com Next. Você já pode ir dando uma olhada no código aqui https://github.com/raphox/rails-next/commits/main.