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

86

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"?

javascript  node.js  apache  nginx  webserver 
— Agradecido
fuente
2
Isn't it true that a Node.js based server (i.e. code) will still be placed within something like Nginx to run?No, eso es incorrecto
— Jaromanda X
1
técnicamente, puede ejecutar su aplicación y hacer que el nodo la sirva al cliente cumpliendo efectivamente el rol del servidor web, pero probablemente esté mordiendo más de lo que quiere masticar. Recientemente leí este gran artículo sobre el tema: nginx.com/blog/nginx-vs-apache-our-view
— datafunk
1
Permítanme aclarar que cuando pregunté por la diferencia entre los dos, NO estaba hablando de apache vs nginx. Estaba hablando de Node.js vs Nginx.
— Agradecido
1
No dejes que el título te engañe. Si lees el artículo, entenderás por qué dije que si bien puedes hacerlo tú mismo, es posible que no quieras ...
— datafunk

Respuestas:

128

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.

— slebetman
fuente
1
He leído en subprocesos SO similares que poner una capa Nginx o Apache delante de Node "quita su naturaleza de no bloqueo". Tiene alguna idea sobre esto?
— MrfksIV
3
@MrfksIV Tanto Nginx como Apache2 no son bloqueantes. De hecho, implementaron el no bloqueo mucho antes de que existiera node.js. No use Apache1
— slebetman
14

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í .

— Naeem Shaikh
fuente
1
En realidad, no estoy demasiado concentrado en nginx en sí. Me preguntaba acerca de la diferencia entre el "servidor" de node.js y los otros "servidores" como apache o nginx. No pude entender cómo el contenido (es decir, el código de nodo) podría equipararse al contenedor (es decir, apache) ... Pero supongo que esta comprensión fue incorrecta. Ahora, me doy cuenta de que el código node.js escucha el puerto 3000 al igual que Apache escucha el puerto 80 ... Así que supongo que son similares. Entonces, ¿es cierto decir que ambos son servidores que tienen sus propias fortalezas y debilidades?
— Agradecido
2
createServer simplemente crea un puerto de escucha. No sirve de nada.
— Roger
1
¿Cuál sería el punto de que nodejs use createServer para escuchar en un puerto si no va a servir algo a una solicitud a ese puerto? ... Por tanto, es de una forma u otra por extensión lógica un "servidor", ¿no?
— GG2
@ RogerF.Gay ... crea un oyente en un puerto especificado y ejecuta una función de devolución de llamada en una solicitud entrante. eso es lo que yo diría que crea un servidor.
— Naeem Shaikh
1
@Naeem Shaikh No sirve de nada. Llamar servidor a algo que no sirve para nada no tiene sentido.
— Roger
1

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.

— Vamshi Krishna
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.