Node, para que ele serve e para que ele é bom ou não.
Para o que ele é bom
O Node é extremamente bem projetado para situações em que um grande volume de tráfego é esperado e a lógica e o processamento necessários do lado do servidor não são necessariamente volumosos antes de responder ao cliente.
Seguindo os textos(copiados das fontes citadas abaixo), que muito bem exemplificam.
Para que ele serve:
Uma API RESTful
Um serviço da Web que forneça uma API RESTful recebe alguns parâmetros, interpreta-os, monta uma resposta e envia-a (normalmente uma quantidade relativamente pequena de texto) de volta ao usuário. Esta é uma situação ideal para o Node, pois você poderá criá-lo para tratar dezenas de milhares de conexões. Ela também não requer um grande volume de lógica; ela simplesmente procura valores em um banco de dados e monta uma resposta. Como a resposta é uma pequena quantidade de texto e a solicitação de entrada é uma pequena quantidade de texto, o volume de tráfego não é grande, e um computador poderá provavelmente tratar as demandas de API mesmo da API da empresa mais movimentada.
Pense em uma empresa como a Twitter, que precisa receber tweets e gravá-los em um banco de dados. Existem literalmente milhares de tweets chegando a cada segundo e o banco de dados não consegue acompanhar o número de gravações necessárias durante os momentos de pico de uso. O Node torna-se uma engrenagem importante na solução deste problema. Como vimos, o Node consegue tratar dezenas de milhares de tweets que chegam. Ele pode gravá-los rápida e facilmente em um mecanismo de enfileiramento em memória (memcached, por exemplo), a partir do qual outro processo separado pode gravá-los no banco de dados. A função do Node é rapidamente coletar o tweet e passar essa informação para outro processo, responsável por gravá-lo. Imagine outro projeto — um servidor PHP normal que tenta tratar gravações no banco de dados em si — cada tweet causaria um pequeno atraso ao ser gravado pelo banco de dados, pois a chamada ao banco de dados estaria sendo bloqueada. Uma máquina com este design só poderia ser capaz de tratar 2000 tweets por segundo, devido à latência do banco de dados. Um milhão de tweets por segundo requer 500 servidores. O Node, em vez disso, trata cada conexão e não bloqueia, possibilitando que ele capture o máximo de tweets possível. Uma máquina com Node, capaz de tratar 50.000 tweets por segundo, requer somente 20 servidores.
Servidor de arquivos de imagem
Uma empresa que tem um grande Web site distribuído (pense no Facebook ou Flickr) poderia decidir dedicar servidores inteiros a simplesmente servir imagens. O Node seria uma boa solução para esse problema, pois a empresa pode usá-lo para codificar um recuperador de arquivos fácil e, a seguir, tratar dezenas de milhares de conexões. O Node procuraria pelo arquivo de imagem, retornaria o próprio arquivo ou um erro 404 e não faria mais nada. Essa configuração permitiria que esses tipos de Web sites distribuídos reduzissem o número de servidores necessários para servir arquivos estáticos, como imagens, arquivos .js e arquivos .css.
Para o que ele não serve
É claro, o Node não é a escolha ideal em algumas situações. Eis alguns cenários em que o Node não seria bom:
Páginas criadas dinamicamente
Atualmente, o Node não fornece uma forma padrão para criar páginas dinâmicas. Por exemplo, ao usar a tecnologia JavaServer Pages (JSP), é possível criar uma página index.jsp que contenha loops em snippers JSP, como <% for (int i=0; i<20; i++) { } %>. O Node não permite esses tipos de páginas dinâmicas direcionadas a HTML. Novamente, o Node não é idealmente adequado para ser um servidor de páginas da web, como o Apache e o Tomcat o são. Portanto, se quisesse fornecer uma solução no lado do servidor para isto no Node, teria que codificar a solução inteira você mesmo. Um programador PHP não gostaria de programar um conversor PHP para o Apache toda vez que implementasse um aplicativo da web, mas, neste momento, é o que o Node exigiria que você fizesse.
Aplicativos pesados em bancos de dados relacionais
O Node foi projetado para ser rápido, assíncrono e sem bloqueio. Os bancos de dados não necessariamente compartilham desses objetivos. Eles são síncronos e com bloqueio, pois chamadas ao banco de dados para leitura e gravação bloqueiam até que um resultado seja gerado. Portanto, um aplicativo da Web que solicite muitas chamadas ao banco de dados, muitas leituras e muitas gravações com cada solicitação seria uma aplicação ruim para o Node, pois o banco de dados relacional em si estaria negando muitos dos pontos fortes do Node. (Os novos bancos de dados NoSQL são uma escolha melhor para o Node, mas este é um tópico totalmente diferente).
Fonte(s):
http://nodejs.org
http://nodebr.com
http://www.ibm.com/developerworks/br/library/os-nodejs/
Ederson Melo 