O que é o Node.js?

Eu não entendo completamente o que é o Node.js. Talvez seja porque eu sou principalmente um desenvolvedor de aplicativos de negócios baseados na web. O que é e qual é o uso disso?

Meu entendimento até agora é que:

  1. O modelo de programação é orientado a events, especialmente o modo como lida com E / S.
  2. Ele usa JavaScript e o analisador é V8 .
  3. Ele pode ser facilmente usado para criar aplicativos de servidor simultâneos.

Meus entendimentos estão corretos? Se sim, então quais são os benefícios da E / S processada, é apenas mais para o material de simultaneidade? Além disso, a direção do Node.js é um modelo de programação baseado em JavaScript (baseado em V8)?

Eu acho que as vantagens são:

  1. Desenvolvimento Web em linguagem dinâmica (JavaScript) em uma VM incrivelmente rápida (V8). É muito mais rápido que Ruby, Python ou Perl.

  2. Capacidade de lidar com milhares de conexões simultâneas com sobrecarga mínima em um único processo.

  3. O JavaScript é perfeito for loops de events com objects e fechamentos de funções de primeira class. As pessoas já sabem como usá-lo dessa maneira, usando-o no navegador para responder a events iniciados pelo usuário.

  4. Muita gente já conhece JavaScript, até pessoas que não dizem ser programadoras. É indiscutivelmente a linguagem de programação mais popular.

  5. O uso do JavaScript em um servidor da Web, bem como no navegador, reduz a incompatibilidade de impedância entre os dois ambientes de programação que podem comunicar estruturas de dados via JSON que funcionam da mesma maneira nos dois lados da equação. O código de validação de formulário duplicado pode ser compartilhado entre o servidor e o cliente, etc.

Eu uso o Node.js no trabalho e acho que ele é muito poderoso. Forçado a escolher uma palavra para descrever o Node.js, eu diria “interessante” (que não é um adjetivo puramente positivo). A comunidade é vibrante e crescente. O JavaScript, apesar de suas esquisitices, pode ser uma ótima linguagem para codificar. E você repensará diariamente sua própria compreensão das “melhores práticas” e os padrões de código bem estruturado. Há uma enorme energia de idéias fluindo para o Node.js agora, e trabalhar nele expõe você a todo esse pensamento – grande levantamento de peso mental.

O Node.js na produção é definitivamente possível, mas longe da implementação “pronta para uso” aparentemente prometida pela documentação. Com o Node.js v0.6.x, o “cluster” foi integrado à plataforma, fornecendo um dos blocos de construção essenciais, mas meu script “production.js” ainda tem ~ 150 linhas de lógica para lidar com coisas como criar o log diretório, recyclerview de trabalhadores mortos, etc. Para um serviço de produção “sério”, você também precisa estar preparado para estrangular as conexões de input e fazer todas as coisas que o Apache faz para o PHP . Para ser justo, o Ruby on Rails tem esse problema exato . Ele é resolvido através de dois mecanismos complementares: 1) Colocar Ruby on Rails / Node.js atrás de um servidor web dedicado (escrito em C e testado para o inferno e voltar) como Nginx (ou Apache / Lighttd ). O servidor da Web pode servir com eficiência o conteúdo estático, o registro de access, a reescrita de URLs, o encerramento do SSL , o cumprimento das regras de access e o gerenciamento de vários sub-serviços. Para solicitações que atingem o serviço do nó real, o servidor da Web faz o proxy da solicitação. 2) Usando uma estrutura como o Unicorn, que irá gerenciar os processos de trabalho, reciclá-los periodicamente, etc. Ainda não encontrei uma estrutura de serviço do Node.js que pareça totalmente integrada; pode existir, mas ainda não o encontrei e ainda uso ~ 150 linhas no meu “production.js” laminado a mão.

Estruturas de leitura como o Express fazem parecer que a prática padrão é simplesmente servir tudo através de um serviço Node.js do tipo jack-of-all-trades … “app.use (express.static (__ dirname + ‘/ public’))” . Para serviços e desenvolvimento com carga mais baixa, provavelmente está tudo bem. Mas, assim que você tentar colocar grande carga de tempo em seu serviço e executá-lo 24 horas por dia, você descobrirá rapidamente as motivações que levam grandes sites a ter código C bem elaborado, como o Nginx, e lidar com todos os sites. das solicitações de conteúdo estático (… até que você configure um CDN , como o Amazon CloudFront )). Para um pouco engraçado e descaradamente negativo assumir isso, ver esse cara .

O Node.js também está encontrando mais e mais usos não relacionados a serviços. Mesmo se você estiver usando outra coisa para servir conteúdo da web, você ainda pode usar o Node.js como uma ferramenta de construção, usando módulos npm para organizar seu código, Browserify para costurá-lo em um único recurso e uglify-js para minimizá- lo para implantação . Para lidar com a web, o JavaScript é uma correspondência de impedância perfeita e, freqüentemente, torna a rota de ataque mais fácil. Por exemplo, se você quiser rastejar por meio de um monte de cargas úteis de resposta JSON , deverá usar meu módulo CLI de sublinhado , o cinturão de utilitários de dados estruturados.

Prós e contras:

  • Pro: Para um servidor, escrever JavaScript no backend tem sido uma “droga de gateway” para aprender padrões modernos de interface do usuário. Eu não tenho mais medo de escrever código de cliente.
  • Pro: Tende a incentivar a verificação de erro adequada (erro é retornado por praticamente todos os retornos de chamada, incomodando o programador para lidar com ele; também, async.js e outras bibliotecas manipulam o paradigma “falhar se qualquer uma dessas subtarefas falhar” muito melhor do que o código síncrono típico )
  • Pro: algumas tarefas interessantes e normalmente difíceis tornam-se triviais – como obter status nas tarefas em andamento, comunicar-se entre os funcionários ou compartilhar o estado do cache
  • Pro: enorme comunidade e muitas ótimas bibliotecas baseadas em um sólido gerenciador de pacotes (npm)
  • Con: JavaScript não tem biblioteca padrão. Você fica tão acostumado a importar funcionalidades que parece estranho quando usa o JSON.parse ou algum outro método de compilation que não requer a adição de um módulo npm. Isso significa que existem cinco versões de tudo. Mesmo os módulos incluídos no “núcleo” do Node.js têm mais cinco variantes, caso você não esteja satisfeito com a implementação padrão. Isso leva a uma rápida evolução, mas também a um certo nível de confusão.

Versus um modelo simples de um processo por solicitação ( LAMP ):

  • Pro: Escalável para milhares de conexões ativas. Muito rápido e muito eficiente. Para uma frota da web, isso poderia significar uma redução de 10X no número de checkboxs necessárias em relação ao PHP ou ao Ruby
  • Pro: Escrever padrões paralelos é fácil. Imagine que você precisa buscar três (ou N) blobs do Memcached . Faça isso em PHP … você acabou de escrever código, o primeiro, depois o segundo, depois o terceiro? Uau, isso é lento. Há um módulo PECL especial para corrigir esse problema específico do Memcached, mas e se você quiser buscar alguns dados do Memcached em paralelo com a consulta do seu database? Em Node.js, porque o paradigma é asynchronous, ter uma solicitação da Web faz várias coisas em paralelo é muito natural.
  • Con: O código asynchronous é fundamentalmente mais complexo do que o código síncrono, e a curva de aprendizado inicial pode ser difícil para os desenvolvedores sem uma compreensão sólida do que a execução simultânea realmente significa. Ainda assim, é muito menos difícil do que escrever qualquer tipo de código multithread com bloqueio.
  • Con: Se uma solicitação de cálculo intensivo for executada, por exemplo, 100 ms, ela parará o processamento de outras solicitações que estão sendo tratadas no mesmo processo do Node.js … AKA, multitarefa cooperativa . Isso pode ser atenuado com o padrão Web Workers (desmembrando um subprocess para lidar com a tarefa cara). Como alternativa, você poderia usar um grande número de trabalhadores do Node.js e permitir que cada um identifique uma única solicitação simultaneamente (ainda que seja bastante eficiente, pois não há reciclar o processo).
  • Con: Executar um sistema de produção é MUITO mais complicado do que um modelo CGI como Apache + PHP, Perl , Ruby , etc. As exceções não tratadas derrubarão todo o processo, necessitando de lógica para reiniciar os trabalhadores com falha (consulte o cluster ). Módulos com código nativo buggy podem danificar o processo. Sempre que um trabalhador morre, qualquer pedido que ele estava manipulando é descartado, portanto, uma API com bugs pode degradar facilmente o serviço para outras APIs co-hospedadas.

Versus escrever um serviço “real” em Java / C # / C (C? Realmente?)

  • Pro: Fazer asynchronous no Node.js é mais fácil do que fazer segurança de thread em qualquer outro lugar e, indiscutivelmente, oferece maior benefício. O Node.js é de longe o paradigma asynchronous menos doloroso em que já trabalhei. Com boas bibliotecas, é apenas um pouco mais difícil do que escrever código síncrono.
  • Pro: Não há multithreading / bloqueio de bugs. É verdade que você investe antecipadamente ao escrever um código mais detalhado que expresse um stream de trabalho asynchronous adequado sem operações de bloqueio. E você precisa escrever alguns testes e fazer com que a coisa funcione (é uma linguagem de script e nomes de variables ​​de dedilhado de gordura só são capturados no tempo de teste da unidade). MAS, uma vez que você trabalhe, a área de superfície para heisenbugs – problemas estranhos que só se manifestam uma vez em um milhão de corridas – essa área superficial é muito mais baixa. As taxas que escrevem o código Node.js são carregadas na fase de codificação. Então você tende a acabar com um código estável.
  • Pro: o JavaScript é muito mais leve para expressar a funcionalidade. É difícil provar isso com palavras, mas JSON , digitação dinâmica, notação lambda, inheritance de protótipo, módulos leves, o que quer que seja … apenas tende a usar menos código para expressar as mesmas idéias.
  • Con: Talvez você realmente gosta de serviços de codificação em Java?

Para outra perspectiva sobre JavaScript e Node.js, confira De Java para Node.js , uma postagem de blog sobre impressões e experiências de um desenvolvedor Java aprendendo Node.js.


Módulos Ao considerar o nó, tenha em mente que sua escolha de bibliotecas JavaScript DEFINIRÁ sua experiência. A maioria das pessoas usa pelo menos dois, um auxiliar de padrão asynchronous (Step, Futures, Async) e um módulo de açúcar em JavaScript ( Underscore.js ).

Ajudante / JavaScript Sugar:

  • Underscore.js – use isso. Apenas faça isso. Ele torna seu código agradável e legível com coisas como _.isString () e _.isArray (). Eu não tenho certeza como você poderia escrever código seguro de outra forma. Além disso, para melhorar a linha de comando-fu, confira meu próprio Underscore-CLI .

Módulos de Padrão Assíncrono:

  • Step – uma maneira muito elegante de expressar combinações de ações seriais e paralelas. Minha recomendação pessoal. Veja o meu post sobre o que o código Step parece.
  • Futuros – muito mais flexível (isso é realmente uma coisa boa?) Maneira de expressar pedidos através de requisitos. Pode expressar coisas como “inicie a, b, c em paralelo. Quando A e B terminam, inicie AB. Quando A e C terminarem, inicie o AC.” Essa flexibilidade requer mais cuidado para evitar erros em seu stream de trabalho (como nunca chamar o retorno de chamada ou chamá-lo várias vezes). Veja o post de Raynos sobre o uso de futuros (este é o post que me fez “pegar” futuros).
  • Async – biblioteca mais tradicional com um método para cada padrão. Comecei com isso antes de minha conversão religiosa para a etapa e subsequente percepção de que todos os padrões em Async poderiam ser expressos em Step com um único paradigma mais legível.
  • TameJS – Escrito por OKCupid, é um pré-compilador que adiciona um novo idioma primative “await” para escrever elegantemente streams de trabalho seriais e paralelos. O padrão parece incrível, mas requer pré-compilation. Eu ainda estou me decidindo sobre isso.
  • StreamlineJS – concorrente do TameJS. Estou inclinado para Tame, mas você pode decidir.

Ou para ler tudo sobre as bibliotecas assíncronas, veja esta entrevista em painel com os autores.

Estrutura da Web:

  • Expresse o ótimo Ruby no framework Rails-esk para organizar sites. Ele usa o JADE como um mecanismo de template XML / HTML, o que torna a criação de HTML menos dolorosa, quase elegante até.
  • jQuery Embora não seja tecnicamente um módulo de nó, o jQuery está rapidamente se tornando um padrão de fato para a interface de usuário do lado do cliente. O jQuery fornece seletores do tipo CSS para ‘consultar’ conjuntos de elementos DOM que podem ser operados (manipuladores, propriedades, estilos, etc.). Na mesma linha, o framework Bootstrap CSS do Twitter, Backbone.js para um padrão MVC e Browserify.js para unir todos os seus arquivos JavaScript em um único arquivo. Todos esses módulos estão se tornando padrões de fato, então você deve pelo menos checá-los se você não ouviu falar deles.

Teste:

  • JSHint – deve usar; Eu não usei isso a princípio, o que agora parece incompreensível. O JSLint adiciona um monte de verificações básicas que você obtém com uma linguagem compilada como o Java. Parênteses incompatíveis, variables ​​não declaradas, tipos de várias formas e tamanhos. Você também pode ativar várias formas do que eu chamo de “modo anal”, onde você verifica o estilo dos espaços em branco e tudo mais, o que é OK se essa é a sua xícara de chá – mas o valor real vem de obter feedback instantâneo sobre o número exato da linha onde você esqueceu um fechamento “)” … sem ter que executar seu código e acertar a linha ofensiva. “JSHint” é uma variante mais configurável do JSLint de Douglas Crockford .
  • Concorrente Mocha para votos que eu estou começando a preferir. Ambas as estruturas lidam bem com o básico, mas padrões complexos tendem a ser mais fáceis de expressar no Mocha.
  • Vows Vows é realmente muito elegante. E imprime um relatório encantador (–spec) mostrando a você quais casos de teste passaram / falharam. Gaste 30 minutos aprendendo e você pode criar testes básicos para seus módulos com o mínimo de esforço.
  • Zombie – Teste sem cabeça para HTML e JavaScript usando JSDom como um “navegador” virtual. Coisas muito poderosas. Combine-o com o Replay para obter testes determinísticos rápidos de código no navegador.
  • Um comentário sobre como “pensar” em testes:
    • O teste não é opcional. Com uma linguagem dinâmica como JavaScript, existem poucas verificações estáticas. Por exemplo, passar dois parâmetros para um método que espera 4 não será interrompido até que o código seja executado. Barra muito baixa para criar erros em JavaScript. Testes básicos são essenciais para compensar a lacuna de verificação com linguagens compiladas.
    • Esqueça a validação, apenas faça seu código executar. Para cada método, meu primeiro caso de validação é “nada quebra”, e esse é o caso que é acionado com mais frequência. Provar que seu código é executado sem arremessar captura 80% dos bugs e fará muito para melhorar a confiança do seu código, e você se verá voltando e adicionando os casos de validação diferenciados que você ignorou.
    • Comece pequeno e quebre a barreira inercial. Somos todos preguiçosos e pressionados pelo tempo, e é fácil ver o teste como “trabalho extra”. Então comece pequeno. Escreva o caso de teste 0 – carregue seu módulo e relate o sucesso. Se você se forçar a fazer exatamente isso, a barreira inercial ao teste será quebrada. Isso é <30 min para fazer isso pela primeira vez, incluindo a leitura da documentação. Agora escreva o caso de teste 1 - chame um dos seus métodos e verifique "quebras de nada", ou seja, que você não recebe um erro de volta. O caso de teste 1 deve levar menos de um minuto. Com a inércia desaparecida, torna-se fácil expandir incrementalmente sua cobertura de teste.
    • Agora evolua seus testes com seu código. Não se deixe intimidar pelo que seria o teste “correto” de ponta a ponta com servidores simulados e tudo isso. Código começa simples e evolui para lidar com novos casos; testes também devem. Ao adicionar novos casos e nova complexidade ao seu código, adicione casos de teste para exercitar o novo código. Ao encontrar bugs, adicione verificações e / ou novos casos para cobrir o código defeituoso. Quando você está depurando e perde a confiança em um pedaço de código, volte e adicione testes para provar que está fazendo o que você acha que é. Capture strings de dados de exemplo (de outros serviços que você chama, websites que você copia, qualquer que seja) e os alimente ao seu código de análise. Alguns casos aqui, validação aprimorada, e você terá um código altamente confiável.

Além disso, confira a lista oficial de módulos Node.js recomendados. No entanto, o Wiki do Node Modules do GitHub é muito mais completo e um bom recurso.


Para entender o Node, é útil considerar algumas das principais opções de design:

O Node.js é baseado em events e asynchronous / não- bloqueador . Eventos, como uma conexão HTTP recebida, triggersm uma function JavaScript que funciona um pouco e iniciam outras tarefas assíncronas, como conectar-se a um database ou obter conteúdo de outro servidor. Uma vez que estas tarefas tenham sido iniciadas, a function de evento é concluída e o Node.js volta a adormecer. Assim que algo mais acontece, como a conexão do database sendo estabelecida ou o servidor externo respondendo com conteúdo, as funções de retorno de chamada triggersm e mais códigos JavaScript são executados, potencialmente iniciando ainda mais tarefas assíncronas (como uma consulta de database). Dessa forma, o Node.js terá prazer em intercalar atividades para vários streams de trabalho paralelos, executando quaisquer atividades que sejam desbloqueadas a qualquer momento. É por isso que o Node.js faz um ótimo trabalho gerenciando milhares de conexões simultâneas.

Por que não usar apenas um processo / thread por conexão como todos os outros? No Node.js, uma nova conexão é apenas uma alocação de heap muito pequena. Girar um novo processo leva significativamente mais memory, um megabyte em algumas plataformas. Mas o custo real é a sobrecarga associada à mudança de contexto. Quando você tem 10 ^ 6 threads de kernel, o kernel tem que fazer muito trabalho para descobrir quem deve executar em seguida. Um monte de trabalho foi dedicado à construção de um planejador O (1) para Linux, mas no final, é muito mais eficiente ter um único processo orientado a events do que processos 10 ^ 6 competindo pelo tempo de CPU. Além disso, sob condições de sobrecarga, o modelo de multiprocessos se comporta muito mal, privando os serviços de administração e gerenciamento críticos, especialmente o SSHD (o que significa que você não pode nem mesmo fazer o login na checkbox para descobrir como ele realmente está ferrado).

Node.js é SINGLE THREADED e LOCK FREE . O Node.js, como uma escolha de design muito deliberada, tem apenas um único encadeamento por processo. Por causa disso, é fundamentalmente impossível que vários encadeamentos acessem dados simultaneamente. Assim, nenhum bloqueio é necessário. Tópicos são difíceis. Realmente muito difícil. Se você não acredita nisso, não fez programação suficiente. Obter o bloqueio certo é difícil e resulta em erros que são realmente difíceis de rastrear. A eliminação de bloqueios e multi-threading faz com que uma das mais desagradáveis ​​classs de bugs simplesmente desapareça. Essa pode ser a maior vantagem do nó.

Mas como eu aproveito minha checkbox de 16 núcleos?

Dois caminhos:

  1. Para grandes tarefas pesadas de computação, como codificação de imagens, o Node.js pode triggersr processos filhos ou enviar mensagens para outros processos de trabalho. Nesse design, você teria um thread gerenciando o stream de events e N processos executando tarefas pesadas de computação e distribuindo os outros 15 CPUs.
  2. Para escalar a taxa de transferência em um webservice, você deve executar vários servidores Node.js em uma checkbox, um por núcleo, usando cluster (com o Node.js v0.6.x, o módulo “cluster” oficial vinculado aqui substitui a versão learnboost que possui uma API diferente). Esses servidores Node.js locais podem competir em um soquete para aceitar novas conexões, equilibrando a carga entre elas. Uma vez que uma conexão é aceita, ela se torna fortemente ligada a um único desses processos compartilhados. Em teoria, isso parece ruim, mas na prática funciona muito bem e permite que você evite a dor de cabeça de escrever código seguro para thread. Além disso, isso significa que o Node.js obtém excelente afinidade de cache da CPU, usando a largura de banda de memory de maneira mais eficiente.

O Node.js permite que você faça coisas realmente poderosas sem gastar muito. Suponha que você tenha um programa Node.js que executa uma variedade de tarefas, ouve em uma porta TCP comandos, codifica algumas imagens, qualquer que seja. Com cinco linhas de código, você pode adicionar em um portal de gerenciamento da Web baseado em HTTP que mostra o status atual das tarefas ativas. Isso é fácil de fazer:

var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end(myJavascriptObject.getSomeStatusInfo()); }).listen(1337, "127.0.0.1"); 

Agora você pode acessar um URL e verificar o status do seu processo em execução. Adicione alguns botões e você terá um “portal de gerenciamento”. Se você tem um script Perl / Python / Ruby em execução, apenas “jogar em um portal de gerenciamento” não é exatamente simples.

Mas o JavaScript não é lento / ruim / mal / desova do diabo? JavaScript tem algumas esquisitices estranhas, mas com “as partes boas” há uma linguagem muito poderosa lá, e em qualquer caso, o JavaScript é a linguagem no cliente (navegador). JavaScript está aqui para ficar; outras linguagens têm como alvo o IL, e os talentos de class mundial estão competindo para produzir os mecanismos JavaScript mais avançados. Por causa da function do JavaScript no navegador, uma enorme quantidade de esforço de engenharia está sendo lançada para tornar o JavaScript muito rápido. V8 é o mais recente e melhor mecanismo de javascript, pelo menos para este mês. Ele afasta as outras linguagens de script tanto em eficiência quanto em estabilidade (olhando para você, Ruby). E só vai melhorar com grandes equipes trabalhando no problema da Microsoft, Google e Mozilla, competindo para construir o melhor motor JavaScript (não é mais um “intérprete” JavaScript, já que todos os motores modernos fazem toneladas de JIT compilando sob o capô com interpretação apenas como um fallback para o código execute-once). Sim, todos nós gostaríamos que pudéssemos corrigir algumas das escolhas mais estranhas de linguagem JavaScript, mas não é tão ruim assim. E a linguagem é tão flexível que você realmente não está codificando JavaScript, você está codificando Step ou jQuery – mais do que qualquer outra linguagem, em JavaScript, as bibliotecas definem a experiência. Para construir aplicativos da Web, você precisa saber JavaScript de qualquer maneira, portanto, codificar com ele no servidor tem uma espécie de sinergia de conjunto de habilidades. Isso me fez não temer escrever código de cliente.

Além disso, se você realmente odeia JavaScript, você pode usar o açúcar sintático como o CoffeeScript . Ou qualquer outra coisa que crie código JavaScript, como o Google Web Toolkit (GWT).

Falando em JavaScript, o que é um “fechamento”? – É uma maneira bem bacana de dizer que você mantém variables ​​de escopo léxico em cadeias de chamadas. 😉 Como isso:

 var myData = "foo"; database.connect( 'user:pass', function myCallback( result ) { database.query("SELECT * from Foo where id = " + myData); } ); // Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback doSomethingElse(); 

Veja como você pode simplesmente usar “myData” sem fazer nada estranho, como escondê-lo em um object? E diferentemente de Java, a variável “myData” não precisa ser somente leitura. Esse poderoso recurso de linguagem torna a programação assíncrona muito menos detalhada e menos dolorosa.

Escrever código asynchronous sempre será mais complexo do que escrever um script simples de encadeamento único, mas com o Node.js, não é muito mais difícil e você obtém muitos benefícios além da eficiência e escalabilidade para milhares de conexões simultâneas. ..

V8 é uma implementação do JavaScript. Ele permite que você execute aplicativos JavaScript autônomos (entre outras coisas).

O Node.js é simplesmente uma biblioteca escrita para o V8 que faz E / S com events. Este conceito é um pouco mais difícil de explicar, e tenho certeza que alguém vai responder com uma explicação melhor do que eu … A essência é que ao invés de fazer alguma input ou saída e esperar que isso aconteça, você simplesmente não espera para terminar. Por exemplo, peça a última hora editada de um arquivo:

 // Pseudo code stat( 'somefile' ) 

Isso pode levar alguns milissegundos ou levar segundos. Com a E / S com events, você simplesmente triggers a solicitação e, em vez de esperar, anexa um retorno de chamada que é executado quando a solicitação é concluída:

 // Pseudo code stat( 'somefile', function( result ) { // Use the result here } ); // ...more code here 

Isso torna muito parecido com o código JavaScript no navegador (por exemplo, com a funcionalidade de estilo Ajax ).

Para mais informações, você deve verificar o artigo Node.js é realmente emocionante, que foi a minha introdução à biblioteca / plataforma … Eu achei muito bom.

O Node.js é uma ferramenta de linha de comando de software livre desenvolvida para o código JavaScript do lado do servidor. Você pode baixar um tarball , compilar e instalar a fonte. Ele permite que você execute programas JavaScript.

O JavaScript é executado pelo V8 , um mecanismo JavaScript desenvolvido pelo Google e usado no navegador Chrome . Ele usa uma API JavaScript para acessar a rede e o sistema de arquivos.

É popular pelo seu desempenho e pela capacidade de realizar operações paralelas.

Entender o node.js é a melhor explicação do node.js que encontrei até agora.

A seguir estão alguns bons artigos sobre o assunto.

  • Aprendendo JavaScript do lado do servidor com o Node.js
  • Desta vez, você aprenderá o Node.js

Os fechamentos são uma maneira de executar código no contexto em que foi criado.

O que isso significa para a concorrência é que você pode definir variables, iniciar uma function de E / S não bloqueante e enviar uma function anônima para seu retorno de chamada.

Quando a tarefa é concluída, a function de retorno de chamada será executada no contexto com as variables, isso é o fechamento.

O motivo pelo qual os closures são tão bons para escrever aplicativos com E / S não-bloqueantes é que é muito fácil gerenciar o contexto de funções executadas de forma assíncrona.

Dois bons exemplos são sobre como você gerencia modelos e usa melhorias progressivas com ele. Você só precisa de algumas peças leves de código JavaScript para que funcione perfeitamente.

Eu recomendo fortemente que você assista e leia estes artigos:

  • Nó de vidro de vídeo
  • Manipulação de Node.js YUI DOM

Pegue qualquer idioma e tente lembrar como você gerenciaria seus modelos de arquivo HTML e o que você precisava fazer para atualizar um único nome de class CSS em sua estrutura DOM (por exemplo, um usuário clicou em um item de menu e deseja marcar como “selecionado” e atualizar o conteúdo da página).

Com o Node.js é tão simples quanto fazê-lo no código JavaScript do lado do cliente. Obtenha seu nó DOM e aplique sua class CSS a isso. Obtenha seu nó DOM e innerHTML seu conteúdo (você precisará de algum código JavaScript adicional para fazer isso. Leia o artigo para saber mais).

Outro bom exemplo é que você pode tornar sua página da Web compatível com JavaScript ativado ou desativado com o mesmo trecho de código. Imagine que você tenha feito uma seleção de data em JavaScript que permita que seus usuários selecionem qualquer data usando um calendar. Você pode escrever (ou usar) o mesmo código JavaScript para fazê-lo funcionar com seu JavaScript ativado ou desativado.

Existe uma analogia muito boa de fast food que explica melhor o modelo orientado a events do Node.js, veja o artigo completo, Node.js, consultórios médicos e restaurantes de fast food – Compreendendo a programação orientada a events

Aqui está um resumo:

Se a junta de fast food seguisse um modelo tradicional, você pediria sua comida e esperaria na fila até que a recebesse. A pessoa que está atrás de você não poderá fazer o pedido até que seu pedido seja feito. Em um modelo orientado a events, você pede sua comida e depois sai da fila para esperar. Todos os outros estão livres para pedir.

O Node.js é baseado em events, mas a maioria dos servidores da Web é baseada em threads. York explica como o Node.js funciona:

  • Você usa seu navegador da web para fazer uma solicitação de “/about.html” em um servidor da web Node.js.

  • O servidor Node.js aceita sua solicitação e chama uma function para recuperar esse arquivo do disco.

  • Enquanto o servidor Node.js está aguardando a recuperação do arquivo, ele atende a próxima solicitação da web.

  • Quando o arquivo é recuperado, há uma function de retorno de chamada inserida na fila de servidores Node.js.

  • O servidor Node.js executa essa function que, nesse caso, renderiza a página “/about.html” e a envia de volta ao seu navegador da web. ”

Bem, eu entendo isso

  • O objective do Node é fornecer uma maneira fácil de construir programas de rede escalonáveis.
  • O Node é similar em design e influenciado por sistemas como o Ruby Event Machine ou o Python’s Twisted.
  • Evented I / O para o javascript V8.

Para mim, isso significa que você estava correto em todas as três suposições. A biblioteca parece promissora!

Além disso, não se esqueça de mencionar que o V8 do Google é muito rápido. Na verdade, ele converte o código JavaScript em código de máquina com o desempenho correspondente do binário compilado. Então, junto com todas as outras grandes coisas, é incrivelmente rápido.

P: O modelo de programação é orientado por events, especialmente o modo como ele lida com E / S.

Corrigir. Ele usa call-backs, portanto, qualquer solicitação para acessar o sistema de arquivos faria com que uma solicitação fosse enviada ao sistema de arquivos e, em seguida, o Node.js começaria a processar sua próxima solicitação. Ele só se preocuparia com a solicitação de E / S depois que obtivesse uma resposta do sistema de arquivos, quando então executaria o código de retorno de chamada. No entanto, é possível fazer solicitações de E / s síncronas (ou seja, solicitações de bloqueio). Cabe ao desenvolvedor escolher entre assíncronas (callbacks) ou síncronas (esperando).

P: Ele usa JavaScript e o analisador é V8.

sim

P: Ele pode ser facilmente usado para criar aplicativos de servidor simultâneos.

Sim, embora você precise codificar manualmente bastante JavaScript. Talvez seja melhor examinar uma estrutura, como http://www.easynodejs.com/ – que vem com documentação on-line completa e um aplicativo de amostra.