Como um “servidor” Node.js se compara aos servidores Nginx ou Apache?

Tenho estudado Node.js recentemente e encontrei algum material sobre como escrever servidores simples baseados em Node.js. Por exemplo, o seguinte.

var express = require("express"),
http = require("http"), app;

// Create our Express-powered HTTP server
// and have it listen on port 3000
app = express();
http.createServer(app).listen(3000);

// set up our routes
app.get("/hello", function (req, res) {
    res.send("Hello World!");
});

app.get("/goodbye", function (req, res) {
    res.send("Goodbye World!");
});

Agora, embora eu pareça entender o que está acontecendo no código, estou um pouco confuso com a terminologia. Quando ouço o termo servidor, penso em coisas como Apache ou Nginx. Estou acostumado a pensar neles como um contêiner que pode conter meus aplicativos da web. Como o servidor Node.js difere do servidor Nginx / Apache? Não é verdade que um servidor baseado em Node.js (ou seja, código) ainda pode ser colocado em algo como o Nginx para ser executado? Então, por que ambos são chamados de "servidores"?

É um servidor, sim.

Um aplicativo da web node.js é um servidor da web completo, como o Nginx ou o Apache.

Você pode realmente servir seu aplicativo node.js sem usar qualquer outro servidor web. Basta alterar seu código para:

app = express();
http.createServer(app).listen(80); // serve HTTP directly

De fato, alguns projetos usam node.js como balanceador de carga de front-end para outros servidores (incluindo Apache).

Observe que node.js não é a única pilha de desenvolvimento a fazer isso. Estruturas de desenvolvimento da Web em Go, Java e Swift também fazem isso.

Por quê?

No começo era o CGI. CGI estava bem e funcionou bem. O Apache obteria uma solicitação, descobriria que a url precisa executar um aplicativo CGI, executar esse aplicativo CGI e passar dados como variáveis ​​de ambiente, ler o stdout e servir os dados de volta ao navegador.

O problema é que ele é lento. Não há problema quando o aplicativo CGI é um pequeno programa C compilado estaticamente, mas torna-se difícil manter um grupo de pequenos programas C compilados estaticamente. Então, as pessoas começaram a escrever em linguagens de script. Então isso se tornou difícil de manter e as pessoas começaram a desenvolver frameworks MVC orientados a objetos. Agora começamos a ter problemas - CADA PEDIDO deve compilar todas essas classes e criar todos esses objetos apenas para servir a algum HTML, mesmo que não haja nada dinâmico para servir (porque o framework precisa descobrir que não há nada dinâmico para servir).

E se não precisarmos criar todos esses objetos a cada solicitação?

Isso foi o que as pessoas pensaram. E da tentativa de resolver esse problema surgiram várias estratégias. Uma das primeiras foi incorporar intérpretes diretamente em servidores web, como mod_phpno Apache. Classes e objetos compilados podem ser armazenados em variáveis ​​globais e, portanto, em cache. Outra estratégia foi fazer uma pré-compilação. E ainda outra estratégia era executar o aplicativo como um processo de servidor regular e conversar com o servidor da web usando um protocolo personalizado como FastCGI.

Então, alguns desenvolvedores começaram simplesmente a usar HTTP como seu protocolo de aplicativo-> servidor. Na verdade, o aplicativo também é um servidor HTTP. A vantagem disso é que você não precisa implementar nenhum protocolo novo, possivelmente com erros, possivelmente não testado, e pode depurar seu aplicativo diretamente usando um navegador da web (ou também comumente curl). E você não precisa de um servidor web modificado para dar suporte ao seu aplicativo, apenas qualquer servidor web que possa fazer proxy reverso ou redirecionamentos.

Por que usar Apache / Nginx?

Ao servir um aplicativo node.js, observe que você é o autor de seu próprio servidor web. Qualquer bug potencial em seu aplicativo é um bug diretamente explorável na Internet. Algumas pessoas (com razão) não se sentem confortáveis ​​com isso.

Adicionar uma camada de Apache ou Nginx na frente de seu aplicativo node.js significa que você tem um software testado para batalha e com segurança reforçada na Internet ao vivo como uma interface para seu aplicativo. Ele adiciona um pouco de latência (o proxy reverso), mas a maioria considera que vale a pena.

Esse costumava ser o conselho padrão nos primeiros dias do node.js. Mas hoje em dia também existem sites e serviços da web que expõem o node.js diretamente para a Internet. O http.Servermódulo agora foi bem testado em batalhas na Internet para ser confiável.

NodeJs cria seu próprio servidor. Como você pode ver, a terminologia é bastante clara:

http.createServer(app).listen(3000);

Crie um servidor e escute as solicitações de http na porta 3000.

Usamos o nginx em um de nossos projetos, mas era mais como um balanceador de carga para várias instâncias de nodejs.

Digamos que você tenha duas instâncias de nodejs em execução na porta 3000 e 3001. Agora você ainda pode usar nginxcomo um servidor para ouvir suas httpchamadas reais port 80e pode querer redirecionar sua solicitação para o nodejsservidor ou talvez algum outro servidor, mais como um loadbalancer. Portanto, você ainda pode usar o que for nginxfornecido nodejs.

Uma boa pergunta já feita aqui .

Suponha que haja um hotel chamado Apache Hotel que tenha um garçom para cada cliente.

Assim que o cliente pede uma salada, o garçom vai até o chef e avisa. Enquanto o chef prepara a comida, o garçom espera. Aqui,

Chef => File System,

Waiter => Thread,

Customer => Event.

Mesmo quando o cliente pede água, o garçom só traz depois de servir a salada. O garçom fica esperando até que a salada seja preparada pelo chef. Este estado é conhecido como estado de bloqueio. Mesmo que o hotel cresça, cada cliente deve ter garçons diferentes para servir. Isso aumenta o bloqueio de threads (waiters).

Agora, chegando ao Node Hotel, há apenas um garçom para todos os clientes. Se o primeiro cliente pedir sopa, o garçom informa o chef e vai para o segundo cliente. Depois que a comida está pronta, o garçom entrega ao cliente. Aqui o cliente não espera. Este estado é conhecido como estado de não bloqueio. O único garçom (Thread) atende todos os clientes e os deixa felizes.

Portanto, o Node, que é um aplicativo de thread único, é muito rápido.