Existe um bom motivo para evitar o node.js para aplicativos da web não em tempo real?

29

Eu já falei bastante sobre o quão incrível o Node.js é para aplicativos da web em tempo real - coisas que precisam de soquetes, Comet, comunicações pesadas em AJAX e assim por diante. Sei que seu modelo assíncrono e orientado a eventos também é bom para simultaneidade com baixa sobrecarga.

Também vi tutoriais do Node.js. para aplicativos mais simples, "tradicionais" e não em tempo real (por exemplo, o exemplo padrão do blog, que parece ser o "Olá Mundo" padrão para as pessoas que aprendem o desenvolvimento de aplicativos). E também sei que o node-static permite que você sirva ativos estáticos.

Minha pergunta é: existe algum bom motivo para evitar o Node.js para aplicativos da Web tradicionais, como classificados, fóruns, o exemplo de blog acima mencionado ou o tipo de aplicativos CRUD que você cria para aplicativos de negócios internos? Só porque se destaca em todas as coisas descoladas e em tempo real, isso é contra-indicado para usos mais difíceis?

A única coisa que consigo pensar, fora do bastão, é a falta de bibliotecas maduras (embora isso esteja mudando).

(A razão pela qual estou perguntando é que estou pensando em abandonar o PHP no Node.js, principalmente para superar a incompatibilidade de impedância de alternar entre idiomas, mas também para reutilizar o código de validação e outros enfeites. Meu superego me aconselha a escolher o melhor ferramenta para o trabalho ; no entanto, não tenho muito tempo para aprender quinze idiomas e todas as suas bibliotecas de países de usuários apenas para ter um arsenal abrangente.É também tranquilizador que o Node.js possa me proporcionar um caminho de otimização mais fácil do que o PHP / Apache no futuro, quando tiver que começar a pensar em tráfego pesado.)

[EDIT] Obrigado pelas respostas até agora, pessoal; Eu só quero ver se mais alguém vai pesar antes que eu escolha uma resposta. A resposta de @Raynos meio que confirma o que estou pensando, e os links dos comentaristas forneceram boa reflexão, mas quero ver se mais alguém tem alguma resposta específica para o nó, como 'NÃO USE NÓ PARA PROBLEMA X ' (Além das tarefas de alta CPU; eu já sei disso :-)

Paul d'Aoust
fonte
1
@ default.kramer: Obrigado pelo link, eu realmente gostei!
Zach
1
Uau! Um sujeito bastante opinativo, não é? No artigo de acompanhamento, ele parece estar dizendo que, para aplicativos de alta E / S e baixa CPU, os sistemas de eventos e encadeados estão aproximadamente no mesmo nível, e que o problema está nos programadores iniciantes que não sabem quando desistir de eventos e gerar um novo tópico. Mas a ignorância do programador não significa que a ferramenta é ruim, não é? Concordo que o uso de um ambiente cujo forte são os loops de eventos para tarefas intensivas em CPU é um pouco estranho, mas é ruim?
Paul d'Aoust 2/11/11
1
Seu ódio ao JavaScript também parece ser uma questão importante, que eu receio ser parcialmente responsável pela energia por trás de seu argumento.
Paul d'Aoust 2/11/11
@ Paul - Você provavelmente deve tomá-lo com um grão de sal. Eu não sei muito sobre o Node.js; Eu apenas pensei que era engraçado. (como a maioria de seus escritos)
default.kramer
@ default.kramer obrigado pelo lembrete; Eu tendo a opinião das pessoas como evangelho. Sua principal crítica válida parece ser que você não deve usar o Node.js. para tarefas com uso intenso de CPU. Estou confuso sobre suas críticas aos processos do trabalhador; existe algum grande problema com a criação de trabalhadores separados para tarefas específicas?
Paul d'Aoust 2/11/11

Respostas:

13

existe algum bom motivo para evitar o Node.js para aplicativos da web tradicionais

Sim, se você tiver N anos na plataforma da Web X, claramente poderá desenvolver um aplicativo na plataforma X mais rapidamente.

Se você deseja fazer Y e a plataforma X possui uma solução pré-fabricada Y que faz X, faça-o.

Todos os motivos genéricos de por que você deve usar uma plataforma sobre outra.

o tipo de aplicativos CRUD que você cria para aplicativos de negócios internos?

Sim, existem outras plataformas que permitem que você escreva um aplicativo genérico mais rapidamente, e vem à mente o Ruby on Rails.

No entanto, dito isso. Tenho experiência com o nó e não posso afirmar que escolheria outra plataforma sobre o nó, a menos que ele faça uma enorme quantidade de recursos prontos para uso.

Basicamente, é uma simples questão de

Existe uma ferramenta que faz tudo isso para mim? Não, escolha a plataforma mais conveniente para escrever a ferramenta.

Não há razões sólidas para o node.js. ser uma plataforma inconveniente (exceto "odeio javascript")

Raynos
fonte
Então você acha que princípios pragmáticos como familiaridade, disponibilidade de bibliotecas etc. são fortes argumentos para uma certa plataforma, não é? Esses são bons pensamentos, e são definitivamente coisas que estou considerando. (Estou surpreso que você está defendendo soluções out-of-the-box, eu pensei que você fosse um roll-seu-próprio tipo de cara!)
Paul d'Aoust
@ Pauld'Aoust Eu sou um tipo de cara do tipo faça você mesmo. No entanto, não faço nada e não tenho prazos.
Raynos
heh, obrigado pela ressalva. Lembro-me dos seus comentários no node.js conversando sobre o uso de bibliotecas de modelos de outras pessoas (Backbone.js, etc) e percebendo que eu estava gastando muito tempo aprendendo o Backbone.js e não tendo tempo suficiente apenas aproveitando (e aprendendo) o JavaScript mecanismo de herança prototípica. Bom conselho; Eu me sinto muito mais relaxado agora.
Paul d'Aoust 2/11/11
4
-1 vaga. 1) Só porque você tem N anos de experiência em X - não significa que você deve evitar o Node.JS. Você está propondo ignorância deliberada com base na experiência? E quais são as "razões genéricas"? 2) 'outros aplicativos que permitem escrever um aplicativo genérico mais rapidamente' - é puramente subjetivo. 3) 'outro * de "* Eu odeio * JavaScript' - também é subjetiva e não uma razão válida para evitar uma tecnologia florescente * ortografia..
Jack Stone
@ClintNash, alguns de seus motivos não são diferentes dos dele. "Recursos humanos" vs "N anos de experiência" são exatamente os mesmos. "O NodeJS não é tão maduro quanto as estruturas tradicionais" vs "Sim, existem outras plataformas que permitem que você escreva um aplicativo genérico mais rapidamente, e vem à mente o Ruby on Rails." também são os mesmos. Não são apenas os mesmos, mas os seus não são mais mensuráveis ​​(objetivos) que os dele.
Aaaaaa
6

Depois de trabalhar com o nó por algumas semanas, eu diria que sim, é muito legal. Mas não necessariamente algo que você gostaria de usar para substituir seus aplicativos da web comuns por ... nem, na verdade, ele pretende ser.

Lembre-se, o nó é seu próprio servidor. Isso apresenta complexidades se você deseja executar mais do que apenas o seu aplicativo node.js. ou seja, se você tiver mais de um site / domínio hospedado em uma máquina. Não é como uma pilha LAMP, onde você pode ter uma dúzia de aplicativos PHP para meia dúzia de domínios diferentes executando no mesmo servidor (na porta 80, pelo menos). Existem estruturas para o nó que provavelmente tornam isso possível, mas isso adiciona complexidade que você simplesmente não precisa se estiver preso às plataformas da web tradicionais. (Obviamente, você também pode configurar proxies colocando um servidor da Web na frente do nó, mas isso acaba com o benefício do uso do nó).

O Node é perfeito para trabalhar em conjunto com um servidor Web tradicional. A maneira como eu tenho as coisas organizadas agora é servir o html / js / images estáticos via apache e lidar com as necessidades de dados em 'tempo real' pesquisando longamente o aplicativo do nó.

GrandmasterB
fonte
Vale a pena considerar a facilidade de uso +1 na configuração de vários hosts.
Paul d'Aoust 27/08/2012
É muito simples colocar os aplicativos de nó atrás de um servidor Apache httpd ou nginx e encaminhar solicitações com a assinatura URI desse aplicativo para a porta (ou portas) do nó.
TomG
+1 - a noção de node.js como proxy do lado do servidor ('em conjunto com o servidor da Web tradicional') ganhou força no início deste ano e vale a pena analisar - especialmente se você tiver uma arquitetura tradicional grande para gerenciar. É um padrão de design que parece fazer sentido para a empresa. Mas, vale a pena notar - esse não é um motivo para EVITAR o Node.js, mas um motivo para usá-lo para fins específicos.
Jack Stone
4
-1 - Colocar um proxy (como nginx) na frente do nó é um caso de uso perfeito e é realmente muito mais seguro e com desempenho em alguns casos do que não ter um. Não anula nenhum benefício do nó. Costumo executar meus aplicativos de nó em soquetes de domínio unix e fazer com que o nginx atue como um gatekeeper.
Scott Anderson
3

Um bom motivo para ter segundos pensamentos sobre o nó não é técnico - é ótimo e surpreendente no que faz.

São negócios e, especificamente, capital humano, ou seja, programadores que sabem disso, quanto custam e sua disponibilidade. Não é tão difícil de aprender, mas, como em qualquer tecnologia mais recente, o número de pessoas que a conhecem bem (ou desejam) é um subestino dos grupos de trabalhadores maiores.

Michael Durrant
fonte
então você acha que não há realmente nada contra usar o Node no lugar de pilhas de aplicativos mais tradicionais; as questões estão mais relacionadas às preocupações do mundo real?
Paul d'Aoust 27/08/2012
+1. Recursos humanos - e a falta de vontade de alguns em aprender JavaScript - é uma verdade inconveniente. Esta resposta afirma bem. Porém, evitar o Node "porque as pessoas odeiam JavaScript" também não é a progressão lógica. Onde estaríamos tecnicamente se evitássemos todas as inovações que alguém odiava? Lugar algum. O desafio do nó é A) Obter novos talentos, ou B) Educar talentos tradicionais em novos talentos. Até esse ponto - estamos vendo escolas de código JavaScript surgirem em todos os lugares desde a previsão de John Resig na fundação da Khan Academy. Em suma, este é o caminho das coisas. +1. Bem afirmado.
Jack Stone
3

Esta é uma pergunta muito boa, que devemos perguntar, para avançar muito o estado da arte.

Fiquei muito curioso para saber (como Paul d'Aoust) onde existem as limitações do Node.JS. Infelizmente, muitas respostas estão cheias de viés subjetivo e lógica temporariamente relevante.

Perguntei-me: PODEMOS FILTRAR BASES SUBJETIVAS E RECOMENDAR PARA RESPOSTAS SÓLIDAS A ESTA PERGUNTA RELEVANTE?

Os pontos restantes parecem ser:

1. O NodeJS não é tão maduro quanto os Frameworks Tradicionais. Como Paul d'Aoust sugere, esse é apenas um motivo temporariamente relevante, não para evitar completamente - mas, ao contrário, revisar e diligenciar. Espera-se fazer o dever de casa como profissionais da web, e é nosso trabalho determinar o melhor ajuste da tecnologia para a organização, suas necessidades, seu futuro, a equipe (e não nós). A maturidade é uma necessidade de esclarecimento e um julgamento por apetite por risco, mas não por evitação.

2. NodeJS como um servidor proxy. Uma sugestão sábia, de discussão prévia, que vale a pena revisar e considerar. É a noção de usar o Nó em correlação com as tecnologias existentes como um padrão de design de proxy da interface front-end. Mas também não é um motivo para EVITAR o uso do nó, mas um motivo para evitar usá-lo como um substituto completo. Em vez disso, optar por uma abordagem corolária.

3. Nó de depuração. Em conversa com os desenvolvedores principais do Nó na Joyent, há muitas complicações relacionadas à depuração e ao rastreamento da causa raiz dos problemas resultantes do núcleo (com base na execução de um único encadeamento e na incapacidade de ver os encadeamentos anteriores). Vale a pena considerar e avaliar - mas (novamente) provavelmente não há aversão ao uso comum apenas em casos extremos que podem forçar o envelope. Talvez suas necessidades específicas se enquadram nessa categoria e talvez não.

4. Recursos humanos. Esta é a melhor razão para EVITAR o uso do JS nesta página e, na minha humilde opinião, é uma verdade gritante e inconveniente. Ele levanta a questão: sua empresa possui os profissionais talentosos certos para assistir ao projeto por todo o ciclo de vida? Caso contrário, não há dúvida de que você precisa evitar o NodeJS. Ou então considere A) localizar o talento correto ou B) Educar o talento existente.

Reclamações: Minha observação das reclamações sobre JavaScript é que muitas resultam mais de erro do usuário do que de falhas consistentes da linguagem. Desmistificamos muitas reivindicações contra "The Hate JavaScript Diatribe" e continuaremos a desmascarar muitas outras. Problemas como - a documentação não é boa o suficiente, não é sexy o suficiente, mas as pessoas não gostam, é câncer, é o diabo, ou é muito "propenso a erros de digitação" (-CRichardson), são subjetivos e reclamações tendenciosas que precisam ser eliminadas para a tomada precisa de decisões corporativas.

No final, a resposta correta pode ser - não há boas razões para EVITAR o NodeJS . Talvez seja por isso que ele esteja experimentando um rápido crescimento, adoção e contribuição. Mas, para todos nós, talvez a resposta aqui seja continuar a avaliar, pesquisar e entender melhor o NodeJS - e procurar aversões concretas. Na busca de estar aberto a entender exatamente onde o Node.JS é imaturo - encontramos exatamente onde precisamos torná-lo melhor. E isso é uma benção.

Boa pergunta. Eu, pelo menos permaneço curioso para que alguém traga uma razão melhor para evitar o NodeJS - do que esses.

Jack Stone
fonte
-1

Existe algum benefício em usar o nó sobre X para aplicativos não em tempo real:

  • Escalonamento : o nó tem bom desempenho, mas outras plataformas também; PHP, Ruby, Python e Java são escaláveis. Você pode encontrar grandes nomes com milhões de usuários que os estão usando.
  • Um idioma para front-end e back - end : é uma piada, assim como o "Write Once Run Anywhere" de Java
  • Gostosa e sexy : o único ponto válido. Mas ninguém liga para o fato de seu site estar usando tecnologia ousada!

Benefício do uso do X sobre Nó para aplicativos não em tempo real:

  • Prática recomendada : como o Node é novo, ele possui menos práticas recomendadas do que outras plataformas, especialmente para aplicativos da web CRUD.
  • Linguagem Javascript : as pessoas não gostam de Javascript. Enquanto o Node.js estiver quente, o Javascript não está. É por isso que as pessoas criaram o Coffeescript para evitar escrever Javascript, mesmo para o cliente.
  • Velocidade de desenvolvimento : As estruturas antigas e chatas, incluindo e não se limitando ao Rails e Django, são bem testadas e aprimoradas ao longo de muitos anos para sites CRUD. Embora você possa implementar aplicativos semelhantes no Node, é mais fácil fazer isso na estrutura do seu avô.
  • Estabilidade : as estruturas da web do Node estão melhorando em um ritmo mais rápido. Isso significa que eles estão mudando e terão mais incompatibilidade de API em um futuro próximo.
  • Bibliotecas e ferramentas : as tecnologias mais antigas com mais usuários têm mais bibliotecas e ferramentas.

Minha resposta definitivamente não será válida em 2015. Em 2014, pule o Node para aplicativos da Web não em tempo real, mas fique de olho nele.

Toda estrutura da web tem um ponto forte. Você ficará feliz enquanto estiver usando esse ponto. Aplicativos da web não em tempo real não são o ponto forte das estruturas da web do Node.

Hossein
fonte
2
-1. Eu concordo que esta resposta não será válida em 2015. Mas isso também é motivo de voto negativo. Em essência - as decisões de hoje SÃO as decisões de amanhã. Ele anula os 8 pontos acima - se pudermos ver que eles são apenas temporariamente relevantes. 1) Escala - Escalas do Walmart Mobile, não é um motivo para evitar o Nó. 2) JS isomórfico não é brincadeira. Não é um motivo. 3) Server Sexyness? A maioria dos usuários conhece apenas ux. 4) A melhor prática é subjetiva, 5) Não é quente? -subjetivo 6) Mais fácil? -subjetivo. 7) A estabilidade é um ponto temporariamente relevante. 8) NPM projetado para passar Maven em 2014. Não há razões aqui. Voto negativo.
Jack Stone
-1

O Node.js é uma plataforma muito popular e possui muitos recursos interessantes blá blá blá, mas o uso de uma ferramenta é uma preferência pessoal. Eu dei quatro vezes ao Node.js e não fiquei feliz com isso. Aqui estão as minhas razões. Lembre-se de que alguns desses motivos estão desatualizados ou simplesmente pessoais: P

  • Eu preferia uma linguagem / sintaxe diferente (eu gosto de Python, Scala, minha linguagem favorita é o Prolog, então sim).
  • A qualidade da documentação para estruturas e bibliotecas que usei não é tão boa para bibliotecas Java, Scala, Python.
  • Os designers dos nodejs são obcecados por retornos de chamada em vez de modelo de evento, observador ou futuros.
  • Existem soluções prontas para o que eu quero fazer em Ruby, Python, Java desenvolvido em 2005, só preciso editar o arquivo de configuração.
David Sergey
fonte
2
-1 - pontos subjetivos. "Sintaxe preferida", "Documentação não tão boa", "Retornos de chamada obsessivos" e "Já concluído no meu idioma" - são todos vagos e subjetivos. Já ouvimos isso antes. Eles são desmascarados. Não há razão para evitar o Node.JS aqui. Voto negativo.
Jack Stone
1
Todos os pontos são minha preferência pessoal, que afirmei abertamente. Além disso, como você desmascara a preferência pessoal?
David Sergey
-9

O HTTP é sem estado, portanto, na verdade, não existe um aplicativo da Web que não seja em tempo real e, portanto, não há razão para que você não possa usar o nó para tudo.

Dito isto, o nó é mais adequado para um tipo específico de arquitetura de aplicativo. PHP são arquivos html que contêm um pouco de código. O nó é um código que contém opcionalmente um pouco de html.

Isso significa que, se seu aplicativo for formulários html padrão sem nenhum script do lado do cliente, o PHP será mais fácil. O Node possui ferramentas de modelagem, mas obviamente não é tão maduro quanto algo como PHP.

Se você tiver muitos scripts do lado do cliente e salvar os dados com o ajax, terá uma função estática de chamada de cliente html no servidor. É exatamente nisso que o nó é bom. Embora não seja o modo como os aplicativos CRUD geralmente são criados, você pode produzir algo muito bom com a estrutura certa.

Tom Clarkson
fonte
Considerações sobre o HTTP ser apátrida e em tempo real; no entanto, estou mais interessado nas preocupações pragmáticas sobre a definição típica de tempo real: grandes volumes de solicitações de baixo peso. Parece um pouco exagerado criar uma nova instância do PHP apenas para exibir três ou quatro linhas de JSON às vezes. Estou correto ou estou apenas sofrendo de síndrome do papagaio?
Paul d'Aoust 2/11/11
Se você não está carregando o PHP, está carregando o javascript e há vários tipos de cache envolvidos, portanto, a diferença não será suficiente. A grande diferença está no estilo de codificação e, portanto, na manutenção - ambas as plataformas podem gerar HTML ou JSON, mas o PHP foi projetado para pessoas acostumadas a editar arquivos html estáticos, enquanto o nó foi projetado para pessoas acostumadas à programação javascript moderna.
Tom Clarkson
Eu sei que preciso carregar um intérprete algum tempo, mas vejo um benefício em ter uma instância do intérprete em execução o tempo todo (para aplicativos com pouca CPU, é claro) como no Node.js, em vez de os intérpretes girarem e finalize com cada solicitação, como no PHP.
Paul d'Aoust 4/11/11
Sim, e eu também esperaria que os js tivessem um melhor desempenho em um nível de solicitação individual, dada a quantidade de competição naquele espaço recentemente. No entanto, acho que essa é uma parte relativamente menor da diferença - com o nó, você tem controle direto e exatamente a quantidade de código necessária para atender à solicitação, enquanto qualquer sistema baseado em modelo que assume que você está servindo páginas adicionará sobrecarga e complexidade desnecessárias. outros cenários.
Tom Clarkson