¿Cómo se compara un “servidor” Node.js con los servidores Nginx o Apache?

He estado estudiando Node.js recientemente y encontré material sobre cómo escribir servidores simples basados ​​en Node.js. Por ejemplo, lo siguiente.

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!");
});

Ahora, aunque parece que entiendo lo que sucede en el código, estoy un poco confundido por la terminología. Cuando escucho el término servidor, pienso en cosas como Apache o Nginx. Estoy acostumbrado a pensar en ellos como un contenedor que puede contener mis aplicaciones web. ¿En qué se diferencia el servidor Node.js del servidor Nginx / Apache? ¿No es cierto que un servidor basado en Node.js (es decir, código) todavía se puede colocar dentro de algo como Nginx para ejecutarse? Entonces, ¿por qué ambos se llaman "servidores"?

Es un servidor, sí.

Una aplicación web node.js es un servidor web completo como Nginx o Apache.

De hecho, puede servir su aplicación node.js sin usar ningún otro servidor web. Simplemente cambie su código a:

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

De hecho, algunos proyectos utilizan node.js como balanceador de carga de front-end para otros servidores (incluido Apache).

Tenga en cuenta que node.js no es la única pila de desarrollo que hace esto. Los marcos de desarrollo web en Go, Java y Swift también hacen esto.

¿Por qué?

Al principio fue el CGI. CGI estuvo bien y funcionó bien. Apache obtendría una solicitud, encontraría que la URL necesita ejecutar una aplicación CGI, ejecutar esa aplicación CGI y pasar datos como variables de entorno, leer la salida estándar y devolver los datos al navegador.

El problema es que es lento. Está bien cuando la aplicación CGI era un pequeño programa C compilado estáticamente, pero un grupo de pequeños programas C compilados estáticamente se volvió difícil de mantener. Entonces la gente comenzó a escribir en lenguajes de programación. Entonces eso se volvió difícil de mantener y la gente comenzó a desarrollar marcos MVC orientados a objetos. Ahora comenzamos a tener problemas: CADA SOLICITUD debe compilar todas esas clases y crear todos esos objetos solo para servir algo de HTML, incluso si no hay nada dinámico que servir (porque el marco necesita descubrir que no hay nada dinámico que servir).

¿Qué pasa si no necesitamos crear todos esos objetos en cada solicitud?

Eso era lo que pensaba la gente. Y de intentar resolver ese problema surgieron varias estrategias. Uno de los primeros fue integrar intérpretes directamente en servidores web como mod_phpen Apache. Las clases y los objetos compilados se pueden almacenar en variables globales y, por lo tanto, se pueden almacenar en caché. Otra estrategia fue hacer una compilación previa. Y otra estrategia más fue ejecutar la aplicación como un proceso de servidor normal y hablar con el servidor web utilizando un protocolo personalizado como FastCGI.

Luego, algunos desarrolladores comenzaron a usar HTTP simplemente como su aplicación-> protocolo de servidor. De hecho, la aplicación también es un servidor HTTP. La ventaja de esto es que no necesita implementar ningún protocolo nuevo, posiblemente con errores, posiblemente no probado, y puede depurar su aplicación directamente usando un navegador web (o también comúnmente curl). Y no necesita un servidor web modificado para admitir su aplicación, solo cualquier servidor web que pueda realizar redirecciones o proxy inverso.

¿Por qué utilizar Apache / Nginx?

Cuando sirva una aplicación node.js, tenga en cuenta que es el autor de su propio servidor web. Cualquier error potencial en su aplicación es un error directamente explotable en Internet. Algunas personas (justificadamente) no se sienten cómodas con esto.

Agregar una capa de Apache o Nginx frente a su aplicación node.js significa que tiene una pieza de software de seguridad reforzada y probada en la batalla en Internet en vivo como una interfaz para su aplicación. Agrega un poco de latencia (el proxy inverso) pero la mayoría considera que vale la pena.

Este solía ser el consejo estándar en los primeros días de node.js. Pero en estos días también hay sitios y servicios web que exponen node.js directamente a Internet. El http.Servermódulo ahora está bastante bien probado en Internet para ser confiable.

NodeJs crea su propio servidor. Como puede ver, la terminología es bastante clara:

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

Cree un servidor y escuche las solicitudes http en el puerto 3000.

Usamos nginx en uno de nuestros proyectos, pero era más como un balanceador de carga para múltiples instancias de nodejs.

Supongamos que tiene dos instancias de nodejs que se ejecutan en el puerto 3000 y 3001, ahora aún puede usarlo nginxcomo servidor para escuchar sus httpllamadas reales port 80y es posible que desee redirigir su solicitud al nodejsservidor o tal vez a otro servidor, más como un loadbalancer. Así que todavía puedes usar lo que te nginxproporcione nodejs.

Una buena pregunta ya se hizo aquí .

Suponga que hay un hotel llamado Apache Hotel que tiene un camarero para cada cliente.

Tan pronto como el cliente pide una ensalada, el camarero se acerca al chef y le dice. Mientras el chef prepara la comida, el camarero espera. Aquí,

Chef => File System,

Waiter => Thread,

Customer => Event.

Incluso cuando el cliente pide agua, el camarero trae solo después de servir la ensalada. El camarero sigue esperando hasta que el chef prepara la ensalada. Este estado se conoce como estado de bloqueo. Incluso si el hotel crece, cada cliente debe tener diferentes camareros para atender. Esto aumenta el bloqueo de hilos (meseros).

Ahora, al llegar a Node Hotel solo hay un camarero para todos los clientes. Si el primer cliente pide sopa, el camarero se lo dice al chef y se dirige al segundo cliente. Una vez que la comida está lista, el camarero se la entrega al cliente. Aquí el cliente no esperará. Este estado se conoce como estado sin bloqueo. El camarero único (Thread) atiende a todos los clientes y los hace felices.

Por lo tanto, Node, que es una aplicación de un solo subproceso, es muy rápido.