Falando sobre Node.js: Mas que diabos é isso?

Comentários

5 respostas para “Falando sobre Node.js: Mas que diabos é isso?”

1. 

   Marcelo Pereira

   julho 14, 2015

   Mr. legal tu falares sobre Node.js, uma tecnologia que vem ganhando adeptos. Porém, faltou mais pesquisa sobre o tema. Tu respondes a questão \”que diabos é isso?\” de maneira equivocada. Node.js é simplesmente uma máquina de execução. Esta tecnologia \”ganha\” poderes de um servidor a partir do momento em que tu te utilizas de módulos escritos pela comunidade para prover esta funcionalidade. Mas Node.js em si não é um servidor. É como se dissesse que a JVM é um servidor, quando na verdade os servidores de aplicação são aplicações construídas em cima da JVM. A JVM sozinha não faz nada. Daí eu não concordar com a sua comparação \”outros servidores vs. Node.js\”.
   Mas vamos dizer que o que tu quiseste dizer foi \”outros servidores vs. servidores construídos em Node.js\”. Tu colocas como se os outros servidores só ficam prontos para atender uma nova requisição uma vez que terminam de processar a primeira. Isto é um grande equívoco, uma vez que estes servidores que tu citas se utilizam de um thread-pool para processar várias requisições simultaneamente.
   O Node.js, por outro lado, não delega as requisições para um thread-pool. Se tu prestares atenção na referência que tu colocaste, o autor fala que o event loop delega tarefas de IO para o sistema operacional usando uma interface POSIX. Porém, todo o processamento no CPU é single-threaded (ao contrários dos outros servidores). A referência que você colocou inclusive mostra dicas para monitorar funções que podem estar \”blockando\” o event-loop, ou seja, não é o caso de o Node.js delegar a requisição e estar pronto para a próxima.
   Conclusão, Node.js é muito bom, mas gargalos e deadlocks nada têm a ver com utilizar outros servidores ou Node.js. Aplicações Node.js podem ter gargalos e a referência que você utilizou inclusive é sobre como preveni-los. A iniciativa foi muito boa, acho que você tinha que se aprofundar mais na tecnologia e enriquecer o blog com outros postos sobre o assunto. Curti a referência do \”event loop monitoring\”, já coloquei aqui nos meus favoritos.

   Um grande abraço!

   Responder
2. 

   Adalberto Júnior

   julho 14, 2015

   Salve Marcelo.
   Respondendo rapidão ao seu comentário:
   Concordo contigo que o Node.js não é um servidor, tanto que no segundo parágrafo eu deixo bem claro que é uma plataforma, que te fornece desde um interpretador de código ( V8 ) até uma boa API para desenvolvimento web de alta performance que internamente te permite instanciar um servidor ( vide o modulo nativo \”http\”). O que quis tentar explicar nesse post foi a forma diferente que a plataforma Node trabalha quando comparada com tecnologias \”tradicionais\” ( usemos como exemplo de comparação um servidor JavaEE ).

   Outro ponto que eu vou abrir debate é quando você cita a forma com a qual o Node trata as requisições. O que quis dizer é que cada thread de qualquer servidor \”tradicional\” que possui um thread pool precisa atender toda a request para estar disponível à atender outra.

   Com relação a single threading em node: Bem esse é o grande ponto de discussão nesse post. É válido dizer a plataforma Node é single threaded ? Sim ! A partir do momento em que você olha apenas pro event loop ( o que vai ser assunto de um próximo post ), mas quando esse evento loop recebe um evento onde existe uma função assíncrona ele cria um processo do teu sistema operacional, que acaba sendo tratada por uma thread, ou seja, ao invés de criar threads internas e ter de gerenciar elas na tua plataforma ele delega pro sistema operacional ! Mas não deixam de ser threads rodando em paralelo.

   Que bom que você gostou da referência que deixei, aqui embaixo tem mais uma do mesmo blog que fala exclusivamente sobre event loop:

   https://strongloop.com/strongblog/node-js-event-loop/

   E essa aqui é uma discussão que foi aberta no Stack Overflow sobre single threading em node.

   http://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded

   Pra fechar, cara… muito obrigado pela crítica, creio que explicamos muito mais coisa aqui nesse debate do que no próprio post em si. Creio que foruns como esses só fazem a gente se aprofundar e interessar mais pelo assunto.

   Valeu!

   Responder
3. 

   Marcelo Pereira

   julho 15, 2015

   Valeu pelas referências mr. Adalbert. Vou dar uma olhada nelas. Continue nessa pegada aí do Node.js. É trocando idéias que se chega longe. Abração!

   Responder
4. 

   Marco Balieiro

   julho 15, 2015

   Poxa tudo que eu ia apontar o Marcelo Pereira já falou. É isso mesmo Adalberto, ambos (servidores convencionais e servidores construídos com Node.js) processam requisições de forma simultânea, a diferença é o mecanismo (thread-pool ou single-thread com event loop).
   Esse mecanismo de event loop do Node.js é realmente o que faz com que ele possa tratar muito mais requisições simultâneas do que o conceito de thread-pool, pois usando thread-pool, ocorrem muitas trocas de contexto (preempção do processador) e demandam muito tempo de CPU com essas trocas.
   Muito boa a iniciativa e nos próximos posts você poderia falar sobre os diversos módulos do Node.JS (que o transformam desde um servidor web de páginas estáticas até servidores complexos com WebSockets ou Stream de vídeo).

   Grande Abraço!

   Responder
5. 

   Thiago Medeiros

   julho 28, 2015

   Realmente, curti para um post inicial foi bem Mr.

   Aguardo para ver a explicação mais detalhada do Event loop e threads assíncronas, que é o que acho mais legal na plataforma.

   E por último, só tenho a acrescentar que o Node.js nem é só um servidor (como dito anteriormente, pelo colega Marcelo Pereira), mas também não é atado a uma máquina virtual específica – há implementações do Node.js para várias VMs (Google V8, SpiderMonkey, JVM, .NET, etc), e o mesmo não é obrigatoriamente single-threaded (existe um fork chamado JXcore).

   Responder