Como decidir quando usar o Node.js?


2195

Sou novo nesse tipo de coisa, mas ultimamente tenho ouvido muito sobre o quão bom o Node.js é. Considerando o quanto eu amo trabalhar com jQuery e JavaScript em geral, não posso deixar de pensar em como decidir quando usar o Node.js. O aplicativo da web que tenho em mente é algo como o Bitly - pega algum conteúdo e o arquiva.

De toda a lição de casa que venho fazendo 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 que você execute programas JavaScript
  • utiliza o ótimo mecanismo JavaScript V8
  • é muito bom quando você precisa fazer várias coisas ao mesmo tempo
  • é baseado em eventos, para que todo o maravilhoso material semelhante ao Ajax possa ser feito no lado do servidor
  • nos permite compartilhar código entre o navegador e o back-end
  • vamos conversar com o MySQL

Algumas das fontes que encontrei são:

Considerando que o Node.js pode ser executado quase que imediatamente nas instâncias EC2 da Amazon , estou tentando entender que tipo de problemas exigem o Node.js, em oposição a qualquer um dos poderosos reis do mercado, como PHP , Python e Ruby . Entendo que realmente depende da experiência que se tem em um idioma, mas minha pergunta se enquadra mais na categoria geral de: Quando usar uma estrutura específica e para que tipo de problemas ela é particularmente adequada?


4
Esta questão está sendo discutida em meta ( meta.stackoverflow.com/q/332386/497418 ).
ZzzzBov

Respostas:


1355

Você fez um ótimo trabalho de resumir o que é incrível no Node.js. Minha impressão é que o Node.js é especialmente adequado para aplicativos em que você deseja manter uma conexão persistente do navegador com o servidor. Usando uma técnica conhecida como "pesquisa longa" , você pode escrever um aplicativo que envia atualizações para o usuário em tempo real. Fazer pesquisas longas 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. Essa situação equivale a um ataque de tarpit . Quando você usa algo como 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 no navegador no Node.js. que consome quase nenhum recurso do sistema para atender a muitos clientes. Sempre que você desejar fazer esse tipo de pesquisa longa, o Node.js é uma ótima opção.

Vale ressaltar que Ruby e Python têm ferramentas para fazer esse tipo de coisa ( eventmachine e twisted , respectivamente), mas que o Node.js faz isso excepcionalmente bem e desde o início. O JavaScript está excepcionalmente bem situado em um modelo de simultaneidade baseado em retorno de chamada e é excelente aqui. Além disso, ser capaz de serializar e desserializar com JSON nativo para o cliente e o servidor é bastante bacana.

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

Vale ressaltar que o Node.js também é ótimo para situações nas quais você reutilizará muito código na lacuna cliente / servidor. A estrutura do Meteor facilita muito isso, e muitas pessoas sugerem que esse pode ser o futuro do desenvolvimento da web. Por experiência, posso dizer que é muito divertido escrever código no Meteor, e grande parte disso é gastar menos tempo pensando em como você vai reestruturar seus dados, para que o código executado no navegador possa facilmente manipulá-lo e devolvê-lo.

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


12
Sim, acho muito importante pensar que o 'node.js é especialmente adequado para aplicativos que exigem conexão persistente do navegador com o servidor. - como programas de bate-papo ou jogos interativos '. Se alguém está apenas criando um aplicativo que não precisa necessariamente de comunicação usuário / servidor, o desenvolvimento com outras estruturas seria ótimo e levaria muito menos tempo.
user482594

1
Obrigado por isso ... Great Q e A ;-) Eu também pensar sobre isso em termos de dominar uma grande tecnologia para o desenvolvimento tanto da frente e back-end sobre alguns diferentes;)
Stokedout

12
Por que usar a pesquisa longa? O que aconteceu com o futuro e os soquetes ?
Hitautodestruct

1
Minha resposta curta é o processo em segundo plano. Solicitação e resposta (incluindo API restante) podem ser obtidas com qualquer outro idioma e servidor. Então, para aqueles que estão pensando em converter seus projetos web em nó. Pense novamente é a mesma coisa! Use o nó como um processo de fundo como a leitura de e-mails com imap, processamento de imagem, upload de arquivos para a nuvem, ou qualquer longa ou interminável processos que são principalmente orientados evento ...
Vikas

409

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 o que um usuário (ou robô? Ou sensor?) Faz com o aplicativo precisa ser visto imediatamente por outros usuários, sem uma atualização de página.

Devo mencionar também que o Socket.IO em combinação com o Node.js reduzirá sua latência em tempo real ainda mais do que é possível com pesquisas longas. O Socket.IO voltará à sondagem longa como um cenário de pior caso e, em vez disso, usará soquetes da Web ou até Flash, se estiverem disponíveis.

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

Além disso, Ryan Dahl disse em uma palestra que certa vez participei que os benchmarks do Node.js rivalizam muito com o Nginx em relação a solicitações HTTP antigas e regulares. Portanto, se criarmos com o Node.js, podemos 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 em toda a pilha.


17
Apenas uma observação de alguém alternando entre .Net e Node. As diferentes linguagens para diferentes áreas do sistema ajudam bastante na alternância de contexto. Quando olho para o Javascript, estou trabalhando no cliente, C # significa o servidor de aplicativos, SQL = banco de dados. Trabalhando em Javascript por toda parte, me vi confundindo as camadas ou simplesmente demorando mais para alternar o contexto. É provável que seja um artefato trabalhar na pilha .NET o dia inteiro e o Node à noite, mas faz a diferença.
Michael Blackburn

9
Curiosamente, a prática de indivíduos interculturais trocando de dialeto quando se deslocam entre culturas tradicionais e nativas é chamada de "troca de código".
Michael Blackburn

1
Outro dia, eu estava pensando em como atribuir cores diferentes aos meus .jsarquivos diferentes de alguma forma. Verde para o lado do cliente, azul para o lado do servidor. Eu continuo me perdendo.
AJB

209

Razões para usar o NodeJS:

  • Ele executa Javascript, para que você possa usar o mesmo idioma no servidor e no cliente e até compartilhar algum código entre eles (por exemplo, para validação de formulário ou para renderizar visualizações em cada extremidade).

  • O sistema orientado a eventos de thread único é rápido, mesmo ao lidar com muitas solicitações de uma só vez, e também simples, comparado às estruturas Java ou ROR tradicionais de vários threads .

  • O crescente conjunto de pacotes acessíveis por meio do NPM , incluindo bibliotecas / módulos do cliente e do servidor, além de ferramentas de linha de comando para o desenvolvimento da Web. A maioria deles está convenientemente hospedada no github, onde às vezes você pode relatar um problema e corrigi-lo em poucas horas! É bom ter tudo sob o mesmo teto, com relatórios de problemas padronizados e bifurcação fácil.

  • Tornou-se o ambiente padrão padrão para executar ferramentas relacionadas ao Javascript e outras ferramentas relacionadas à Web , incluindo executores de tarefas, minificadores, embelezadores, linters, pré-processadores, empacotadores e processadores de análise.

  • Parece bastante adequado para prototipagem, desenvolvimento ágil e rápida iteração do produto .

Razões para não usar o NodeJS:

  • Ele executa Javascript, que não possui verificação de tipo em tempo de compilação. Para sistemas grandes e complexos de segurança crítica , ou projetos, incluindo a colaboração entre diferentes organizações, uma linguagem que incentiva interfaces contratuais e fornece verificação estática de tipo pode poupar algum tempo de depuração (e explosões ) a longo prazo. (Embora a JVM esteja bloqueada null, use Haskell para seus reatores nucleares.)

  • Além disso, muitos dos pacotes no NPM são um pouco brutos e ainda estão em rápido desenvolvimento. Algumas bibliotecas para estruturas mais antigas passaram por uma década de testes e correções de bugs e agora são muito estáveis . O Npmjs.org não possui um mecanismo para classificar pacotes , o que levou a uma proliferação de pacotes fazendo mais ou menos a mesma coisa, dos quais uma grande porcentagem não é mais mantida.

  • Inferno aninhado de retorno de chamada. (Claro que existem 20 soluções diferentes para isso ...)

  • O crescente conjunto de pacotes pode fazer com que um projeto do NodeJS pareça radicalmente diferente do seguinte. Há uma grande diversidade de implementações devido ao grande número de opções disponíveis (por exemplo, Express / Sails.js / Meteor / Derby ). Às vezes, isso pode dificultar a entrada de um novo desenvolvedor em um projeto do Node. Compare isso com um desenvolvedor do Rails que ingressa em um projeto existente: ele deve se familiarizar com o aplicativo rapidamente, porque todos os aplicativos do Rails são incentivados a usar uma estrutura semelhante .

  • Lidar com arquivos pode ser um pouco trabalhoso. Coisas triviais em outros idiomas, como ler uma linha de um arquivo de texto, são estranhas o suficiente para fazer com o Node.js, pois há uma pergunta do StackOverflow sobre isso com mais de 80 upvotes. Não há uma maneira simples de ler um registro de cada vez em um arquivo CSV . Etc.

Eu amo o NodeJS, é rápido, selvagem e divertido, mas estou preocupado que ele tenha pouco interesse na correção comprovável. Vamos torcer para que possamos eventualmente mesclar o melhor dos dois mundos. Estou ansioso para ver o que substituirá o Node no futuro ... :)


1
@ nane Sim, acho que eles podem resolver esse problema, no entanto, você deve limitar-se a usar apenas bibliotecas escritas em linguagens typesafe ou aceitar que nem toda a sua base de código é digitada estaticamente. Mas existe um argumento: como você deve escrever bons testes para o seu código, independentemente do idioma, seu nível de confiança deve ser igual, mesmo para o código digitado dinamicamente. Se aceitarmos esse argumento, as vantagens da digitação forte serão reduzidas para auxiliar no tempo de desenvolvimento / depuração, disponibilidade e otimização .
Joeytwiddle 23/08

1
@kervin, concordo que alguns benchmarks seriam ótimos, mas fiquei desapontado com o que encontrei on-line. Alguns argumentaram que o desempenho do .NET é comparável ao do Node, mas que é crucial o que você está realmente fazendo. O nó pode ser ótimo em fornecer pequenas mensagens com muitas conexões simultâneas, mas não tão bom para cálculos matemáticos pesados. Uma boa comparação de desempenho precisaria testar uma variedade de situações.
Joeytwiddle 23/08/2015

2
@joeytwiddle coisas como o Typescript não ajudariam o Node.js quando se trata de lidar com programas complexos maiores e com digitação estática?
CodeMonkey

2
@joeytwiddle pelo que vale a pena, você pode usar stillmaintained.com para determinar se um pacote npm ainda é mantido (como a maioria está no github). Além disso, npm searche npm showvai mostrar a data da última liberação de um pacote.
Dan Pantry

3
Ao comparar os trilhos ao nó, você está confundindo uma plataforma com uma estrutura. Rails é uma estrutura para Ruby, assim como Sails e meteoro são estruturas para Javascript.
BonsaiOak

206

Para abreviar:

O Node.js é adequado para aplicativos que possuem muitas conexões simultâneas e cada solicitação precisa apenas 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 ciclo de eventos em Node.js é de Mixu blog de tecnologia: Entendendo o ciclo de eventos node.js .


127

Eu tenho um exemplo do mundo real em que usei o Node.js. A empresa em que trabalho conseguiu um cliente que queria ter um site HTML estático simples. Este site destina-se à venda de um item usando o PayPal e o cliente também queria ter um contador que mostre a quantidade de itens vendidos. Espera-se que o cliente tenha uma enorme quantidade de visitantes neste site. Decidi fazer o contador usando o Node.js e a estrutura Express.js .

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

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

  1. É muito leve e rápido. Houve mais de 200000 visitas neste site em três semanas e recursos mínimos do servidor foram capazes de lidar com tudo.
  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, eu encontrei um módulo Node.js. para o PayPal.

Nesse caso, o Node.js foi uma excelente escolha.


7
Como você hospeda algo assim? Você precisa configurar o nodejs no servidor de produção? No linux?
Miguel Stevens

1
Existem alguns PaaSs como nodejitsu e Heroku. Ou você pode realmente configurar o nodejs em uma caixa Linux, ou seja, da amazon ec2. Veja: lauradhamilton.com/…
harry young

13
200.000 visitas em 1.814.400 segundos. Não é relevante. Até o bash poderia atender a muitas solicitações, no servidor mais lento. Servidor zero. VM mais lenta.
Tiberiu-Ionuț Stan

105

Os motivos mais importantes para iniciar seu próximo projeto usando o Node ...

  • Todos os caras mais legais gostam disso ... então deve ser divertido.
  • Você pode fazer um hangout no cooler e ter muitas aventuras do Node para se gabar.
  • Você é um centavo quando se trata de custos de hospedagem na nuvem.
  • Já fiz isso com o Rails
  • Você odeia implantações do IIS
  • Seu antigo trabalho de TI está ficando bastante monótono e você deseja estar em uma nova e brilhante inicialização.

O que esperar ...

  • Você se sentirá seguro com o Express sem todo o bloatware de servidor que você nunca precisou.
  • Funciona como um foguete e escala bem.
  • Você sonha isso. Você instalou. O repositório de pacotes npmjs.org é o maior ecossistema de bibliotecas de código aberto do mundo.
  • Seu cérebro ficará distorcido na terra de retornos aninhados ...
  • ... até você aprender a cumprir suas promessas .
  • Sequelize e Passport são seus novos amigos da API.
  • Depurar o código principalmente assíncrono ficará umm ... interessante .
  • Tempo para todas as Noders para dominar Dactilografado .

Quem o usa?

  • PayPal, Netflix, Walmart, LinkedIn, Grupo, Uber, GoDaddy, Dow Jones
  • Eis por que eles mudaram para o Node .

18
Sim, eu poderia ter respondido a essa pergunta da maneira tradicional. Acho que estou qualificado para fazê-lo, mas a maior parte já foi dita e achei que alguma diversão leve quebraria a monotonia. Contribuo regularmente com respostas técnicas para outras questões.
Tony O'Hagan

1
retornos de chamada aninhados podem ser evitados usando geradores ES6 para código assíncrono
refatorar

1
@CleanCrispCode: Sim, de fato! O ES6 adotou o estilo C # async/ awaitentão agora podemos lançar um código de nó assíncrono muito mais limpo, que também suporta try/ catch. Em 2016/17, os codificadores JS estão migrando para o ES6.
Tony O'Hagan

1
dez mil vezes esta "Você vai se sentir seguro com o Express sem todo o servidor bloatware você nunca necessário"
Simone Poggi

60

Não há nada como o Silver Bullet. Tudo vem com algum custo associado a ele. É como se você come alimentos oleosos, comprometerá sua saúde e alimentos saudáveis ​​não vêm com especiarias como alimentos oleosos. É uma escolha individual se eles querem saúde ou especiarias como em seus alimentos. Da 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 seu desenvolvimento. Estou apenas colocando o meu pensamento no mesmo:

Quando usar o Node.JS

  1. Se o código do lado do servidor exigir muito poucos ciclos de CPU. Em outro mundo, você está executando uma operação sem bloqueio e não possui um algoritmo / trabalho pesado que consome muitos ciclos de CPU.
  2. Se você é do Javascript, está à vontade para escrever código Single Threaded, como o JS do lado do cliente.

Quando NÃO usar Node.JS

  1. Sua solicitação do servidor depende do algoritmo / trabalho que consome muita CPU.

Consideração de escalabilidade com Node.JS

  1. O Node.JS em si não utiliza todo o núcleo do sistema subjacente e, por padrão, possui um encadeamento único; você deve escrever a lógica por conta própria para utilizar o processador multi core e torná-lo multiencadeado.

Alternativas ao Node.JS

Há outra opção para usar no lugar do Node.JS, no entanto, o Vert.x parece bastante promissor e possui muitos recursos adicionais, como poligotação e melhores considerações sobre escalabilidade.


24
Não tenho certeza sobre "Se a sua solicitação do servidor incluir operações de bloqueio, como File IO ou Socket IO", sendo listadas em "Quando NÃO usar". Se meu entendimento estiver correto, um dos pontos fortes do node.js é que ele possui meios assíncronos poderosos para lidar com E / S sem bloquear. Portanto, o Node.js pode ser visto como "uma cura" para bloquear E / S.
Ondrej Peterka

3
@OndraPeterka: Você está certo de que o Node.js resolve curar a E / S do servidor, no entanto, se o manipulador de solicitações no servidor estiver fazendo uma chamada de bloqueio para algum outro serviço da Web / operação de arquivo, o Node.js não ajudaria aqui. É E / S não bloqueadora apenas para solicitações de entrada no servidor, mas não para solicitações de saída do manipulador de solicitações de aplicativos.
Ajay Tiwari

4
@ajay de nodejs.org eles dizem "non-blocking I / O", por favor, verifique o seu "Quando NÃO" 2 e 3.
Omar Al-Ithawi

5
com a versão atual, o nó realmente suporta o suporte multinúcleo usando o cluster. Isso realmente aumenta o desempenho do aplicativo Node pelo menos duas vezes. No entanto, acho que o desempenho deve ser superior a duas vezes quando eles estabilizam a biblioteca de cluster.
Nam Nguyen

4
Você pode usar o node.js para computação pesada. Use fork. Consulte stackoverflow.com/questions/9546225/… . O nó lida com vários núcleos muito bem com o clustermódulo. nodejs.org/api/cluster.html
Jess

41

Outra grande coisa que eu acho que ninguém mencionou sobre o Node.js. é a incrível comunidade, o sistema de gerenciamento de pacotes (npm) e a quantidade de módulos que você pode incluir, incluindo-os no seu arquivo package.json.


6
E todos esses pacotes são relativamente novos, portanto, eles têm o benefício de retrospectiva e tendem a estar em conformidade com os padrões da web recentes.
Joeytwiddle 19/07/2013

3
Com todo o respeito, muitos pacotes no npm são terríveis, porque o npm não tem um mecanismo para classificar pacotes . Em retrospecto, alguém da CPAN ?
Dan Dascalescu

pena que nenhuma das bibliotecas de websockets possa satisfazer as especificações do rfc 6455. Os fanboys do node.js. são surdos, burros e cegos quando esse fato é dado.
R3wt

1
Eu não sei sobre quando você fez o comentário, mas a partir de agora o ws biblioteca suporta essa especificação
Jonathan Grey

37

Minha peça: nodejs é excelente para criar sistemas em tempo real, como análises, aplicativos de bate-papo, APIs, servidores de anúncios, etc. Inferno, eu fiz meu primeiro aplicativo de bate-papo usando nodejs e socket.io em menos de 2 horas e durante a semana do exame!

Editar

Faz vários anos desde que comecei a usar o nodejs e o usei para criar várias coisas diferentes, incluindo servidores de arquivos estáticos, análises simples, aplicativos de bate-papo e muito mais. Esta é minha opinião sobre quando usar o nodejs

Quando usar

Ao criar um sistema que enfatize a concorrência e a velocidade.

  • Soquetes apenas servidores como aplicativos de bate-papo, aplicativos irc, etc.
  • Redes sociais que enfatizam recursos em tempo real, como geolocalização, transmissão de vídeo, transmissão de áudio etc.
  • Manipulando pequenos pedaços de dados com muita rapidez, como um aplicativo de análise.
  • Como expor uma API REST apenas.

Quando não usar

É um servidor da web muito versátil, para que você possa usá-lo onde quiser, mas provavelmente não nesses locais.

  • Blogs simples e sites estáticos.
  • Assim como um servidor de arquivos estático.

Tenha em mente que eu estou apenas dando uma olhada. Para servidores de arquivos estáticos, o apache é melhor principalmente porque está amplamente disponível. A comunidade nodejs ficou maior e mais madura ao longo dos anos e é seguro dizer que o nodejs pode ser usado em qualquer lugar, se você tiver sua própria opção de hospedagem.


Blogs simples ainda podem se beneficiar do Node.js. Para veicular arquivos estáticos, você ainda pode usar o Node.js e, se a carga aumentar, basta adicionar o proxy reverso do Nginx à sua frente, conforme as práticas recomendadas atuais. O servidor httpd Apache é um dinossauro que está morrendo - veja esta pesquisa da Netcraft .
Endrju

Eu diria o contrário - dê uma olhada no ghost.org , parece incrível e é construído sobre os NodeJs - colaboração, edição de artigos em tempo real. Além disso, a criação de uma página simples em NodeJS, dizer usando sailsjs.org , é fácil, rápido e você não precisa se preocupar com a aprendizagem de qualquer uma das linguagens de programação do lado do servidor
Bery

30

Pode ser usado onde

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

No campo Mobile, as empresas no horário nobre confiaram no Node.js para suas soluções móveis. Confira por quê?

O LinkedIn é um usuário de destaque. Toda a sua pilha móvel é construída no Node.js. Eles deixaram de executar 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!

O eBay lançou o ql.io, uma linguagem de consulta na Web para APIs HTTP, que usa o Node.js como 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!

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

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


20

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

Então, vamos começar com uma história. Nos últimos 2 anos, estou trabalhando em JavaScript e desenvolvendo front-end da Web e estou gostando. O pessoal do back-end nos fornece algumas APIs escritas em Java, python (não nos importamos) e simplesmente escrevemos uma chamada AJAX, obtemos nossos dados e adivinhem! acabamos. Mas, na realidade, não é tão fácil, se os dados que estamos obtendo não estão corretos ou se houver algum erro no servidor, nós travamos e precisamos entrar em contato com nossos funcionários por e-mail ou bate-papo (às vezes também no whatsApp :).) não é legal. E se nós escrevemos nossas APIs em JavaScript e as chamamos de nosso front end? Sim, isso é muito legal porque, se enfrentarmos algum problema na API, podemos investigar. Adivinha ! você pode fazer isso agora, como? - Nó está lá para você.

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

então aqui está a mágica começa. Sim, tenho outros motivos para usar o nó nas nossas APIs.

Vamos voltar ao nosso sistema API de descanso tradicional, que se baseia na operação de bloqueio ou na segmentação. Suponha que ocorram duas solicitações simultâneas (r1 e r2), cada uma delas requer operação do banco de dados. Então, no sistema tradicional, o que acontecerá:

1. Modo de espera: Nosso servidor começa a atender a r1solicitação e aguarda a resposta da consulta. após a conclusão r1, o servidor começa a servir r2e o faz da mesma maneira. Portanto, esperar não é uma boa ideia, porque não temos muito tempo.

2. Maneira Threading: Nosso servidor cria dois threads para ambas as solicitações r1e r2serve a seus propósitos depois de consultar o banco de dados, para esfriar rapidamente. então você tem que lidar com problemas do tipo deadlock. Portanto, é melhor do que esperar, mas ainda existem problemas.

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

3. Nodeway: quando a mesma solicitação simultânea entrar no nó, ele registrará um evento com seu retorno de chamada e seguirá em frente, não aguardará a resposta da consulta para uma r1solicitação específica. Portanto, quando a solicitação chegar, o loop de eventos do nó (sim, existe um loop de eventos). no nó que serve a esse propósito.) registre um evento com sua função de retorno de chamada e avance para atender à r2solicitação e registre seu evento da mesma forma com seu retorno de chamada. Sempre que uma consulta termina, ela dispara seu evento correspondente e executa seu retorno de chamada até a conclusão sem ser interrompido.

Portanto, sem espera, sem encadeamento, sem consumo de memória - sim, essa é uma maneira de servir a API de descanso.


1
Oi Anshul. Você pode elaborar ou sugerir algum recurso sobre como o conflito pode ocorrer de maneira de encadeamento.
jsbisht

16

Meu mais um motivo para escolher o Node.js para um novo projeto é:

Ser capaz de fazer puro desenvolvimento baseado em nuvem

Eu uso o Cloud9 IDE há algum tempo e agora não consigo imaginar sem ele, ele abrange todos os ciclos de vida de desenvolvimento. Tudo o que você precisa é de um navegador e pode codificar a qualquer momento e em qualquer lugar, em qualquer dispositivo. Você não precisa fazer o check-in do código em um computador (como em casa) e depois fazer o check-out em outro computador (como no local de trabalho).

Claro, 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 desenvolver o Node.js. é realmente uma ótima experiência para mim.


1
Na verdade, o Cloud9 IDE e os outros (com o código que eu uso) suportam quase todos os tipos de linguagem da web.
Wanny Miarelli

7
Você está falando sério? este é o critério para escolher uma pilha? :) feliz que está trabalhando para você!
matanster

15

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

Eu tenho usado muito o nó e, na maioria dos aplicativos que criamos, exige conexões com o servidor ao mesmo tempo, portanto, um tráfego de rede pesado. Estruturas como Express.js e o novo Koajs (que removeu o inferno de retorno de chamada) tornaram o trabalho no nó ainda mais fácil.


15

Colocar amianto longjohns ...

Ontem meu título com Packt Publications, Programação Reativa com JavaScript . Não é realmente um título centrado no Node.js. os capítulos iniciais destinam-se a cobrir a teoria, e os capítulos posteriores pesados ​​em código cobrem a prática. Como eu realmente não achei que seria apropriado deixar de fornecer aos servidores um servidor da web, o Node.js parecia de longe a escolha óbvia. O caso foi encerrado antes mesmo de ser aberto.

Eu poderia ter dado uma visão muito positiva da minha experiência com o Node.js. Em vez disso, fui honesto com os pontos positivos e negativos que encontrei.

Deixe-me incluir algumas citações relevantes aqui:

Atenção: o Node.js e seu ecossistema são quentes - o suficiente para queimar você demais!

Quando eu era assistente de professor de matemática, uma das sugestões não óbvias que me disseram não era para dizer a um aluno que algo era "fácil". O motivo era óbvio em retrospecto: se você disser às pessoas que algo é fácil, alguém que não vê uma solução pode acabar se sentindo (ainda mais) estúpido, porque não apenas eles não conseguem resolver o problema, mas o problema eles são estúpidos demais para entender é fácil!

Existem truques que não apenas incomodam as pessoas vindas do Python / Django, que recarregam a fonte imediatamente se você mudar alguma coisa. Com o Node.js, o comportamento padrão é que, se você fizer uma alteração, a versão antiga continuará ativa até o final do tempo ou até você parar e reiniciar manualmente o servidor. Esse comportamento inadequado não apenas irrita os pythonistas; também irrita usuários nativos do Node.js. que fornecem várias soluções alternativas. A pergunta do StackOverflow “Recarregamento automático de arquivos no Node.js.” possui, no momento em que este artigo foi escrito, mais de 200 votos positivos e 19 respostas; uma edição direciona o usuário para um script de babá, supervisor de nó, com a página inicial em http://tinyurl.com/reactjs-node-supervisor. Esse problema oferece aos novos usuários a grande oportunidade de se sentirem estúpidos porque pensaram ter resolvido o problema, mas o antigo comportamento de buggy permanece completamente inalterado. E é fácil esquecer de devolver o servidor; Eu fiz isso várias vezes. E a mensagem que eu gostaria de passar é: “Não, você não é estúpido porque esse comportamento do Node.js mordeu suas costas; é que os designers do Node.js não viram motivo para fornecer um comportamento apropriado aqui. Tente lidar com isso, talvez usando uma pequena ajuda do supervisor de nó ou de outra solução, mas por favor, não vá embora sentindo que você é estúpido. Você não é o único com o problema; o problema está no comportamento padrão do Node.js. "

Esta seção, depois de algum debate, foi deixada, precisamente porque não quero dar uma impressão de "É fácil". Cortei minhas mãos repetidamente enquanto fazia as coisas funcionarem, e não quero amenizar as dificuldades e fazer com que você acredite que fazer com que o Node.js e seu ecossistema funcione bem é uma questão simples e se não é direta para você também , você não sabe o que está fazendo. Se você não encontrar dificuldades desagradáveis ​​usando o Node.js, isso é maravilhoso. Se você o fizer, espero que você não se afaste, sentindo: "Eu sou estúpido - deve haver algo errado comigo." Você não é estúpido se tiver surpresas desagradáveis ​​ao lidar com o Node.js. Não é você! É o Node.js e seu ecossistema!

O Apêndice, que eu realmente não queria depois do crescente crescimento nos últimos capítulos e da conclusão, fala sobre o que eu consegui encontrar no ecossistema e forneceu uma solução alternativa para o literalismo idiota:

Outro banco de dados que parecia um ajuste perfeito e ainda pode ser resgatável é uma implementação do lado do servidor do armazenamento de valores-chave HTML5. Essa abordagem tem a principal vantagem de uma API que a maioria dos bons desenvolvedores de front-end entende bem o suficiente. Por outro lado, também é uma API que a maioria dos desenvolvedores de front-end não tão bons entende bem o suficiente. Mas com o pacote node-localstorage, enquanto o acesso à sintaxe do dicionário não é oferecido (você deseja usar localStorage.setItem (key, value) ou localStorage.getItem (key), não localStorage [key]), a semântica localStorage completa é implementada , incluindo uma cota padrão de 5 MB - POR QUE? Os desenvolvedores de JavaScript do servidor precisam ser protegidos de si mesmos?

Para recursos de banco de dados do lado do cliente, uma cota de 5 MB por site é realmente uma quantidade generosa e útil de espaço para permitir que os desenvolvedores trabalhem com ele. Você pode definir uma cota muito menor e ainda oferecer aos desenvolvedores uma melhoria imensurável em relação ao mancar junto com o gerenciamento de cookies. Um limite de 5 MB não se presta muito rapidamente ao processamento do Big Data no lado do cliente, mas há uma permissão bastante generosa que os desenvolvedores de recursos podem usar para fazer muito. Mas, por outro lado, 5 MB não é uma parcela particularmente grande da maioria dos discos comprados recentemente, o que significa que se você e um site discordam sobre o uso razoável do espaço em disco, ou se algum site é simplesmente hoggish, não custa realmente você e não corre o risco de um disco rígido inundado, a menos que o disco rígido já esteja cheio demais.

No entanto, pode-se dizer com delicadeza que, quando você é o único que escreve o código para o seu servidor, não precisa de nenhuma proteção adicional para tornar seu banco de dados mais do que um tamanho tolerável de 5 MB. A maioria dos desenvolvedores não precisará nem desejará ferramentas atuando como babá e protegendo-as de armazenar mais de 5 MB de dados do servidor. E a cota de 5 MB, que é um ato de equilíbrio de ouro no lado do cliente, é um pouco tola em um servidor Node.js. (E, para um banco de dados para vários usuários, como é abordado neste apêndice, pode-se apontar, um pouco doloroso, que não são 5 MB por conta de usuário, a menos que você crie um banco de dados separado em disco para cada conta de usuário; são 5 MB compartilhados entre todas as contas de usuário juntas, o que pode ser dolorosose você for viral!) A documentação afirma que a cota é personalizável, mas um email há uma semana para o desenvolvedor perguntando como alterar a cota não tem resposta, assim como a pergunta StackOverflow. A única resposta que consegui encontrar está na fonte do Github CoffeeScript, onde é listado como um segundo argumento opcional opcional para um construtor. Portanto, isso é fácil e você pode especificar uma cota igual ao tamanho de um disco ou partição. Mas, além de portar um recurso que não faz sentido, o autor da ferramenta falhou completamente em seguir uma convenção muito padrão de interpretar 0 como significando "ilimitado" para uma variável ou função em que um número inteiro deve especificar um limite máximo para o uso de alguns recursos. A melhor coisa a fazer com esse erro de característica é provavelmente especificar que a cota é Infinita:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Trocando dois comentários em ordem:

As pessoas desnecessariamente se balançavam no pé constantemente usando JavaScript como um todo, e parte do JavaScript que se tornava uma linguagem respeitável era Douglas Crockford dizendo em essência: “JavaScript como uma linguagem tem algumas partes muito boas e outras muito ruins. Aqui estão as boas partes. Apenas esqueça que qualquer outra coisa está lá. ” Talvez o ecossistema quente do Node.jS desenvolva seu próprio "Douglas Crockford", que dirá: "O ecossistema do Node.js. é um oeste selvagem de codificação, mas existem algumas verdadeiras jóias a serem encontradas. Aqui está um roteiro. Aqui estão as áreas a serem evitadas a quase qualquer custo. Aqui estão as áreas com algumas das mais ricas condições de pagamento encontradas em QUALQUER idioma ou ambiente. ”

Talvez alguém possa tomar essas palavras como um desafio, seguir o exemplo de Crockford e escrever "as partes boas" e / ou "as partes melhores" para o Node.js e seu ecossistema. Eu compraria uma cópia!

E, dado o grau de entusiasmo e as poucas horas de trabalho em todos os projetos, pode ser necessário, em um ano, dois ou três, atenuar acentuadamente quaisquer observações sobre um ecossistema imaturo feito no momento em que este artigo foi escrito. Realmente pode fazer sentido em cinco anos dizer: “O ecossistema do Node.j 2015 teve vários campos minados. O ecossistema 2020 do Node.js. possui vários paraísos. ”


9

Se seu aplicativo amarra principalmente APIs da Web ou outros canais io, fornece ou aceita uma interface do usuário, o node.js pode ser uma escolha justa para você, especialmente se você deseja extrair o máximo de escalabilidade ou, se seu idioma principal na vida é javascript (ou tipos de transpilers de javascript). Se você criar microsserviços, o node.js também estará bem. O Node.js também é adequado para qualquer projeto pequeno ou simples.

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

Além de um certo ponto, no entanto, você não pode escalar seu código sem hacks terríveis para forçar a modularidade, a legibilidade e o controle de fluxo. Porém, algumas pessoas gostam desses hacks, principalmente provenientes de um background javascript orientado a eventos, que parecem familiares ou perdoáveis.

Em particular, quando seu aplicativo precisa executar fluxos síncronos, você começa a sangrar por soluções incompletas que o tornam mais lento em termos de processo de desenvolvimento. Se você possui peças intensivas em computação em seu aplicativo, pise com cuidado (apenas) node.js. Talvez http://koajs.com/ ou outras novidades aliviem esses aspectos originalmente espinhosos, em comparação com quando eu originalmente usei o node.js ou escrevi isso.


3
Existem muitas abordagens existentes para dimensionar aplicativos Node.js. e você parece não fornecer nenhuma referência sobre as reivindicações "soluções incompletas", "hacks terríveis" e "API terrível". Mente se expandindo naqueles?
Sven Slootweg 9/03/15

Deixo isso como um exercício para o leitor, mas basta examinar as chamadas soluções para controle de fluxo.
matanster

2
Isso não é realmente uma resposta. Você alega que as soluções existentes são "terríveis hacks", mas não apontam nenhuma delas. Você considerou que talvez simplesmente não entenda ou esteja ciente dos métodos corretos para dimensionar aplicativos Node.js.?
Sven Slootweg 9/03/15

Eu atualizei minha resposta um pouco. Talvez você ainda tenha reclamações, mas se você acha que está errado, deve comentar com detalhes ... em vez de apontar uma falta na resposta. Isso seria mais produtivo para a comunidade imo.
matanster

-2

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

  1. Para aplicativos em tempo real, como bate-papo, a edição colaborativa é melhor com o nodejs, pois é a base de eventos em que o evento e os dados são disparados para os clientes do servidor.
  2. Simples e fácil de entender, pois é a base de javascript, onde a maioria das pessoas tem idéia.
  3. A maioria dos aplicativos da Web atuais é direcionada para js e backbone angulares. Com o nó, é fácil interagir com o código do lado do cliente, pois ambos usarão dados json.
  4. Muitos plugins disponíveis.

Desvantagens: -

  1. O nó suporta 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 de outra maneira, se algum aplicativo de acordo com erros parar de funcionar onde novamente precisamos ir e iniciá-lo manualmente ou usando qualquer ferramenta de automação.

Conclusão: - É melhor usar o Nodejs para aplicativos simples e em tempo real. Se você possui uma lógica de negócios muito grande e uma funcionalidade complexa, melhor não deve usar o nodejs. Se você deseja criar um aplicativo junto com o bate-papo e qualquer funcionalidade colaborativa .. o nó pode ser usado em partes específicas e deve permanecer com a sua tecnologia de conveniência.


-3
  1. O nó é ótimo para protótipos rápidos, mas eu nunca o usaria novamente para algo 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 visita há algum tempo. Informações de tipo e detecção de erros em tempo de compilação são BOAS COISAS. Por que jogar tudo isso fora? Para quê? E, dang, quando algo vai para o sul, a pilha rastreia muitas vezes completamente inútil.


2
Embora você não obtenha a verificação em tempo de compilação, o JSDoc permite adicionar qualquer informação de tipo que você queira, para que as coisas façam mais sentido quando você voltar. As funções (pequenas) adequadamente decompostas também costumam ser fáceis de grok devido ao seu ambiente bem definido (o fechamento). Os rastreamentos incorretos da pilha geralmente podem ser resolvidos com uma re-fatoração para garantir que você não esteja dividindo sua lógica com um retorno de chamada assíncrono no meio. Manter seus retornos de chamada assíncronos no mesmo fechamento facilita a discussão e a manutenção.
Rich Remer

2
Passei 30 anos com linguagens compiladas, mas depois de usá-lo por apenas cerca de um ano, o JavaScript agora é minha língua preferida. É tão produtivo - posso fazer muito mais com muito menos código do que Java C # C ++ ou C. Mas é uma mentalidade diferente. Variáveis ​​sem tipo são realmente uma vantagem em muitos casos. JSLINT é essencial. Quando você precisa fazer coisas simultaneamente, os retornos de chamada assíncronos são muito mais seguros, fáceis e, finalmente, mais produtivos do que qualquer idioma em que você precise usar threads. E você precisa saber o JavaScript de qualquer maneira, porque é o idioma do navegador.
James

Simpatizo com as preocupações levantadas e observo que foram feitos alguns esforços para resolvê-las, embora certamente não sejam universalmente aplicadas. Existe um projeto incrível chamado Tern que pode fornecer derivação de tipo a partir da análise estática do código Javascript e das bibliotecas. Possui plugins para vários editores. Há também Typescript, JSDoc e BetterJS . E há o Go , uma das muitas linguagens de compilação em Javascript !
Joeytwiddle
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.