Qual é o Node.js? [fechadas]

StackOverflow https://stackoverflow.com/questions/1884724

Pergunta

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

O meu entendimento é que até agora:

  1. O modelo de programação é orientado a eventos, especialmente a forma como ele lida com I / O .
  2. JavaScript eo analisador é V8 .
  3. Pode ser facilmente usado para criar aplicativos de servidor concorrentes.

Os meus entendimentos correto? Se sim, então o que são os benefícios de evented I / O, é apenas mais para o material de concorrência? Além disso, é a direção do Node.js para tornar-se um quadro semelhante, baseada em JavaScript (baseado V8) modelo de programação?

Foi útil?

Solução

Eu acho que as vantagens são:

  1. Desenvolvimento Web em uma linguagem dinâmica (JavaScript) em uma máquina virtual que é incrivelmente rápido (V8). É muito mais rápido do que Ruby, Python ou Perl.

  2. Capacidade de milhares de pega de ligações simultâneas com o mínimo de sobrecarga sobre um único processo.

  3. JavaScript é perfeito para laço de eventos com objetos de função de primeira classe e encerramentos. As pessoas já sabem como usá-lo desta forma ter utilizado no navegador para responder a eventos iniciados pelo usuário.

  4. Um monte de gente já sabe JavaScript, mesmo as pessoas que não pretendem ser programadores. É sem dúvida a linguagem de programação mais popular.

  5. Usando JavaScript em um servidor web, bem como o navegador reduz a diferença de impedância entre os dois ambientes de programação que podem se comunicar estruturas de dados via JSON que o trabalho o mesmo em ambos os lados da equação. código de validação de formulário duplicado pode ser compartilhado entre o servidor eo cliente, etc.

Outras dicas

Eu uso Node.js no trabalho, e encontrá-lo para ser muito poderosa. Forçado a escolher uma palavra para descrever Node.js, eu diria "interessante" (que não é um adjetivo puramente positivo). A comunidade é vibrante e crescente. JavaScript, apesar de suas esquisitices pode ser uma grande linguagem de código. E você vai diária repensar a sua própria compreensão de "melhores práticas" e os padrões de código bem estruturado. Há uma enorme energia das idéias que fluem em Node.js agora, e trabalhando nela expõe a todo esse pensamento -. Ótimo levantamento de peso mentais

Node.js na produção é definitivamente possível, mas muito longe da implantação "turn-key" aparentemente prometido pela documentação. Com Node.js v0.6.x, "cluster" foi integrado na plataforma, proporcionando um dos blocos de construção essenciais, mas meu script "production.js" é ainda ~ 150 linhas de lógica para o material alça como a criação do log diretório, reciclagem de trabalhadores mortos, etc. para um "sério" serviço de produção, você também precisa estar preparado para estrangular conexões de entrada e fazer todas as coisas que o Apache faz para PHP . Para ser justo, Ruby on Rails tem esta exata problema. Ele é resolvido através de dois mecanismos complementares: 1) Colocando rubi nos trilhos / Node.js atrás de um servidor dedicado (escrita em C e testado para inferno e para trás), como Nginx (ou Apache / < a href = "http://en.wikipedia.org/wiki/Lighttpd" rel = "nofollow noreferrer"> Lighttd ). O servidor web pode eficientemente servir conteúdo estático, login de acesso, reescrever URLs, encerrar SSL , fazer cumprir as regras de acesso e gerenciar múltiplas sub-serviços. Para solicitações que chegam ao serviço do nó actual, o servidor web proxies a solicitação através. 2) Usar um quadro como Unicorn que irá gerir os processos de trabalho, reciclá-los periodicamente, etc. eu ainda de encontrar um quadro servindo Node.js que parece totalmente cozido; ele pode existir, mas eu não tê-lo encontrado ainda e ainda usar ~ 150 linhas no meu "production.js" enrolados à mão.

Leitura frameworks como expresso faz parecer que a prática padrão é apenas servem de tudo, através de um jack-de- all-trades serviço Node.js ... "app.use (express.static (__ dirname + '/ public'))". Para serviços de baixa carga e de desenvolvimento, que é provavelmente bem. Mas assim que você tentar colocar carga grande momento em seu serviço e executá-lo 24/7, você vai descobrir rapidamente as motivações que levam grandes sites de ter bem cozido, temperado C-código como Nginx frente para seu site e manipulação de todas as solicitações de conteúdo estático (... até que você configurar um CDN , como Amazon CloudFront )). Para uma tomada negativo um pouco bem-humorado e descaradamente sobre este assunto, consulte esse cara .

Node.js também está encontrando mais e mais usos não-serviço. Mesmo se você estiver usando uma outra coisa para servir conteúdo web, você ainda pode usar o Node.js como uma ferramenta de construção, usando npm módulos para organizar seu código, Browserify para costurar em um único ativo, e enfear-js para apoucar-lo para implantação Para lidar com a web, JavaScript é um perfeito jogo de impedância e, frequentemente, que o torna o caminho mais fácil de ataque. Por exemplo, se você quiser rastejar através de um grupo de noreferrer cargas resposta JSON , você deve usar o meu sublinhado-CLI módulo, o utilitário de cinto de dados estruturadas.

Pros / Contras:

  • Pro: Para um cara servidor, escrevendo JavaScript no backend tem sido uma "porta de entrada" para aprender os padrões de interface do usuário modernos. I escrever código cliente não mais medo.
  • Pro: tende a encorajar a verificação de erros adequada (err é devolvido por praticamente todos os retornos de chamada, chatear o programador para lidar com isso, também, async.js e outras bibliotecas de lidar com a "falhar se qualquer um desses subtasks falhar" paradigma muito melhor do que código síncrono típico)
  • Pro: Algumas tarefas interessantes e, normalmente rígidos tornar trivial - como a obtenção de status em tarefas em vôo, comunicação entre os trabalhadores, ou a partilha de estado de cache
  • Pro: comunidade enorme e toneladas de grandes bibliotecas com base em um gerenciador de pacotes sólido (NPM)
  • Con: JavaScript não tem nenhuma biblioteca padrão. Você se acostuma a funcionalidade importação que se sente estranho quando você usa JSON.parse ou alguma outra configuração no método que não requer a adição de um módulo npm. Isto significa que existem cinco versões de tudo. Mesmo os módulos incluídos na Node.js "core" ter mais cinco variantes você deve estar insatisfeito com a implementação padrão. Isto leva a uma rápida evolução, mas também algum nível de confusão.

Versus um simples modelo de um processo-per-request ( LAMP ):

  • Pro: Escalável para milhares de conexões ativas. Muito rápido e muito eficiente. Para uma frota web, isso pode significar uma redução de 10X no número de caixas necessárias contra PHP ou Ruby
  • Pro: Escrevendo padrões paralelos é fácil. Imagine que você precisa para buscar três (ou N) blobs de Memcached . Fazei isto em PHP ... você acabou de escrever código as buscas o primeiro blob, depois o segundo, depois o terceiro? Uau, isso é lento. Há um especial PECL módulo para corrigir esse problema específico para Memcached, mas o que se você quiser para buscar alguns dados Memcached em paralelo com a sua consulta de banco de dados? Em Node.js, porque o paradigma é assíncrona, tendo uma solicitação da web fazer várias coisas em paralelo é muito natural.
  • Con: código assíncrono é fundamentalmente mais complexo do que o código síncrono, ea curva de aprendizado up-front pode ser difícil para os desenvolvedores sem uma sólida compreensão do que significa a execução simultânea na verdade. Ainda assim, é muito menos difícil do que escrever qualquer tipo de código multithreaded com bloqueio.
  • Con: Se uma solicitação de computação intensiva corridas para, por exemplo, 100 ms, ele irá parar o processamento de outras solicitações que estão sendo tratadas no mesmo processo Node.js ... AKA, cooperativo multitarefa . Isto pode ser mitigado com o padrão Web Workers (cisão um subprocesso para lidar com a tarefa caro). Alternativamente, você poderia usar um grande número de trabalhadores Node.js e só deixar que cada um pega um único pedido simultaneamente (ainda bastante eficiente porque não há reciclagem de processo).
  • Con: Execução de um sistema de produção é muito mais complicado do que um CGI modelo como o Apache + PHP, Perl , rubi , etc. exceções sem tratamento trará para baixo de todo o processo, necessitando lógica para o reinício falhou trabalhadores (ver aglomerado ). Módulos com código nativo de buggy pode hard-travar o processo. Sempre que morre um trabalhador, quaisquer pedidos que foi manipulação são descartados, por isso uma API de buggy pode atender facilmente degrade para outras APIs co-patrocinada.

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

  • Pro: Fazendo assíncrona em Node.js é mais fácil do que fazê-thread-segurança em qualquer outro lugar e sem dúvida proporciona maior benefício. Node.js é de longe o menos paradigma assíncrona dolorosa que eu já trabalhei. Com boas bibliotecas, é apenas um pouco mais difícil do que escrever código síncrona.
  • Pro: Não multithreading / erros de bloqueio. É verdade que você investe na frente por escrito mais detalhado código que expressa um fluxo de trabalho assíncrono adequada sem operações de bloqueio. E você precisa escrever alguns testes e obter a coisa para o trabalho (que é uma linguagem de script e nomes de variáveis ??dedilhado de gordura só é pego em tempo-teste de unidade). Mas, uma vez que você obtê-lo para o trabalho, a área de superfície para a heisenbugs - problemas estranhos que só manifesta uma vez em um milhão de corridas - que a área de superfície é apenas muito, muito menor. Os impostos que escrevem código Node.js são fortemente front-carregados para a fase de codificação. Em seguida, você tende a acabar com código estável.
  • Pro: JavaScript é muito mais leve para expressar funcionalidade. É difícil provar isso com palavras, mas JSON , tipagem dinâmica, notação lambda, herança prototípica, módulos leves, o que quer ... ele só tende a ter menos código para expressar as mesmas idéias.
  • Con:? Talvez você realmente, realmente como codificação de serviços em Java

Para uma outra perspectiva sobre JavaScript e Node.js, veja de Java para Node.js , um blog sobre impressões e experiências de um desenvolvedor Java aprendizagem Node.js.

Módulos Ao considerar nó, tenha em mente que a sua escolha de bibliotecas JavaScript irá DEFINE sua experiência. A maioria das pessoas usam pelo menos dois, um assíncrono padrão helper (Step, Futures, Async), e um módulo de açúcar JavaScript ( Underscore.js ).

Helper / JavaScript Açúcar:

  • Underscore.js - usar isso. Apenas faça. Não faz o seu código bonito e legível com coisas como _.isString () e _.isArray (). Eu não estou realmente certo de como você poderia escrever código seguro contrário. Além disso, para-line-fu comando aprimorado, veja a minha própria Sublinhado-CLI .

Os módulos padrão assíncrono:

  • Passo - uma maneira muito elegante para expressar combinações de ações seriais e paralelas. Minha recomendação pessoal. Consulte meu post no que parece código Passo semelhante.
  • Futures - muito mais flexível (que é realmente uma coisa boa?) Maneira de expressar encomenda atravésrequisitos. Pode expressar coisas como "começar a, b, c em paralelo. Quando A, e terminar B, começar a AB. Quando A, e terminar C, iniciar AC." Essa flexibilidade requer mais cuidado para erros a evitar no seu fluxo de trabalho (como nunca chamar o callback, ou chamando-o várias vezes). Veja post sobre usando futuros (este é o post que me fez "pegar" futuros).
  • Async - biblioteca mais tradicional, com um método para cada padrão. Eu comecei com isso antes da minha conversão religiosa a passo e posterior percepção de que todos os padrões em Async poderia ser expressa na etapa com um único paradigma mais legível.
  • TameJS - Escrito por OkCupid, que é um pré-compilador que adiciona uma nova linguagem primitiva "aguardam" para escrever elegantemente série e fluxos de trabalho paralelos. O padrão parece incrível, mas requer pré-compilação. Eu ainda estou fazendo a minha mente em um presente.
  • StreamlineJS - concorrente para TameJS. Eu estou inclinado a Tame, mas você pode fazer a sua própria mente.

Ou para ler tudo sobre as bibliotecas assíncronas, consulte este painel- entrevistar com os autores.

Web Framework:

  • Expresso Grande Ruby on Rails-ESK para a organização de sites. Ele usa JADE como um XML / HTML templates motor, o que torna a construção de HTML muito menos doloroso, mesmo, quase elegante.
  • jQuery Embora não seja tecnicamente um módulo nó, jQuery está rapidamente se tornando um de-facto padrão para interface de usuário do lado do cliente. jQuery fornece CSS-like seletores para 'consulta' para conjuntos de elementos DOM que podem ser operados (manipuladores conjunto, propriedades, estilos, etc). Na mesma veia, Bootstrap quadro CSS do Twitter, Backbone.js para um MVC padrão, e Browserify.js para costurar todos os seus arquivos JavaScript em um único arquivo. Estes módulos estão todos se tornando padrões de-facto para que você deve pelo menos vê-los se você ainda não ouviu falar deles.

Testing:

  • JSHint - Deve usar; Eu não uso isso em primeiro lugar que agora parece incompreensível. JSLint adiciona de volta um monte das verificações básicas que você começa com uma linguagem compilada como Java. parêntese incompatíveis, variáveis ??não declaradas, typeos de muitas formas e tamanhos. Você também pode ativar várias formas do que chamo de "modo anal", onde você verificar o estilo de espaços em branco e outros enfeites, que é OK, se essa é a sua chávena de chá - mas o valor real vem recebendo feedback instantâneo sobre o número da linha exato onde você esqueceu um fechamento ")" ... sem ter que executar o seu código e atingiu a linha ofender. "JSHint" é uma variante mais configurável de Douglas Crockford 's JSLint .
  • Mocha concorrente votos queEstou começando a preferir. Ambos os quadros lidar com o básico bem o suficiente, mas padrões complexos tendem a ser mais fáceis de expressar em Mocha.
  • Votos votos é realmente muito elegante. E ele imprime um relatório adorável (--spec) mostrando quais casos de teste passou / falhou. Gastar 30 minutos aprendê-la, e você pode criar testes básicos para seus módulos com o mínimo esforço.
  • Zombie - Headless testando para HTML e JavaScript usando JSDom como um virtual "navegador". Material muito poderoso. Combine-o com Repetição para obter raios testes rápidos determinísticos de código no navegador.
  • Um comentário sobre a forma de "pensar sobre" o teste:
    • O teste é não opcional. Com uma linguagem dinâmica como JavaScript, existem muito algumas verificações estáticas. Por exemplo, a passagem de dois parâmetros a um método que espera 4 não vai quebrar até que o código é executada. bar baixo bastante para a criação de erros em JavaScript. testes básicos são essenciais para fazer a lacuna de verificação com linguagens compiladas.
    • Esqueça validação, basta fazer o seu código executar. Para cada método, o meu primeiro caso de validação é "nada quebra", e esse é o caso que os incêndios na maioria das vezes. Provando que suas corridas de código sem jogar capturas de 80% dos bugs e vai fazer muito para melhorar a sua confiança código que você vai encontrar-se voltando e adicionando os casos de validação nuances que você ignorados.
    • Comece pequeno e quebrar a barreira inercial. Nós somos todos preguiçosos, e pressionado por hora, e é fácil ver o teste como "trabalho extra". Então, começar pequeno. Escrever caso de teste 0 - carregar seu módulo e relatório de sucesso. Se você forçar-se a fazer exatamente isso muito, então a barreira inercial a testes está quebrado. Isso é <30 minutos para fazê-lo a primeira vez, incluindo a leitura da documentação. Agora caso de teste de escrita 1 - um dos seus métodos e verificar "quebra nada" chamada, ou seja, que você não conseguir uma volta de erro. caso de teste 1 deve demorar menos de um minuto. Com a inércia ido, torna-se fácil de forma incremental expandir sua cobertura de teste.
    • Agora evoluir seus testes com o seu código. Não se deixe intimidar pelo que o teste "correta" end-to-end seria parecido com servidores falsos e tudo isso. Código começa simples e evolui para lidar com casos novos; Os testes devem também. À medida que adiciona novos casos e nova complexidade ao seu código, casos de teste add para exercer o novo código. Como você encontrar bugs, adicionar verificações e / ou novos casos para cobrir o código falho. Quando você está depurando e confiança perder em um pedaço de código, voltar e adicionar testes para provar que ele está fazendo o que você pensa que é. cordas de captura de dados de exemplo (de outros serviços que você chama, sites que você raspar, qualquer que seja) e os alimentam a seu código de análise. Alguns casos aqui, a melhoria da validação de lá, e você vai acabar com código altamente confiável.

Além disso, confira o lista oficial do Nó recomendado. js módulos. No entanto, do GitHub nó módulos Wiki é muito mais completa e um bom recurso.

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

Node.js é evento com base e ASSÍNCRONO / NON-BLOCKING . Eventos, como uma conexão HTTP de entrada irá disparar uma função JavaScript que faz um pouco de trabalho e arranca outras tarefas assíncronas, como se conectar a um banco de dados ou puxar conteúdo de outro servidor. Uma vez que essas tarefas have sido expulso, a função de evento acabamentos e Node.js volta a dormir. Assim como qualquer outra coisa acontece, como a conexão de banco de dados que está sendo estabelecida ou o servidor externo respondendo com conteúdo, o fogo funções de retorno de chamada, e mais executa o código JavaScript, potencialmente dando início a tarefas ainda mais assíncrona (como uma consulta de banco de dados). Desta forma, Node.js irá atividades feliz intercalam para vários fluxos de trabalho paralelos, execução quaisquer atividades são desbloqueados em qualquer ponto no tempo. É por isso que Node.js faz um ótimo trabalho como gerenciar milhares de conexões simultâneas.

Por que não usar um processo / thread por conexão como todo mundo? Em Node.js, uma nova conexão é apenas uma alocação de pilha muito pequena. Girando-se um novo processo demora significativamente mais memória, um megabyte em algumas plataformas. Mas o custo real é a sobrecarga associada com o contexto-comutação. Quando você tem 10 ^ 6 threads do kernel, o kernel tem que fazer um monte de trabalho para descobrir quem deve executar seguinte. Um grupo de trabalho tem ido para a construção de um (1) programador O para Linux, mas no final, é a maneira como apenas mais eficiente ter um único processo orientado a eventos de 10 ^ 6 processos concorrentes para o tempo de CPU. Além disso, sob condições de sobrecarga, se comporta modelo multi-processo muito mal, faminta serviços de administração e gestão críticas, especialmente SSHD (ou seja, você não pode sequer entrar em caixa para descobrir como ferrou ele realmente é).

Node.js é único segmento e Lock Free . Node.js, como uma escolha de design muito deliberado só tem um único segmento por processo. Devido a isso, é fundamentalmente impossível para vários segmentos para acessar dados simultaneamente. Assim, não são necessários fechaduras. Threads são difíceis. Realmente muito difícil. Se você não acredita nisso, você não tiver feito a programação de rosca suficiente. Obtendo bloqueio direito é difícil e resulta em erros que são realmente difíceis de rastrear. Eliminando fechaduras e multi-threading faz uma das piores classes de erros simplesmente ir embora. Esta pode ser a única maior vantagem do nó.

Mas como faço para tirar proveito da minha casa 16 do núcleo?

Duas maneiras:

  1. Para tarefas grandes pesado de computação, como codificação de imagem, Node.js pode disparar até processos filhos ou mensagens Enviar a processos de trabalho adicionais. Neste projeto, você tem um segmento gerir o fluxo de eventos e N processos fazer tarefas pesadas de computação e mastigando os outros 15 CPUs.
  2. Para escalar o rendimento em um webservice, você deve executar vários servidores Node.js em uma caixa, um por núcleo, usando conjunto (Com Node.js v0.6.x, o funcionário "módulo de Cluster" ligada aqui substitui a versão LearnBoost que tem uma API diferente). Esses servidores locais Node.js pode competir em um soquete para aceitar novas conexões, balanceamento de carga entre eles. Depois que uma conexão é aceito, torna-se fortemente vinculado a um único desses processos compartilhados. Em teoria, isso soa mal, mas na prática ele funciona muito bem e permite-lhe evitar a dor de cabeça de escrever código thread-safe. Além disso, isto significa que Node.js recebe excelente afinidade cache da CPU, de forma mais eficaz utilizando a largura de banda de memória.

Node.js permite fazer algumas coisas realmente poderosos sem suar a camisa. Suponha que você tenha um programa Node.js que faz uma variedade de tarefas, escutas em um TCP porta para comandos, codifica algumas imagens, seja qual for. Com cinco linhas de código, você pode adicionar em um portal de gerenciamento de web HTTP baseado que mostra o estado atual de 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 bater um URL e verificar o status do seu processo de execução. Adicionar alguns botões, e você tem um "por gestãotal". Se você tem um funcionando Perl / Python / Ruby roteiro, apenas 'jogando em um portal de gestão' não é exatamente simples.

Mas não é JavaScript lento / mau / mal / desova-of-the-diabo? JavaScript tem algumas esquisitices estranhas, mas com "as partes boas" não há uma linguagem muito poderosa lá, e em qualquer caso, JavaScript é a linguagem no cliente (browser). JavaScript está aqui para ficar; outras línguas estão alvejando-o como um IL, e de classe mundial talento está competindo para produzir a maioria dos motores de JavaScript avançadas. Devido ao papel do JavaScript no navegador, uma enorme quantidade de esforço de engenharia está sendo jogado em fazer JavaScript super rápido. V8 é o mais recente e maior motor de javascript, pelo menos para este mês. Ele sopra longe as outras linguagens de script, tanto na eficiência e estabilidade (olhando para você, Ruby). E isso só vai ficar melhor com grandes equipes que trabalham no problema em Microsoft, Google e Mozilla, competindo para construir o melhor motor JavaScript (Não é mais um "intérprete" JavaScript como todos os motores modernos fazem toneladas de JIT compilar sob o capô com interpretação apenas como uma alternativa para executar-uma vez código). Sim, todos nós desejamos que pudéssemos corrigir algumas das mais estranhas escolhas linguagem JavaScript, mas não é realmente tão ruim assim. E a linguagem é tão danado flexível que você realmente não são codificação JavaScript, você está codificando Passo ou jQuery - mais do que qualquer outra língua, em JavaScript, as bibliotecas definir a experiência. Para aplicações web construir, você praticamente tem que saber JavaScript qualquer maneira, então a codificação com ele no servidor tem uma espécie de conjunto de habilidades sinergia. Ele me fez não teme escrever código do cliente.

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

Falando de JavaScript, o que é um "fechamento" -? Praticamente uma maneira elegante de dizer que você retenha variáveis ??escopo léxico nas cadeias de chamadas. ;) Como esta: 

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 apenas usar "myData" sem fazer nada estranho como stashing-lo em um objeto? E ao contrário de Java, a variável "myData" não tem que ser só de leitura. Este recurso de linguagem poderosa faz assíncrono de programação muito menos detalhadas e menos doloroso.

Escrevendo código assíncrono é sempre vai ser mais complexa do que escrever um script single-threaded simples, mas com Node.js, não é muito mais difícil e você terá uma série de 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 aplicações JavaScript independentes (entre outras coisas).

Node.js é simplesmente uma biblioteca escrita para V8 que não evented I / O. Este conceito é um complicado pouco para explicar, e eu tenho certeza que alguém vai responder com uma explicação melhor do que eu ... A essência é que em vez de fazer alguma entrada ou saída e esperando para que isso aconteça, você só don 't esperar que ela termine. Assim, por exemplo, para pedir a última vez editada de um arquivo: 

// Pseudo code
stat( 'somefile' )

Isso pode levar um par de milissegundos, ou pode demorar alguns segundos. Com evented I / O você simplesmente disparar o pedido e, em vez de esperar em torno de anexar um callback que é executado quando o pedido de acabamentos: 

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

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

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

Node.js é uma ferramenta de linha de comando de código aberto construído para o código JavaScript do lado do servidor. Você pode baixar uma tarball , compilar e instalar a fonte. Ele permite que você execute programas em JavaScript.

O JavaScript é executado pelo V8 , um motor JavaScript desenvolvido pelo Google que é usado em Chrome browser. Ele usa uma API JavaScript para acessar o sistema de rede e arquivo.

É popular por seu desempenho e a capacidade de executar operações paralelas.

Compreender node.js é o melhor explicação para node.js eu encontrei até agora.

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

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

O que isto significa para concurency é que você pode definir variáveis, em seguida, iniciar um nonblocking I / O função , e enviá-lo uma função anônima para o seu retorno.

Quando a tarefa for concluída, a função de retorno será executado no contexto com as variáveis, este é o fechamento.

Os fechamentos razão são tão boas para escrever aplicações com bloqueante I / O é que é muito fácil de gerir contexto de funções que executam de forma assíncrona.

exemplos Dois bons são sobre como você gerenciar modelos e usar melhorias progressivas com ele. Você só precisa de algumas peças leves de código JavaScript para fazê-lo funcionar perfeitamente.

Eu recomendo fortemente que você assistir e ler estes artigos:

Pegue qualquer idioma e tentar lembrar como você gerenciar seus modelos de arquivo HTML e o que tinha que fazer para atualizar um único CSS nome da classe em sua DOM estrutura (por exemplo, um usuário clicado em um item de menu e você quer que marcou como "selecionado" e atualizar o conteúdo da página).

Com Node.js é tão simples como fazer isso no lado do cliente de código JavaScript. Obtenha seu nó DOM e aplicar sua classe CSS para isso. Obtenha seu nó DOM e innerHTML seu conteúdo (você vai precisar de algum código JavaScript adicional para fazer isso. Leia o artigo para saber mais).

Outro bom exemplo, é que você pode fazer a sua página web compatível tanto com JavaScript ligado ou desligado com o mesmo pedaço de código. Imagine que você tem uma seleção de data feita em JavaScript que permitiria que os usuários de pegar qualquer data usando um calendário. Você pode escrever (ou utilização), o mesmo pedaço de código JavaScript para fazê-lo funcionar com o seu JavaScript ligado ou desligado.

Há uma muito boa rápido comida local analogia que melhor explica o modelo orientado a eventos de Node.js, consulte o artigo completo, Node.js, consultórios médicos e fast Food restaurantes - entendimento programação orientada a eventos

Aqui está um resumo:

Se o fast food conjunta seguiu um modelo tradicional baseado em threads, você pedir seu alimentos e esperar na fila até que você recebeu. A pessoa atrás de você não seria capaz de encomendar até que seu pedido foi feito. Em um modelo orientado a eventos, você pedir seu alimentos e, em seguida, sair da linha de espera. Todo mundo está então livre para ordem.

Node.js é orientada a eventos, mas a maioria dos servidores web são thread-based.York explica como Node.js funciona:

  • Você usa o seu navegador web para fazer um pedido de "/about.html" em um servidor web Node.js.

  • O servidor Node.js aceita o seu pedido e chama uma função para recuperar esse arquivo a partir do disco.

  • Enquanto o servidor Node.js está esperando para o arquivo a ser recuperado, ele serviços a próxima solicitação da web.

  • Quando o arquivo é recuperado, existe uma função de retorno de chamada que é inserido na fila de servidores Node.js.

  • executa servidor O Node.js que a função que neste caso seria processar a página "/about.html" e enviá-lo de volta para o seu navegador web ".

Bem, Eu entendo que

  • O objetivo da Node é fornecer uma maneira fácil construir programas de rede escaláveis.
  • Node é semelhante em design para e influenciado por sistemas como Máquina Evento de Ruby ou torcidas de Python.
  • Criando eventos I / O para V8 javascript.

Para mim, isso significa que você estava certo em todas as três hipóteses. Os olhares certeza biblioteca promissor!

Além disso, não se esqueça de mencionar que V8 do Google é muito rápido. Na verdade, converte o código JavaScript para código de máquina com o desempenho combinado de binário compilado. Então, juntamente com todos os outros grandes coisas, é insanamente rápido.

Q: O modelo de programação é orientado a eventos, especialmente a forma como ele lida com I / O .

Correto. Ele usa call-backs, portanto, qualquer solicitação para acessar o sistema de arquivos causaria um pedido para ser enviado para o sistema de arquivos e, em seguida, Node.js iria começar a processar seu próximo pedido. Ele só iria se preocupar com o pedido de I / O, uma vez que recebe uma volta resposta do sistema de arquivos, altura em que será executado o código de retorno de chamada. No entanto, é possível fazer solicitações de E / S síncrona (isto é, o bloqueio das solicitações). Cabe ao desenvolvedor escolher entre assíncronas (chamadas de retorno) ou síncrona (em espera).

Q:. Ele usa JavaScript e o analisador é V8

Sim

Q:. Ele pode ser facilmente usado para criar aplicativos de servidor simultâneas

Sim, embora você precisa de mão-código de um monte de JavaScript. Poderia ser melhor para olhar para um quadro, como http://www.easynodejs.com/ - que vem com documentação on-line completa e um exemplo de aplicativo.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top