Temos uma grande aplicação Ruby on Rails (25 milhões de usuários mensais), nossa gerência decidiu reescrever no Node.js, estou louco?

Por favor me diga se:

O Node.js tornará nosso site mais rápido!
O Node.js consumirá menos recursos do servidor, podemos economizar dinheiro!
O Node.js nos tornará mais produtivos!
Node.js significa que podemos compartilhar o código JavaScript do lado do cliente e do servidor.

Para esclarecer, estamos reescrevendo um servidor front-end, que conversará com nosso aplicativo Ruby on Rails existente como uma API. Enquanto isso, refatoraremos nosso aplicativo Ruby on Rails em serviços.

Mais detalhes sobre a arquitetura existente:

Memcached para cache de parciais HTML
Redis para sessão e alguns cache de dados estruturados
Mestre único MySQL , múltiplos escravos
- Há uma tabela grande que aceita muitas gravações (imagine uma pesquisa)
- Caso contrário, principalmente lê.
MongoDB para alguns metadados
Ruby on Rails 3.0
nginx e unicórnio

— user88487
fonte

sheesh, todas essas línguas hipster. Um aplicativo php bem escrito será escalado facilmente, as ferramentas tradicionais funcionam, não deixe que esses descolados lhe digam o contrário.

— quer

A questão deve ser mais parecida com "As melhorias economizarão dinheiro suficiente para a empresa fazer valer a pena?" Pode poupar dinheiro ao longo de 5 anos, mas reescrevendo é caro e demorado - a menos que o seu código é uma bagunça horrível horrível que eu acho que os seus gestores estão sendo louco

— Mikey C

Se as reescritas estiverem sendo consideradas, você também pode considerar mover seu front-end para o javascript do lado do cliente, o que significa que você não terá mais um servidor front-end dinâmico, apenas arquivos estáticos.

— Joeri Sebrechts

A @Darknight tenha em mente que em um ponto o PHP era a linguagem hipster, e que as pessoas que o mostravam poderiam ser implantadas em produtos de sucesso promoveram sua adoção - enquanto os desenvolvedores da Web Perl estavam rindo dos descolados do PHP.

Estou muito surpreso que ninguém tenha mencionado o artigo de Joel Spolsky. Coisas que você nunca deve fazer . Não estou dizendo que todas as reescritas são ruins, mas concordo com o @MikeyC que elas devem ser abordadas com extrema cautela.

— Dan Pichelman

Respostas:

A maioria das perguntas que você faz não é respondida sem contexto e é mais ou menos discutível, já que a gerência já fez a sua escolha ... a menos que você esteja perguntando 'devo parar e encontrar um novo emprego diante de todas essas mudanças? ?

Se você for difícil, recomendo que você leia este post sobre o tema: Como sobreviver a uma reescrita de baixo para cima sem perder a sanidade .

Recentemente, iniciei o processo de reescrever um pouco da lógica do servidor no node.js. O principal motivo foi que ele está atualmente escrito em .NET e queremos migrar para longe dos ambientes MS no caminho.

Minhas experiências até agora foram positivas, você terá uma curva de aprendizado inicial com todo o seu não-bloqueio, mas depois que você passar, é realmente divertido codificar .. Eu sei, DIVERTIDO!

Porém, ele tem um lado sombrio: todo homem e seu cachorro que fizeram algum desenvolvimento front-end com JavaScript - e isso seria todo desenvolvedor de front-end, espero - fica um pouco animado quando você menciona que o node.js é 'javascript do lado do servidor 'no entanto, isso não significa que os desenvolvedores de front-end terão a experiência necessária para escrever bons aplicativos do lado do servidor.

Por um lado, você considerou que um erro fatal derrubará todo o aplicativo devido à sua natureza não encadeada, então as apostas são um pouco maiores e você deve verificar e capturar tudo explicitamente.

Para aqueles que fizeram o front e o back - e desfrutam de ambos - não ter que alternar contextos mentais dos idiomas front-end para back-end é um bônus real que, em última análise, aumentará a produtividade de nossa equipe.

— dave.zap
fonte

"Por um lado, você considerou que um erro fatal derrubará todo o aplicativo devido à sua natureza não encadeada, então as apostas são um pouco maiores e você deve verificar e capturar tudo explicitamente" - Essa seria minha preocupação.

— tentimes

Sim, meu ponto principal com essa afirmação foi que apenas os desenvolvedores de front-end geralmente não são particularmente exigentes quando se trata de manipulação de exceções. Vamos lá, já é quase 2017!

— Dave.zap

Bem, não acho que reescrever o aplicativo tenha sido uma boa ideia, a menos que tenha um desempenho ruim. Para responder suas perguntas:

Node.js não é mágico. Seu aplicativo tem uma quantidade enorme de usuários, portanto não há como ter certeza de que o tornará mais rápido.
Bem, sim, o Node.js de fato consome menos recursos do servidor. Portanto, não apenas você pode economizar dinheiro em recursos, mas também pode fazer mais com os existentes. Isso ocorre principalmente devido à natureza de thread único do Node.js. Não há sobrecarga de threads adicionais.
Novamente Node.js não é mágico. Dito isto, pode haver alguma verdade nisso. O Node.js possui uma comunidade muito ativa que criou centenas de módulos para todas as tarefas possíveis. Portanto, é bastante provável que a maior parte do trabalho tenha sido feita para você. Você só precisa encaixar as peças.
Teoricamente, sim. Como o Node.js é JavaScript, você pode compartilhar o código entre o cliente e o servidor. Mas não sei exatamente o que será compartilhado. Não escrevi nenhum código reutilizável em um cliente. O que fazemos no servidor geralmente não tem nada a ver com o cliente. Mais importante para mim é a falta de mudança de contexto. Acho mais fácil codificar no cliente e no servidor em um único idioma.

Como o Node.js é de thread único, a menos que seja explicitamente configurado para isso, ele não pode tirar proveito de várias CPUs .

Dê uma olhada nos comentários também. Eles fornecem algumas boas informações sobre o funcionamento do Node.js.

— Akshat Jiwan Sharma
fonte

Menos recursos por causa de um único encadeamento? O que você acha que esses segmentos extras estariam fazendo?

— 21413 Joe

@Joe, tanto quanto eu entendo, eles serão adicionados.No nó js, é uma prática recomendada descartar uma solicitação o mais rápido possível.Para concluir de uma só vez ou retomar na próxima vez.Para ser honesto, nó js é a única tecnologia para a qual desenvolvi aplicativos de produção.Por isso, talvez não seja a melhor pessoa para compará-la com outras tecnologias do lado do servidor.Por isso, evitei fazer comparações e coloque apenas o que acho que sei sobre o nó js em minha resposta.

— Akshat Jiwan Sharma

Sim, um único encadeamento certamente limita o uso de recursos, porque o servidor pode fazer apenas uma coisa ao mesmo tempo no loop de eventos. Também limita o uso do servidor, porque só pode fazer uma coisa de uma vez. É muito importante citar recursos (thread único) e vantagens e desvantagens, em vez de apenas vantagens. O Node.js é adequado para alguns usos, mas é uma má idéia para outros. Quando o servidor do nó de thread único tiver problemas de capacidade, talvez seja necessário adicionar outra instância do nó. Agora você tem um servidor com vários processos.

— 21413 Joe

Eu vejo o que você mean.I irá atualizar a resposta em breve (leia após alguma pesquisa)

— Akshat Jiwan Sharma

Não se trata apenas de CPUs. O motivo pelo qual é importante lidar com todas as solicitações o mais rápido possível (em um sistema de thread único sem nenhuma outra simultaneidade) é porque o servidor não pode atender a várias solicitações ao mesmo tempo, portanto, toda solicitação precisa aguardar até que você termine de lidar com todas as solicitações. os pedidos antes dele. Concorrência, feita corretamente, significa menos espera. O uso de encadeamentos não é inerentemente um problema de desempenho, e o encadeamento único (por padrão ou não) não é uma vantagem de desempenho.

— Peter Hosey