¿Qué es Node.js? [cerrado]

Utilizo Node.js en el trabajo y lo encuentro muy poderoso. Obligado a elegir una palabra para describir Node.js, diría "interesante" (que no es un adjetivo puramente positivo). La comunidad es vibrante y está creciendo. JavaScript, a pesar de sus rarezas, puede ser un excelente lenguaje para codificar. Y diariamente repensará su propia comprensión de las "mejores prácticas" y los patrones de código bien estructurado. Hay una enorme energía de ideas fluyendo hacia Node.js en este momento, y trabajar en él te expone a todo este pensamiento: un gran levantamiento de pesas mental.

Node.js en producción es definitivamente posible, pero está lejos de la implementación "llave en mano" que aparentemente promete la documentación. Con Node.js v0.6.x, el "clúster" se ha integrado en la plataforma, proporcionando uno de los componentes básicos, pero mi script "production.js" todavía tiene ~150 líneas de lógica para manejar cosas como la creación del registro. directorio, reciclaje de trabajadores muertos, etc. Para un servicio de producción "serio", también debe estar preparado para acelerar las conexiones entrantes y hacer todo lo que hace Apache para PHP . Para ser justos, Ruby on Rails tiene exactamente este problema. Se resuelve mediante dos mecanismos complementarios: 1) Poner Ruby on Rails/Node.js detrás de un servidor web dedicado (escrito en C y probado hasta el infinito) como Nginx (o Apache / Lighttd ). El servidor web puede servir contenido estático de manera eficiente, acceder a registros, reescribir URL, finalizar SSL , hacer cumplir reglas de acceso y administrar múltiples subservicios. Para las solicitudes que llegan al servicio de nodo real, el servidor web envía la solicitud mediante proxy. 2) Usar un marco como Unicorn que administrará los procesos de trabajo, los reciclará periódicamente, etc. Todavía tengo que encontrar un marco de servicio de Node.js que parezca completamente preparado; puede que exista, pero aún no lo he encontrado y todavía uso ~150 líneas en mi "production.js" hecho a mano.

Leer marcos como Express hace que parezca que la práctica estándar es simplemente servir todo a través de un servicio Node.js multiuso... "app.use(express.static(__dirname + '/public'))" . Para servicios y desarrollo de menor carga, probablemente esté bien. Pero tan pronto como intente cargar su servicio a gran escala y ejecutarlo las 24 horas del día, los 7 días de la semana, descubrirá rápidamente las motivaciones que empujan a los sitios grandes a tener un código C bien preparado y reforzado, como Nginx , al frente de su sitio y manejando todo. de las solicitudes de contenido estático (...hasta que configure una CDN , como Amazon CloudFront )). Para una visión un tanto humorística y descaradamente negativa de esto, consulte a este tipo .

Node.js también encuentra cada vez más usos no relacionados con los servicios. Incluso si está usando otra cosa para servir contenido web, aún puede usar Node.js como herramienta de compilación, usando módulos npm para organizar su código, Browserify para unirlo en un solo activo y uglify-js para minimizarlo para su implementación. . Para trabajar con la web, JavaScript es una combinación de impedancia perfecta y, con frecuencia, eso lo convierte en la ruta de ataque más fácil. Por ejemplo, si desea arrastrarse a través de un montón de cargas útiles de respuesta JSON , debe usar mi módulo CLI de subrayado , el cinturón de utilidades de datos estructurados.

Pros contras:

• Ventaja: para un servidor, escribir JavaScript en el backend ha sido una "droga de entrada" para aprender patrones de interfaz de usuario modernos. Ya no temo escribir código de cliente.
• Ventaja: tiende a fomentar una verificación de errores adecuada (prácticamente todas las devoluciones de llamada devuelven err, lo que insta al programador a manejarlo; además, async.js y otras bibliotecas manejan el paradigma "fallar si alguna de estas subtareas falla" mucho mejor que el código síncrono típico )
• Ventaja: algunas tareas interesantes y normalmente difíciles se vuelven triviales, como obtener el estado de las tareas en curso, comunicarse entre trabajadores o compartir el estado de la caché.
• Ventaja: enorme comunidad y toneladas de excelentes bibliotecas basadas en un sólido administrador de paquetes (npm)
• Desventaja: JavaScript no tiene una biblioteca estándar. Te acostumbras tanto a importar funcionalidades que se siente extraño cuando usas JSON.parse o algún otro método integrado que no requiere agregar un módulo npm. Esto significa que hay cinco versiones de todo. Incluso los módulos incluidos en el "núcleo" de Node.js tienen cinco variantes más en caso de que no esté satisfecho con la implementación predeterminada. Esto conduce a una rápida evolución, pero también a cierto nivel de confusión.

Frente a un modelo simple de un proceso por solicitud ( LAMP ):

• Ventaja: escalable a miles de conexiones activas. Muy rápido y muy eficiente. Para una flota web, esto podría significar una reducción 10 veces mayor en el número de cajas necesarias en comparación con PHP o Ruby.
• Ventaja: escribir patrones paralelos es fácil. Imagine que necesita recuperar tres (o N) blobs de Memcached . Haga esto en PHP... ¿acaba de escribir el código que recupera el primer blob, luego el segundo y luego el tercero? Vaya, eso es lento. Hay un módulo PECL especial para solucionar ese problema específico de Memcached, pero ¿qué sucede si desea recuperar algunos datos de Memcached en paralelo con su consulta de base de datos? En Node.js, debido a que el paradigma es asincrónico, es muy natural que una solicitud web haga varias cosas en paralelo.
• Desventaja: el código asincrónico es fundamentalmente más complejo que el código sincrónico, y la curva de aprendizaje inicial puede ser difícil para los desarrolladores sin una comprensión sólida de lo que realmente significa la ejecución concurrente. Aún así, es mucho menos difícil que escribir cualquier tipo de código multiproceso con bloqueo.
• Desventaja: si una solicitud de cómputo intensivo se ejecuta durante, por ejemplo, 100 ms, detendrá el procesamiento de otras solicitudes que se estén manejando en el mismo proceso de Node.js... También conocido como multitarea cooperativa . Esto se puede mitigar con el patrón Web Workers (creando un subproceso para encargarse de la costosa tarea). Alternativamente, puede utilizar una gran cantidad de trabajadores de Node.js y dejar que cada uno solo maneje una única solicitud al mismo tiempo (aún es bastante eficiente porque no hay reciclaje de procesos).
• Desventaja: ejecutar un sistema de producción es MUCHO más complicado que un modelo CGI como Apache + PHP, Perl , Ruby , etc. Las excepciones no controladas detendrán todo el proceso, lo que requerirá lógica para reiniciar los trabajadores fallidos (consulte cluster ). Los módulos con código nativo defectuoso pueden bloquear el proceso. Cada vez que un trabajador muere, cualquier solicitud que estuviera manejando se descarta, por lo que una API con errores puede degradar fácilmente el servicio de otras API cohospedadas.

En lugar de escribir un servicio "real" en Java/C#/C (¿C? ¿En serio?)

• Ventaja: realizar operaciones asincrónicas en Node.js es más fácil que realizar tareas de seguridad para subprocesos en cualquier otro lugar y podría decirse que proporciona mayores beneficios. Node.js es, con diferencia, el paradigma asincrónico menos doloroso en el que he trabajado. Con buenas bibliotecas, es sólo un poco más difícil que escribir código sincrónico.
• Ventaja: sin errores de subprocesos múltiples/bloqueo. Es cierto que invierte por adelantado en escribir código más detallado que exprese un flujo de trabajo asincrónico adecuado sin operaciones de bloqueo. Y necesita escribir algunas pruebas y hacer que todo funcione (es un lenguaje de secuencias de comandos y los nombres de variables con dedos gruesos solo se detectan en el momento de la prueba unitaria). PERO, una vez que lo haces funcionar, la superficie de los errores heisen (problemas extraños que sólo se manifiestan una vez entre un millón de ejecuciones) es mucho menor. Los impuestos por escribir código Node.js se concentran en gran medida en la fase de codificación. Entonces tiendes a terminar con un código estable.
• Ventaja: JavaScript es mucho más liviano para expresar funcionalidad. Es difícil demostrar esto con palabras, pero JSON , escritura dinámica, notación lambda, herencia de prototipos, módulos livianos, lo que sea... simplemente tiende a requerir menos código para expresar las mismas ideas.
• Desventaja: ¿Quizás realmente te gustan los servicios de codificación en Java?

Para obtener otra perspectiva sobre JavaScript y Node.js, consulte De Java a Node.js , una publicación de blog sobre las impresiones y experiencias de un desarrollador de Java al aprender Node.js.

Módulos Al considerar node, tenga en cuenta que su elección de bibliotecas de JavaScript DEFINIRÁ su experiencia. La mayoría de la gente usa al menos dos, un asistente de patrón asincrónico (Step, Futures, Async) y un módulo de azúcar JavaScript ( Underscore.js ).

Ayudante / JavaScript Azúcar:

• Underscore.js : usa esto. Hazlo. Hace que su código sea agradable y legible con cosas como _.isString() y _.isArray(). No estoy muy seguro de cómo se podría escribir código seguro de otra manera. Además, para obtener una línea de comandos mejorada, consulte mi propio Underscore-CLI .

Módulos de patrones asíncronos:

• Paso - una forma muy elegante de expresar combinaciones de acciones en serie y paralelas. Mi recomendación personal. Vea mi publicación sobre cómo se ve el código de paso.
• Futuros : una forma mucho más flexible (¿es eso realmente algo bueno?) de expresar pedidos a través de requisitos. Puede expresar cosas como "comenzar a, b, c en paralelo. Cuando A y B terminen, comience AB. Cuando A y C terminen, comience AC". Esta flexibilidad requiere más cuidado para evitar errores en su flujo de trabajo (como no llamar nunca a la devolución de llamada o llamarla varias veces). Vea la publicación de Raynos sobre el uso de futuros (esta es la publicación que me hizo "obtener" futuros).
• Async : biblioteca más tradicional con un método para cada patrón. Comencé con esto antes de mi conversión religiosa al paso y la posterior comprensión de que todos los patrones en Async podrían expresarse en Paso con un único paradigma más legible.
• TameJS : escrito por OKCupid, es un precompilador que agrega un nuevo lenguaje primitivo "await" para escribir con elegancia flujos de trabajo en serie y paralelos. El patrón se ve increíble, pero requiere una compilación previa. Todavía estoy decidiéndome sobre esto.
• StreamlineJS : competidor de TameJS. Me inclino por Tame, pero tú puedes tomar tu propia decisión.

O para leer todo sobre las bibliotecas asincrónicas, consulte este panel de entrevista con los autores.

Marco web:

• Express Great Ruby on Rails-esk framework para organizar sitios web. Utiliza JADE como motor de plantillas XML/HTML, lo que hace que la creación de HTML sea mucho menos complicada, incluso casi elegante.
• jQuery Aunque técnicamente no es un módulo de nodo, jQuery se está convirtiendo rápidamente en un estándar de facto para la interfaz de usuario del lado del cliente. jQuery proporciona selectores similares a CSS para 'consultar' conjuntos de elementos DOM sobre los que luego se puede operar (controladores de conjuntos, propiedades, estilos, etc.). En la misma línea, el marco CSS Bootstrap de Twitter , Backbone.js para un patrón MVC y Browserify.js para unir todos sus archivos JavaScript en un solo archivo. Todos estos módulos se están convirtiendo en estándares de facto, por lo que al menos deberías consultarlos si no has oído hablar de ellos.

Pruebas:

• JSHint : debe usarse; Al principio no usé esto, lo que ahora parece incomprensible. JSLint agrega un montón de verificaciones básicas que se obtienen con un lenguaje compilado como Java. Paréntesis no coincidentes, variables no declaradas, tipos de muchas formas y tamaños. También puedes activar varias formas de lo que yo llamo "modo anal", donde verificas el estilo de los espacios en blanco y demás, lo cual está bien si eso es lo que te gusta, pero el valor real proviene de obtener información instantánea sobre el número de línea exacto donde olvidaste un ")" de cierre... sin tener que ejecutar tu código y presionar la línea ofensiva. "JSHint" es una variante más configurable de JSLint de Douglas Crockford .
• Competidor de Mocha para Vows, que estoy empezando a preferir. Ambos marcos manejan lo básico bastante bien, pero los patrones complejos tienden a ser más fáciles de expresar en Mocha.
• Vows Vows es realmente bastante elegante. E imprime un hermoso informe (--spec) que muestra qué casos de prueba pasaron/fallaron. Dedique 30 minutos a aprenderlo y podrá crear pruebas básicas para sus módulos con el mínimo esfuerzo.
• Zombie : pruebas sin cabeza para HTML y JavaScript utilizando JSDom como "navegador" virtual. Cosas muy poderosas. Combínelo con Replay para obtener pruebas deterministas ultrarrápidas del código del navegador.
• Un comentario sobre cómo "pensar en" las pruebas:
  • La prueba no es opcional. Con un lenguaje dinámico como JavaScript, existen muy pocas comprobaciones estáticas. Por ejemplo, pasar dos parámetros a un método que espera 4 no se interrumpirá hasta que se ejecute el código. Barra bastante baja para crear errores en JavaScript. Las pruebas básicas son esenciales para compensar la brecha de verificación con los lenguajes compilados.
  • Olvídese de la validación, simplemente haga que se ejecute su código. Para cada método, mi primer caso de validación es "nada se rompe", y ese es el caso que se activa con mayor frecuencia. Demostrar que su código se ejecuta sin errores detecta el 80% de los errores y hará tanto para mejorar la confianza de su código que se encontrará regresando y agregando los casos de validación matizados que omitió.
  • Empiece poco a poco y rompa la barrera de inercia. Todos somos vagos y estamos presionados por el tiempo, y es fácil ver las pruebas como un "trabajo extra". Así que empieza poco a poco. Escriba el caso de prueba 0: cargue su módulo e informe el éxito. Si se obliga a hacer esto, entonces se rompe la barrera inercial a las pruebas. Son <30 minutos para hacerlo la primera vez, incluida la lectura de la documentación. Ahora escriba el caso de prueba 1: llame a uno de sus métodos y verifique que "nada se rompa", es decir, que no reciba un error. El caso de prueba 1 debería llevarle menos de un minuto. Una vez eliminada la inercia, resulta fácil ampliar gradualmente la cobertura de las pruebas.
  • Ahora evolucione sus pruebas con su código. No se deje intimidar por cómo se vería la prueba "correcta" de un extremo a otro con servidores simulados y todo eso. El código comienza de manera simple y evoluciona para manejar nuevos casos; las pruebas también deberían hacerlo. A medida que agrega nuevos casos y nueva complejidad a su código, agregue casos de prueba para ejercitar el nuevo código. A medida que encuentre errores, agregue verificaciones y/o nuevos casos para cubrir el código defectuoso. Cuando esté depurando y pierda la confianza en un fragmento de código, regrese y agregue pruebas para demostrar que está haciendo lo que cree que hace. Capture cadenas de datos de ejemplo (de otros servicios a los que llame, sitios web que extraiga, lo que sea) e introdúzcalos en su código de análisis. Unos pocos casos aquí, una validación mejorada allí y terminará con un código altamente confiable.

Además, consulte la lista oficial de módulos Node.js recomendados. Sin embargo, la Wiki de módulos de nodo de GitHub es mucho más completa y es un buen recurso.

Para comprender Node, resulta útil considerar algunas de las opciones de diseño clave:

Node.js está BASADO en EVENTOS y es ASÍNCRONO / SIN BLOQUEO . Los eventos, como una conexión HTTP entrante, activarán una función de JavaScript que realiza un poco de trabajo e inicia otras tareas asincrónicas, como conectarse a una base de datos o extraer contenido de otro servidor. Una vez que se han iniciado estas tareas, la función de evento finaliza y Node.js vuelve a dormir. Tan pronto como sucede algo más, como que se establece la conexión de la base de datos o que el servidor externo responde con contenido, las funciones de devolución de llamada se activan y se ejecuta más código JavaScript, lo que potencialmente inicia aún más tareas asincrónicas (como una consulta de base de datos). De esta manera, Node.js intercalará felizmente actividades para múltiples flujos de trabajo paralelos, ejecutando cualquier actividad que esté desbloqueada en cualquier momento. Es por eso que Node.js hace un gran trabajo al administrar miles de conexiones simultáneas.

¿Por qué no utilizar simplemente un proceso/hilo por conexión como todos los demás? En Node.js, una nueva conexión es solo una asignación de montón muy pequeña. Poner en marcha un nuevo proceso requiere mucha más memoria, un megabyte en algunas plataformas. Pero el costo real son los gastos generales asociados con el cambio de contexto. Cuando tienes 10^6 subprocesos del kernel, el kernel tiene que trabajar mucho para determinar quién debe ejecutarse a continuación. Se ha trabajado mucho para crear un programador O(1) para Linux, pero al final, es mucho más eficiente tener un único proceso controlado por eventos que 10^6 procesos compitiendo por el tiempo de CPU. Además, en condiciones de sobrecarga, el modelo multiproceso se comporta muy mal, privando de servicios críticos de administración y gestión, especialmente SSHD (lo que significa que ni siquiera puedes iniciar sesión en el cuadro para descubrir qué tan jodido está realmente).

Node.js tiene un SOLO HILO y está LIBRE DE BLOQUEOS . Node.js, como elección de diseño muy deliberada, solo tiene un hilo por proceso. Debido a esto, es fundamentalmente imposible que varios subprocesos accedan a los datos simultáneamente. Por tanto, no se necesitan cerraduras. Los hilos son duros. Realmente muy difícil. Si no cree eso, no ha realizado suficiente programación con subprocesos. Lograr el bloqueo correcto es difícil y genera errores que son realmente difíciles de localizar. La eliminación de bloqueos y subprocesos múltiples hace que una de las clases de errores más desagradables simplemente desaparezca. Esta podría ser la mayor ventaja de node.

¿Pero cómo aprovecho mi caja de 16 núcleos?

Dos caminos:

1. Para tareas informáticas grandes y pesadas, como la codificación de imágenes, Node.js puede activar procesos secundarios o enviar mensajes a procesos de trabajo adicionales. En este diseño, tendría un subproceso que administraría el flujo de eventos y N procesos realizando tareas informáticas pesadas y consumiendo las otras 15 CPU.
2. Para escalar el rendimiento en un servicio web, debe ejecutar varios servidores Node.js en una caja, uno por núcleo, usando un clúster (con Node.js v0.6.x, el módulo oficial "cluster" vinculado aquí reemplaza la versión learnboost que tiene una API diferente). Estos servidores locales de Node.js pueden luego competir en un socket para aceptar nuevas conexiones, equilibrando la carga entre ellas. Una vez que se acepta una conexión, queda estrechamente vinculada a uno solo de estos procesos compartidos. En teoría, esto suena mal, pero en la práctica funciona bastante bien y le permite evitar el dolor de cabeza de escribir código seguro para subprocesos. Además, esto significa que Node.js obtiene una excelente afinidad de caché de CPU, utilizando de manera más efectiva el ancho de banda de la memoria.

Node.js te permite hacer cosas realmente poderosas sin sudar. Suponga que tiene un programa Node.js que realiza una variedad de tareas, escuchacomandos en un puerto TCP , codifica algunas imágenes, lo que sea. Con cinco líneas de código, puede agregar un portal de administración web basado en HTTP que muestra el estado actual de las tareas activas. Esto es fácil de hacer:

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");

Ahora puede acceder a una URL y verificar el estado de su proceso en ejecución. Agregue algunos botones y tendrá un "portal de administración". Si tiene un script Perl/Python/Ruby en ejecución, simplemente "incorporar un portal de administración" no es exactamente simple.

¿Pero no es JavaScript lento/malo/malvado/engendro del diablo? JavaScript tiene algunas rarezas extrañas, pero con "las partes buenas" hay un lenguaje muy poderoso y, en cualquier caso, JavaScript es EL lenguaje en el cliente (navegador). JavaScript llegó para quedarse; otros lenguajes lo consideran un IL y talentos de clase mundial compiten para producir los motores JavaScript más avanzados. Debido al papel de JavaScript en el navegador, se está realizando una enorme cantidad de esfuerzo de ingeniería para hacer que JavaScript sea increíblemente rápido. V8 es el último y mejor motor de JavaScript, al menos durante este mes. Supera a los otros lenguajes de programación tanto en eficiencia como en estabilidad (mirándote, Ruby). Y solo mejorará con grandes equipos trabajando en el problema en Microsoft, Google y Mozilla, compitiendo para construir el mejor motor de JavaScript (ya no es un "intérprete" de JavaScript, ya que todos los motores modernos realizan toneladas de compilación JIT bajo el capó con interpretación sólo como alternativa para el código de ejecución única). Sí, todos desearíamos poder corregir algunas de las opciones de lenguaje JavaScript más extrañas, pero en realidad no es tan malo. Y el lenguaje es tan flexible que realmente no estás codificando JavaScript, estás codificando Step o jQuery; más que cualquier otro lenguaje, en JavaScript, las bibliotecas definen la experiencia. Para crear aplicaciones web, es necesario conocer JavaScript de todos modos, por lo que codificar con él en el servidor tiene una especie de sinergia de habilidades. Ha hecho que no tenga miedo de escribir código de cliente.

Además, si REALMENTE odias JavaScript, puedes usar azúcar sintáctico como CoffeeScript . O cualquier otra cosa que cree código JavaScript, como Google Web Toolkit (GWT).

Hablando de JavaScript, ¿qué es un "cierre"? - Es una forma bastante elegante de decir que se conservan variables de alcance léxico en las cadenas de llamadas. ;) Como esto:

var myData = "foo";
database.connect( 'user:pass', function myCallback( result ) {
    database.query("SELECT * from Foo where id = " + myData);
} );
// Note that doSomethingElse() executes _BEFORE_ "database.query" which is inside a callback
doSomethingElse();

¿Ves cómo puedes usar "myData" sin hacer nada incómodo como esconderlo en un objeto? Y a diferencia de Java, la variable "myData" no tiene por qué ser de sólo lectura. Esta poderosa característica del lenguaje hace que la programación asincrónica sea mucho menos detallada y menos dolorosa.

Escribir código asincrónico siempre será más complejo que escribir un script simple de un solo subproceso, pero con Node.js no es mucho más difícil y obtienes muchos beneficios además de la eficiencia y escalabilidad para miles de conexiones simultáneas. ..

Jul 21 '2011 20:07 Dave Dopson