javascript - website - Como decidir quando usar o Node.js?




website com node js (12)

  1. O Node é ótimo para protótipos rápidos, mas eu nunca o usaria novamente para nada complexo. Passei 20 anos desenvolvendo um relacionamento com um compilador e com certeza sinto falta disso.

  2. O nó é especialmente doloroso para manter o código que você não visitou por algum tempo. Informações de tipo e detecção de erro de tempo de compilação são boas coisas. Por que jogar tudo isso fora? Para quê? E, quando algo vai para o sul, a pilha fica completamente completamente inútil.

Eu sou novo nesse tipo de coisa, mas ultimamente eu tenho ouvido muito sobre como o Node.js é bom. Considerando o quanto eu amo trabalhar com jQuery e JavaScript em geral, não posso deixar de me perguntar como decidir quando usar o Node.js. A aplicação web que tenho em mente é algo como Bitly - pega algum conteúdo, arquiva.

De toda a lição de casa que tenho feito nos últimos dias, obtive as seguintes informações. Node.js

  • é uma ferramenta de linha de comando que pode ser executada como um servidor web comum e permite executar programas JavaScript
  • utiliza o ótimo motor V8 JavaScript
  • é muito bom quando você precisa fazer várias coisas ao mesmo tempo
  • é baseada em eventos, então todas as maravilhosas coisas semelhantes a Ajax podem ser feitas no lado do servidor
  • nos permite compartilhar código entre o navegador e o backend
  • nos permite falar com o MySQL

Algumas das fontes que me deparei são:

Considerando que o Node.js pode ser executado quase pronto para uso nas instâncias do Amazon EC2 , estou tentando entender que tipo de problemas exigem o Node.js, em oposição a qualquer um dos poderosos reis como PHP , Python e Ruby . Eu entendo que isso realmente depende da especialização que se tem em uma linguagem, mas minha pergunta se encaixa mais na categoria geral de: Quando usar uma estrutura particular e para que tipo de problemas ela é particularmente adequada?


Acredito que o Node.js é mais adequado para aplicativos em tempo real: jogos online, ferramentas de colaboração, salas de bate-papo ou qualquer coisa em que um usuário (ou robô? Ou sensor?) Faça com o aplicativo precisa ser visto por outros usuários imediatamente, sem uma atualização de página.

Eu também devo mencionar que o Socket.IO em combinação com o Node.js irá reduzir sua latência em tempo real ainda mais do que o que é possível com o polling longo. Socket.IO voltará a longo polling como um cenário de pior caso e, em vez disso, usar soquetes da Web ou até mesmo o Flash, se estiverem disponíveis.

Mas eu também devo mencionar que praticamente qualquer situação em que o código possa bloquear devido a threads pode ser melhor resolvido com o Node.js. Ou qualquer situação em que você precise que o aplicativo seja orientado por eventos.

Além disso, Ryan Dahl disse em uma palestra que eu compareci uma vez que os benchmarks do Node.js rivalizam muito com o Nginx para solicitações HTTP antigas regulares. Então, se construirmos com o Node.js, poderemos servir nossos recursos normais com bastante eficiência, e quando precisarmos do material orientado a eventos, ele estará pronto para lidar com isso.

Além disso, é tudo JavaScript o tempo todo. Lingua Franca na pilha inteira.


Eu tenho um exemplo do mundo real onde usei o Node.js. A empresa onde trabalho tem um cliente que queria ter um site HTML simples e estático. Este site é para vender um item usando o PayPal e o cliente também queria ter um contador que mostrasse a quantidade de itens vendidos. O cliente deverá ter uma quantidade enorme de visitantes para este site. Eu decidi fazer o contador usando o Node.js e o framework Express.js .

O aplicativo Node.js foi simples. Obtenha o valor de itens vendidos de um banco de dados Redis , aumente o contador quando o item for vendido e sirva o valor do contador para os usuários por meio da API .

Algumas razões pelas quais eu escolhi usar o Node.js neste caso

  1. É muito leve e rápido. Houve mais de 200.000 visitas neste site em três semanas e recursos mínimos do servidor conseguiram lidar com tudo isso.
  2. O contador é realmente fácil de fazer para ser em tempo real.
  3. O Node.js foi fácil de configurar.
  4. Existem muitos módulos disponíveis gratuitamente. Por exemplo, encontrei um módulo Node.js para o PayPal.

Neste caso, o Node.js foi uma escolha incrível.


Mais uma coisa que o nó fornece é a capacidade de criar vários instantes de v8 do nó usando o processo filho do nó ( childProcess.fork() cada um exigindo 10MB de memória como por documentos), sem afetar o processo principal executando o servidor. Portanto, descarregar um trabalho em segundo plano que requer uma enorme carga de servidor se torna uma brincadeira de criança e podemos matá-los facilmente quando necessário.

Eu tenho usado muito o node e, na maioria dos aplicativos que construímos, precisamos de conexões de servidor ao mesmo tempo, portanto, um tráfego de rede pesado. Frameworks como Express.js e o novo Koajs (que removeu o callback do inferno) tornaram o trabalho no nó ainda mais fácil.


Minha mais uma razão para escolher o Node.js para um novo projeto é:

Ser capaz de fazer desenvolvimento baseado em nuvem pura

Eu usei o Cloud9 IDE por um tempo e agora não posso imaginar sem ele, ele abrange todos os ciclos de vida de desenvolvimento. Tudo que você precisa é de um navegador e você pode codificar a qualquer momento em qualquer lugar em qualquer dispositivo. Você não precisa registrar o código em um computador (como em casa) e fazer o checkout em outro computador (como no local de trabalho).

É claro que talvez haja IDE baseado em nuvem para outros idiomas ou plataformas (o Cloud 9 IDE também está adicionando suporte para outros idiomas), mas usar o Cloud 9 para fazer o desenvolvimento do Node.js é realmente uma ótima experiência para mim.


Não há nada como Silver Bullet. Tudo vem com algum custo associado a ele. É como se você come comida oleosa, você vai comprometer sua saúde e comida saudável não vem com especiarias como alimentos oleosos. É uma escolha individual se eles querem saúde ou temperos como em sua comida. A mesma maneira que o Node.js considera ser usado em um cenário específico. Se o seu aplicativo não se encaixa nesse cenário, você não deve considerá-lo para o desenvolvimento do aplicativo. Estou apenas colocando meu pensamento da mesma forma:

Quando usar o Node.JS

  1. Se o seu código do lado do servidor requer muito poucos ciclos de cpu. Em outro mundo, você está fazendo uma operação sem bloqueio e não possui algoritmo / job pesado que consome muitos ciclos de CPU.
  2. Se você é de JavaScript back ground e confortável em escrever Single Threaded código apenas como o lado do cliente JS.

Quando não usar o Node.JS

  1. Sua solicitação do servidor depende do uso intenso de algoritmo / trabalho da CPU.

Consideração de escalabilidade com o Node.JS

  1. Node.JS em si não utiliza todo o núcleo do sistema subjacente e é único segmentado por padrão, você tem que escrever a lógica por conta própria para utilizar o processador multi-core e torná-lo multi-threaded.

Alternativas Node.JS

Há outra opção para usar no lugar do Vert.x entretanto, o Vert.x parece ser bastante promissor e tem muitos recursos adicionais, como o polygot, e melhores considerações de escalabilidade.


Para resumir:

O Node.js é adequado para aplicativos que possuem muitas conexões simultâneas e cada solicitação só precisa de muito poucos ciclos de CPU, porque o loop de eventos (com todos os outros clientes) é bloqueado durante a execução de uma função.

Um bom artigo sobre o loop de eventos no Node.js é o blog de tecnologia da Mixu: Entendendo o loop de eventos node.js.


Pode ser usado onde

  • Aplicativos que são altamente orientados a eventos e são altamente vinculados a E / S
  • Aplicativos que manipulam um grande número de conexões para outros sistemas
  • Aplicativos em tempo real (o Node.js foi projetado desde o início para uso em tempo real e para ser fácil de usar).
  • Aplicativos que manipulam o fluxo de informações de e para outras fontes
  • Alto tráfego, aplicativos escalonáveis
  • Aplicativos móveis que precisam falar com a API e o banco de dados da plataforma, sem precisar fazer muita análise de dados
  • Construa aplicativos em rede
  • Aplicativos que precisam falar com o back-end com muita frequência

Na frente de dispositivos móveis, as empresas de horário nobre confiaram no Node.js para suas soluções móveis. Confira o porquê?

LinkedIn é um usuário proeminente. Sua pilha inteira de celulares é construída em Node.js. Eles passaram de 15 servidores com 15 instâncias em cada máquina física, para apenas 4 instâncias - que podem lidar com o dobro do tráfego!

eBay lançou o ql.io, uma linguagem de consulta da Web para APIs HTTP, que usa o Node.js como a pilha de tempo de execução. Eles conseguiram ajustar uma estação de trabalho Ubuntu com qualidade de desenvolvedor para lidar com mais de 120.000 conexões ativas por processo node.js, com cada conexão consumindo cerca de 2kB de memória!

Walmart reformulou seu aplicativo móvel para usar o Node.js e empurrou seu processamento de JavaScript para o servidor.

Leia mais em: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/


Você fez um ótimo trabalho de resumir o que é incrível sobre o Node.js. Meu sentimento é que o Node.js é especialmente adequado para aplicativos em que você gostaria de manter uma conexão persistente do navegador de volta ao servidor. Usando uma técnica conhecida como "long-polling" , você pode escrever um aplicativo que envia atualizações para o usuário em tempo real. Fazer longas pesquisas em muitos dos gigantes da web, como Ruby on Rails ou Django , criaria uma carga imensa no servidor, porque cada cliente ativo consome um processo de servidor. Esta situação equivale a um ataque de tarpit . Quando você usa algo como o Node.js, o servidor não precisa manter threads separados para cada conexão aberta.

Isso significa que você pode criar um aplicativo de bate-papo baseado em navegador no Node.js que quase não usa recursos do sistema para atender a muitos clientes. Sempre que você quiser fazer esse tipo de pesquisa longa, o Node.js é uma ótima opção.

Vale a pena mencionar que o Ruby e o Python têm ferramentas para fazer esse tipo de coisa ( eventmachine e twisted , respectivamente), mas o Node.js faz isso excepcionalmente bem e, a partir do zero. O JavaScript está excepcionalmente bem situado para um modelo de simultaneidade baseado em retorno de chamada, e ele se destaca aqui. Além disso, ser capaz de serializar e desserializar com JSON nativo para o cliente e o servidor é muito bacana.

Estou ansioso para ler outras respostas aqui, esta é uma pergunta fantástica.

Vale a pena ressaltar que o Node.js também é ótimo para situações em que você estará reutilizando muito código na lacuna cliente / servidor. O framework Meteor torna isso realmente fácil, e muitas pessoas estão sugerindo que esse pode ser o futuro do desenvolvimento web. Eu posso dizer por experiência que é muito divertido escrever código no Meteor, e uma grande parte disso é gastar menos tempo pensando em como você vai reestruturar seus dados, então o código que roda no navegador pode facilmente manipulá-lo e devolvê-lo.

Aqui está um artigo sobre Pyramid e long-polling, que acaba por ser muito fácil de configurar com uma pequena ajuda do gevent: TicTacToe e Long Polling com Pyramid .


Nó melhor para manipulação de solicitações simultâneas

Então, vamos começar com uma história. A partir dos últimos 2 anos, estou trabalhando em JavaScript e desenvolvendo o front-end da web e estou aproveitando. Os caras de back-end nos fornecem algumas APIs escritas em Java, python (não nos importamos) e simplesmente escrevemos uma chamada AJAX, obtemos nossos dados e adivinhe! acabamos. Mas na realidade não é assim tão fácil, se os dados que estamos obtendo não estiverem corretos ou houver algum erro do servidor, então nós temos que entrar em contato com o pessoal do back end pelo correio ou chat (às vezes no whatsApp também :)). não é legal. E se nós escrevêssemos nossas APIs em JavaScript e chamarmos essas APIs do nosso front end? Sim, isso é muito legal, porque se enfrentarmos algum problema na API, podemos investigar. Adivinha ! você pode fazer isso agora, como? - Node está lá para você.

Ok concordou que você pode escrever sua API em JavaScript, mas e se eu estou bem com o problema acima. Você tem algum outro motivo para usar o nó para a API de descanso?

então aqui está a mágica começa. Sim, eu tenho outras razões para usar o nó para nossas APIs.

Vamos voltar ao nosso tradicional sistema de APIs de descanso, que é baseado em operações de bloqueio ou encadeamento. Suponha que dois pedidos simultâneos ocorram (r1 e r2), cada um deles requer operação do banco de dados. Então, no sistema tradicional, o que acontece:

1. Waiting Way: Nosso servidor começa a atender a solicitação r1 e aguarda a resposta da consulta. após a conclusão de r1 , o servidor começa a servir r2 e o faz da mesma maneira. Então, esperar não é uma boa ideia, porque não temos muito tempo.

2. Threading Way: Nosso servidor irá criar dois threads para ambos os pedidos r1 e r2 e servir a sua finalidade depois de consultar banco de dados para esfriar seu fast.But é consome memória, porque você pode ver que começamos dois tópicos também problema aumenta quando ambos os pedidos está consultando mesmos dados, então você tem que lidar com o tipo deadlock de problemas. Então é melhor do que esperar maneira, mas ainda existem problemas.

Agora aqui está, como o nó fará isso:

3. Nodeway: Quando a mesma solicitação simultânea vem no nó, ela registrará um evento com seu retorno de chamada e seguirá em frente. Ele não aguardará a resposta da consulta para um pedido específico. Assim, quando a solicitação r1 vier, o loop de eventos do nó (sim, há um evento) loop no nó que serve a essa finalidade.) registre um evento com sua função de retorno de chamada e avance para servir a solicitação de r2 e registre de forma semelhante seu evento com seu retorno de chamada. Sempre que qualquer consulta terminar, ele acionará seu evento correspondente e executará seu retorno de chamada até a conclusão sem ser interrompido.

Portanto, sem espera, sem threading, sem consumo de memória - sim, isso é nodeway para servir API de descanso.


Eu posso compartilhar alguns pontos onde e por que usar o nó js.

  1. Para aplicações em tempo real como chat, edição colaborativa melhor, vamos com o nodejs, pois é a base de eventos onde o evento de fogo e os dados para os clientes do servidor.
  2. Simples e fácil de entender, pois é base de javascript, onde a maioria das pessoas tem idéia.
  3. A maioria dos aplicativos da web atuais em direção ao js angular & backbone, com o nó, é fácil interagir com o código do lado do cliente, pois ambos usarão os dados json.
  4. Muitos plugins disponíveis.

Desvantagens: -

  1. O nó suportará a maioria dos bancos de dados, mas o melhor é o mongodb, que não suporta junções complexas e outras.
  2. Erros de compilação ... o desenvolvedor deve lidar com todas as exceções, caso contrário, se algum aplicativo de acordo de erro parará de funcionar onde, novamente, precisamos iniciar manualmente ou usar qualquer ferramenta de automação.

Conclusão: - Nodejs melhor para usar para aplicações simples e em tempo real .. se você tem lógica de negócios muito grande e funcionalidade complexa melhor não deve usar o nodejs. Se você quiser construir um aplicativo junto com o chat e qualquer funcionalidade colaborativa, o nó pode ser usado em partes específicas e permanecer deve ir com a sua tecnologia de conveniência.


Se a sua aplicação conecta principalmente web apis, ou outros canais io, ou uma interface de usuário, o node.js pode ser uma escolha justa para você, especialmente se você quiser extrair a maior escalabilidade, ou, se sua principal linguagem na vida é javascript (ou javascript transpilers das sortes). Se você construir microservices, node.js também está bem. O Node.js também é adequado para qualquer projeto que seja pequeno ou simples.

Seu principal ponto de venda é que ele permite que os front-ends se responsabilizem pelo material de back-end em vez da divisão típica. Outro ponto de venda justificável é se a sua força de trabalho é orientada para o javascript, para começar.

Além de um certo ponto, no entanto, você não pode dimensionar seu código sem ataques terríveis para forçar modularidade, legibilidade e controle de fluxo. Algumas pessoas gostam desses hacks, especialmente vindo de um fundo de javascript baseado em eventos, eles parecem familiares ou perdoáveis.

Em particular, quando o seu aplicativo precisa executar fluxos síncronos, você começa a sangrar por meio de soluções incompletas que diminuem sua velocidade consideravelmente em termos de seu processo de desenvolvimento. Se você tiver peças com uso intensivo de computação em seu aplicativo, pise com cuidado escolhendo (somente) node.js. Talvez o Koajs ou outras novidades aliviem esses aspectos originalmente espinhosos, comparado a quando eu originalmente usei node.js ou escrevi isso.







web-applications