507 votos

¿Qué es Node.JS?

No entiendo del todo lo que Node.JS es todo. Tal vez sea porque soy principalmente un desarrollador de aplicaciones empresariales basadas en la web. ¿Qué es y para qué sirve?

Lo que entiendo hasta ahora es que:

  1. El modelo de programación está orientado a los eventos, especialmente la forma en que maneja E/S .
  2. Utiliza JavaScript y el parser es V8 .
  3. Puede utilizarse fácilmente para crear aplicaciones de servidor concurrentes.

¿Es correcto lo que he entendido? Si es así, ¿cuáles son los beneficios de la E/S con eventos, es sólo para las cosas de concurrencia? También, ¿es la dirección de Node.JS para convertirse en un marco como, modelo de programación basado en JavaScript (basado en V8)?

618voto

Dave Dopson Puntos 16690

Utilizo Node.JS en el trabajo, y lo encuentro muy potente. Si tuviera que 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 gran lenguaje para codificar. Y diariamente te replantearás tu propia comprensión de las "mejores prácticas" y los patrones del código bien estructurado. Hay una enorme energía de ideas que fluyen en 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 del despliegue "llave en mano" que aparentemente promete la documentación. Con Node.JS v0.6.x, el "cluster" se ha integrado en la plataforma, proporcionando uno de los bloques de construcción esenciales, pero mi "production.JS" script sigue siendo ~150 líneas de lógica para manejar cosas como la creación del directorio de registro, el reciclaje de trabajadores muertos, etc. Para un servicio de producción "serio", también hay que estar preparado para estrangular las conexiones entrantes y hacer todas las cosas que Apache hace para PHP . Para ser justos, Ruby on Rails tiene esto exactamente problema. Se resuelve a través de dos mecanismos complementarios: 1) Poner Ruby on Rails/Node.JS detrás de un servidor web dedicado (escrito en C y probado hasta la saciedad) como Nginx (o Apache / Lighttd ). El servidor web puede servir eficazmente contenidos estáticos, acceder al registro, reescribir URLs, terminar SSL , aplicar reglas de acceso y gestionar múltiples subservicios. En el caso de las solicitudes que llegan al servicio del nodo real, el servidor web las hace pasar. 2) Utilizar un marco de trabajo como Unicornio que gestionará los procesos de los trabajadores, los reciclará periódicamente, etc. Todavía no he encontrado un marco de trabajo de servicio de Node.JS que parezca completamente horneado; puede existir, pero todavía no lo he encontrado y todavía uso ~150 líneas en mi "production.JS" enrollado a mano.

Marcos de lectura como Expreso hace que parezca que la práctica estándar es simplemente servir todo a través de un servicio Node.JS de todo tipo ... "app.use(express.static(__dirname + '/public'))". Para los servicios de menor carga y el desarrollo, eso probablemente esté bien. Pero tan pronto como intentes poner una gran carga en tu servicio y tenerlo funcionando 24/7, descubrirás rápidamente las motivaciones que empujan a los grandes sitios a tener un código C bien horneado y endurecido como Nginx que se encargue de su sitio y de todas las solicitudes de contenido estático (...hasta que se configure un CDN como Amazon CloudFront )). Para una visión algo humorística y descaradamente negativa de esto, véase este tipo .

Node.JS también está encontrando cada vez más usos no relacionados con el servicio. Incluso si usted está utilizando algo más para servir el contenido web, usted todavía podría utilizar Node.JS como una herramienta de construcción, utilizando npm para organizar su código, Browserify para unirlo en un solo activo, y uglify-JS para minificarla para su despliegue. Para tratar con la web, JavaScript es un perfecto coincidencia de impedancia y con frecuencia eso hace que sea la vía de ataque más fácil. Por ejemplo, si quieres arrastrarte por un montón de JSON cargas útiles de respuesta, debe utilizar mi underscore-CLI módulo, el cinturón de utilidad de los datos estructurados.

Pros / Contras:

  • Pro: Para un tipo de servidor, escribir JavaScript en el backend ha sido una "droga de entrada" para aprender patrones modernos de interfaz de usuario. Ya no me da miedo escribir código de cliente.
  • Pro: Tiende a fomentar la comprobación de errores adecuada (err es devuelto por prácticamente todas las devoluciones de llamada, lo que obliga al programador a manejarlo; además, async.JS y otras bibliotecas manejan el paradigma de "fallar si alguna de estas subtareas falla" mucho mejor que el típico código síncrono)
  • Pro: Algunas tareas interesantes y normalmente difíciles se convierten en triviales, como obtener el estado de las tareas en vuelo, comunicarse entre trabajadores o compartir el estado de la caché.
  • Pro: Enorme comunidad y toneladas de grandes bibliotecas basadas en un sólido gestor de paquetes (npm)
  • Contra: JavaScript no tiene una biblioteca estándar. Uno se acostumbra tanto a importar funcionalidades que se siente raro cuando usa JSON.parse o algún otro método de construcción 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 por si no estás contento con la implementación por defecto. 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 ( LÁMPARA ):

  • Pro: Escalable a miles de conexiones activas. Muy rápido y muy eficiente. Para una flota web, esto podría significar una reducción de 10 veces en el número de cajas necesarias frente a PHP o Ruby
  • Pro: Escribir patrones paralelos es fácil. Imagina que necesitas obtener tres (o N) blobs de Memcached . Haz esto en PHP... ¿acabas de escribir el código que obtiene el primer blob, luego el segundo, luego el tercero? Vaya, eso es lento. Hay un PECL para solucionar ese problema específico de Memcached, pero ¿qué pasa si quieres obtener algunos datos de Memcached en paralelo con tu consulta a la base de datos? En Node.JS, debido a que el paradigma es asíncrono, hacer que una petición web haga varias cosas en paralelo es muy natural.
  • Contra: El código asíncrono es fundamentalmente más complejo que el código síncrono, y la curva de aprendizaje inicial puede ser difícil para los desarrolladores que no tengan un conocimiento sólido de lo que significa la ejecución concurrente. Aun así, es mucho menos difícil que escribir cualquier tipo de código multihilo con bloqueo.
  • Contra: Si una solicitud de cálculo intensivo se ejecuta durante, por ejemplo, 100 ms, se detendrá el procesamiento de otras solicitudes que se están manejando en el mismo proceso Node.JS ... TAMBIÉN CONOCIDO COMO, cooperativa-multitarea . Esto se puede mitigar con el patrón de los Web Workers (girando un subproceso para ocuparse de la costosa tarea). Alternativamente, se puede utilizar un gran número de trabajadores Node.JS y dejar que cada uno maneje una sola solicitud de forma concurrente (sigue siendo bastante eficiente porque no hay reciclaje de procesos).
  • Con: El funcionamiento de un sistema de producción es MUCHO más complicado que un CGI modelo como Apache + PHP, Perl , Ruby etc. Las excepciones no manejadas harán caer todo el proceso, necesitando la lógica para reiniciar los trabajadores fallidos (ver grupo ). Los módulos con código nativo defectuoso pueden hacer fracasar el proceso. Cada vez que un trabajador muere, las solicitudes que estaba manejando se eliminan, por lo que una API con errores puede degradar fácilmente el servicio para otras APIs co-alojadas.

Frente a escribir un servicio "real" en Java / C# / C (¿C? ¿en serio?)

  • Pro: Hacer asíncrono en Node.JS es más fácil que hacer seguridad de hilos en cualquier otro lugar y podría decirse que proporciona un mayor beneficio. Node.JS es de lejos el paradigma asíncrono menos doloroso en el que he trabajado. Con buenas bibliotecas, es sólo ligeramente más difícil que escribir código síncrono.
  • Pro: No hay errores de multihilo/bloqueo. Es cierto que hay que invertir por adelantado en escribir un código más verboso que exprese un flujo de trabajo asíncrono adecuado sin operaciones de bloqueo. Y tienes que escribir algunas pruebas y conseguir que la cosa funcione (es un lenguaje de scripting y la digitación de los nombres de las variables sólo se detecta en el momento de las pruebas unitarias). PERO, una vez que consigues que funcione, la superficie de heisenbugs -- problemas extraños que sólo se manifiestan una vez en un millón de carreras -- esa superficie es simplemente mucho más baja. Los impuestos al escribir código Node.JS están muy cargados en la fase de codificación. Entonces tiendes a terminar con un código estable.
  • Pro: JavaScript es mucho más ligero para expresar la funcionalidad. Es difícil demostrarlo con palabras, pero JSON El uso de la tecnología de la información, la tipificación dinámica, la notación lambda, la herencia prototípica, los módulos ligeros, lo que sea... sólo tiende a tomar menos código para expresar las mismas ideas.
  • Contra: ¿Quizás te gusta mucho codificar servicios en Java?

Si desea conocer otra perspectiva de JavaScript y Node.JS, consulte De Java a Node.JS un blog sobre las impresiones y experiencias de un desarrollador de Java aprendiendo Node.JS.


Módulos Al considerar el nodo, tenga en cuenta que su elección de las bibliotecas de JavaScript DEFINIR su experiencia. La mayoría de la gente utiliza al menos dos, un ayudante de patrón asíncrono (Step, Futures, Async), y un módulo de azúcar de JavaScript ( Underscore.JS ).

Ayudante / Azúcar JavaScript:

  • Underscore.JS - utiliza esto. Simplemente hazlo. Hace que tu código sea agradable y legible con cosas como _.isString(), y _.isArray(). No estoy seguro de cómo podrías escribir código seguro de otra manera. Además, para mejorar la línea de comandos, echa un vistazo a mi propio Underscore-CLI .

Módulos de patrones asíncronos:

  • Paso - una forma muy elegante de expresar combinaciones de acciones en serie y en paralelo. Mi recomendación personal. Ver mi puesto sobre el aspecto del código del Paso.
  • Futuros - Una forma mucho más flexible (¿es eso realmente algo bueno?) de expresar los pedidos a través de los requisitos. Puede expresar cosas como "empezar a, b, c en paralelo. Cuando A y B terminen, empieza AB. Cuando A, y C terminan, empieza AC". Tal flexibilidad requiere más cuidado para evitar errores en su flujo de trabajo (como no llamar nunca al callback, o llamarlo varias veces). Véase El puesto de Raynos sobre el uso de futuros (este es el post que me hizo "entender" los futuros).
  • Async - biblioteca más tradicional con un método para cada patrón. Empecé con esto antes de mi conversión religiosa a Step y la posterior comprensión de que todos los patrones en Async podrían expresarse en Step con un único paradigma más legible.
  • TameJS - Escrito por OKCupid, es un precompilador que añade un nuevo lenguaje primitivo "await" para escribir elegantemente flujos de trabajo en serie y en paralelo. El patrón parece increíble, pero requiere precompilación. Todavía estoy pensando en esto.
  • StreamlineJS - competidor de TameJS. Me inclino por Tame, pero puedes decidir por ti mismo.

O para leer todo sobre las bibliotecas asíncronas, consulte este panel-entrevista con los autores.

Marco web:

  • Expreso Gran framework Ruby on Rails-esk para organizar sitios web. Utiliza JADE como un motor de plantillas XML/HTML, que hace que la construcción de HTML sea mucho menos dolorosa, casi elegante incluso.
  • 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 los de CSS para "consultar" conjuntos de elementos del DOM sobre los que se puede operar (establecer manejadores, propiedades, estilos, etc.). En la misma línea, el programa de Twitter Bootstrap Marco CSS, Backbone.JS para un MVC patrón, y Browserify.JS para unir todos sus archivos JavaScript en un solo archivo. Estos módulos se están convirtiendo en estándares de facto, por lo que deberías echarle un vistazo si no has oído hablar de ellos.

Pruebas:

  • JSHint - Debe usarse; al principio no lo usé, lo que ahora me parece incomprensible. JSLint vuelve a añadir un montón de verificaciones básicas que obtienes con un lenguaje compilado como Java. Paréntesis no coincidentes, variables no declaradas, typeos 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 es tu taza de té -- pero el valor real viene de obtener información instantánea sobre el número exacto de línea donde olvidaste un ")" de cierre ... sin tener que ejecutar su código y golpear la línea ofensiva. "JSHint" es una variante más configurable de Douglas Crockford 's JSLint .
  • Moca competidor de Vows que estoy empezando a preferir. Ambos frameworks manejan lo básico bastante bien, pero los patrones complejos tienden a ser más fáciles de expresar en Mocha.
  • Votos Vows es realmente muy elegante. E imprime un informe encantador (--spec) que muestra los casos de prueba que han sido aprobados o fallados. Dedica 30 minutos a aprenderlo y podrás crear pruebas básicas para tus módulos con un esfuerzo mínimo.
  • Zombie - Pruebas sin cabeza para HTML y JavaScript con JSDom como un "navegador" virtual. Un material muy potente. Combínalo con Replay para obtener pruebas deterministas a la velocidad del rayo del código dentro del navegador.
  • Un comentario sobre cómo "pensar en" las pruebas:
    • Las pruebas no son opcionales. Con un lenguaje dinámico como JavaScript, hay muy algunas comprobaciones estáticas. Por ejemplo, pasar dos parámetros a un método que espera 4 no se romperá hasta que se ejecute el código. Un listón bastante bajo para crear bugs en JavaScript. Las pruebas básicas son esenciales para compensar la brecha de verificación con los lenguajes compilados.
    • Olvídate de la validación, sólo haz que tu código se ejecute. Para cada método, mi primer caso de validación es "nada se rompe", y ese es el caso que se dispara más a menudo. Probar que tu código se ejecuta sin tirar atrapa el 80% de los errores y hará tanto para mejorar la confianza en tu código que te encontrarás volviendo y añadiendo los casos de validación matizados que te has saltado.
    • Empieza de a poco y rompe la barrera de la inercia. Todos somos perezosos y estamos presionados por el tiempo, y es fácil ver las pruebas como un "trabajo extra". Así que empiece con algo pequeño. Escriba el caso de prueba 0: cargue su módulo e informe del éxito. Si te obligas a hacer sólo esto, entonces se rompe la barrera inercial de las pruebas. Son <30 minutos para hacerlo la primera vez, incluyendo 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 rompe", es decir, que no recibe un error de vuelta. El caso de prueba 1 debería llevarte menos de un minuto. Una vez eliminada la inercia, es fácil ampliar la cobertura de las pruebas.
    • Ahora haz evolucionar tus pruebas con tu código. No te dejes intimidar por el aspecto que tendría la prueba "correcta" de extremo a extremo, con servidores simulados y todo eso. El código empieza siendo simple y evoluciona para manejar nuevos casos; las pruebas también deberían hacerlo. A medida que añada nuevos casos y nueva complejidad a su código, añada casos de prueba para ejercitar el nuevo código. A medida que encuentre errores, añada verificaciones y/o nuevos casos para cubrir el código defectuoso. Cuando esté depurando y pierda la confianza en un trozo de código, vuelva atrás y añada pruebas para demostrar que está haciendo lo que cree. Captura cadenas de datos de ejemplo (de otros servicios a los que llamas, sitios web que raspas, lo que sea) y aliméntalas a tu código de análisis. Unos pocos casos aquí, una validación mejorada allí, y terminarás con un código altamente fiable.

Además, consulte el lista oficial de módulos Node.JS recomendados. Sin embargo, GitHub's Wiki de módulos de nodo es mucho más completo y un buen recurso.


Para entender Node, es útil tener en cuenta algunas de las principales opciones de diseño:

Node.JS es BASADO EN EVENTOS y ASYNCHRONOUS / SIN BLOQUEO . Los eventos, como una conexión HTTP entrante, activarán una función JavaScript que hace un poco de trabajo y pone en marcha otras tareas asíncronas como la conexión a una base de datos o la extracción de contenido de otro servidor. Una vez que estas tareas han sido iniciadas, la función del evento termina y Node.JS vuelve a dormir. En cuanto ocurre algo más, como el establecimiento de la conexión a la base de datos o la respuesta del servidor externo con contenido, se disparan las funciones de devolución de llamada y se ejecuta más código JavaScript, lo que puede dar lugar a más tareas asíncronas (como una consulta a la base de datos). De este modo, Node.JS intercalará felizmente actividades para múltiples flujos de trabajo paralelos, ejecutando cualquier actividad que esté desbloqueada en cualquier momento. Esta es la razón por la que Node.JS hace un gran trabajo gestionando miles de conexiones simultáneas.

¿Por qué no utilizar un proceso/hilo por conexión como todo el mundo? En Node.JS, una nueva conexión es sólo una pequeña asignación de heap. La puesta en marcha de un nuevo proceso requiere bastante más memoria, un megabyte en algunas plataformas. Pero el coste real es la sobrecarga asociada al cambio de contexto. Cuando se tienen 10^6 hilos en el núcleo, éste tiene que hacer mucho trabajo para averiguar quién debe ser el siguiente en ejecutarse. Se ha trabajado mucho en la construcción de un planificador O(1) para Linux, pero al final, es mucho más eficiente tener un único proceso dirigido por eventos que 10^6 procesos compitiendo por el tiempo de la CPU. Además, bajo 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 entrar en la caja para averiguar cómo está de jodida).

Node.JS es DE UNA SOLA ROSCA y BLOQUEO LIBRE . Node.JS, como una elección de diseño muy deliberada sólo tiene un único hilo por proceso. Debido a esto, es fundamentalmente imposible que varios hilos accedan a los datos simultáneamente. Por lo tanto, no se necesitan bloqueos. Los hilos son difíciles. Realmente muy difíciles. Si no lo crees, no has hecho suficiente programación con hilos. Conseguir que los bloqueos sean correctos es difícil y da lugar a errores que son realmente difíciles de rastrear. Eliminar los bloqueos y el multihilo hace que uno de los tipos de errores más desagradables desaparezca. Esta podría ser la mayor ventaja de Node.

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

De dos maneras:

  1. Para grandes tareas de computación pesada como la codificación de imágenes, Node.JS puede disparar procesos hijo o enviar mensajes a procesos trabajadores adicionales. En este diseño, tendrías un hilo gestionando el flujo de eventos y N procesos haciendo tareas de cálculo pesadas y masticando las otras 15 CPUs.
  2. Para escalar el rendimiento de un servicio web, debe ejecutar varios servidores Node.JS en una caja, uno por núcleo, utilizando grupo (Con Node.JS v0.6.x, el módulo oficial "cluster" enlazado aquí sustituye a la versión learnboost que tiene una API diferente). Estos servidores Node.JS locales pueden entonces competir en un socket para aceptar nuevas conexiones, equilibrando la carga entre ellos. Una vez que se acepta una conexión, ésta queda estrechamente ligada a uno de estos procesos compartidos. En teoría, esto suena mal, pero en la práctica funciona bastante bien y permite evitar el dolor de cabeza que supone escribir código a prueba de hilos. Además, esto significa que Node.JS obtiene una excelente afinidad con la caché de la CPU, utilizando más eficazmente el ancho de banda de la memoria.

Node.JS te permite hacer algunas cosas realmente potentes sin sudar. Supongamos que tienes un programa Node.JS que hace una serie de tareas, escucha en un TCP puerto para los comandos, codifica algunas imágenes, lo que sea. Con cinco líneas de código, puedes añadir un portal de gestión web basado en HTTP que muestre 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 puedes pulsar una URL y comprobar el estado de tu proceso en ejecución. Añade unos cuantos botones y tendrás un "portal de gestión". Si usted tiene un Perl / Python / Ruby script que se ejecuta, sólo "lanzar en un portal de gestión" no es exactamente simple.

¿Pero no es JavaScript lento / malo / malvado / engendro del diablo? JavaScript tiene algunas rarezas, pero con "las partes buenas" hay un lenguaje muy potente, y en cualquier caso, JavaScript es EL lenguaje en el cliente (navegador). JavaScript está aquí para quedarse; otros lenguajes lo están apuntando como un IL, y el talento de clase mundial está compitiendo para producir los motores de JavaScript más avanzados. Debido al papel que desempeña JavaScript en el navegador, se está dedicando una enorme cantidad de esfuerzos de ingeniería a hacer que JavaScript sea tremendamente rápido. V8 es el último y mejor motor de javascript, al menos por este mes. Supera a los demás lenguajes de programación tanto en eficiencia como en estabilidad (mirándote a ti, Ruby). Y sólo va a mejorar con enormes 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 como todos los motores modernos hacen toneladas de JIT compilar bajo el capó con la interpretación sólo como un recurso para el código de ejecución única). Sí, todos desearíamos poder arreglar algunas de las opciones más extrañas del lenguaje JavaScript, 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 construir aplicaciones web, tienes que saber JavaScript de todos modos, así que codificar con él en el servidor tiene una especie de sinergia de habilidades. Me ha hecho no temer escribir código de cliente.

Además, si realmente odias JavaScript, puedes utilizar azúcar sintáctico como CoffeeScript . O cualquier otra cosa que cree código JavaScript, como Kit de herramientas web de Google (GWT).

Hablando de JavaScript, ¿qué es un "cierre"? - Es una forma elegante de decir que se conservan las variables de ámbito léxico a través de las cadenas de llamadas.) Así:

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 simplemente "misDatos" sin hacer nada incómodo como almacenarlo en un objeto? Y a diferencia de Java, la variable "myData" no tiene que ser de sólo lectura. Esta poderosa característica del lenguaje hace que la programación asíncrona sea mucho menos verbosa y menos dolorosa.

Escribir código asíncrono siempre va a ser más complejo que escribir un simple scriptde un solo hilo, pero con Node.JS, no es mucho más difícil y obtienes muchos beneficios además de la eficiencia y la escalabilidad a miles de conexiones concurrentes...

213voto

postfuturist Puntos 9836

Creo que las ventajas son:

  1. Desarrollo web en un lenguaje dinámico (JavaScript) en una máquina virtual increíblemente rápida (V8). Es mucho más rápido que Ruby, Python o Perl.

  2. Capacidad para gestionar miles de conexiones simultáneas con una sobrecarga mínima en un solo proceso.

  3. JavaScript es perfecto para los bucles de eventos con objetos de función de primera clase y cierres. La gente ya sabe cómo utilizarlo de esta manera al haberlo usado en el navegador para responder a eventos iniciados por el usuario.

  4. Mucha gente ya conoce JavaScript, incluso personas que no dicen ser programadores. Podría decirse que es el lenguaje de programación más popular.

  5. El uso de JavaScript en un servidor web, así como en el navegador, reduce el desajuste de impedancia entre los dos entornos de programación, que pueden comunicar estructuras de datos a través de JSON que funcionan igual en ambos lados de la ecuación. El código de validación de formularios duplicado puede compartirse entre el servidor y el cliente, etc.

86voto

rfunduk Puntos 15267

V8 es una implementación de JavaScript. Permite ejecutar aplicaciones JavaScript independientes (entre otras cosas).

Node.JS es simplemente una biblioteca escrita para V8 que hace E/S con eventos. Este concepto es un poco más complicado de explicar, y estoy seguro de que alguien responderá con una explicación mejor que la mía... La esencia es que en lugar de hacer alguna entrada o salida y esperar a que suceda, simplemente no esperar a que termine. Así, por ejemplo, pedir la última hora de edición de un archivo:

// Pseudo code
stat( 'somefile' )

Eso puede tardar un par de milisegundos, o puede tardar segundos. Con los eventos E/S simplemente lanza la solicitud y en lugar de esperar adjunta un callback que se ejecuta cuando la solicitud termina:

// Pseudo code
stat( 'somefile', function( result ) {
  // Use the result here
} );
// ...more code here

Esto lo hace muy parecido al código JavaScript en el navegador (por ejemplo, con Ajax estilo de funcionalidad).

Para más información, consulte el artículo Node.JS es realmente emocionante que fue mi introducción a la biblioteca/plataforma... Lo encontré bastante bueno.

36voto

Asif Mushtaq Puntos 7943

Node.JS es una herramienta de línea de comandos de código abierto construida para el código JavaScript del lado del servidor. Puede descargar una tarball Compilar e instalar el código fuente. Le permite ejecutar programas de JavaScript.

El JavaScript es ejecutado por el V8 un motor JavaScript desarrollado por Google que se utiliza en Cromo navegador. Utiliza una API de JavaScript para acceder a la red y al sistema de archivos.

Es popular por su rendimiento y la capacidad de realizar operaciones paralelas.

Comprender node.JS es la mejor explicación de node.JS que he encontrado hasta ahora.

A continuación, algunos buenos artículos sobre el tema.

13voto

Fire Crow Puntos 2273

Los cierres son una forma de ejecutar el código en el contexto en el que fue creado.

Lo que esto significa para la concurrencia es que se pueden definir variables, y luego iniciar un E/S y enviarle una función anónima para su devolución de llamada.

Cuando la tarea se complete, la función de devolución de llamada se ejecutará en el contexto con las variables, esto es el cierre.

La razón por la que los cierres son tan buenos para escribir aplicaciones con E/S sin bloqueo es que es muy fácil gestionar el contexto de las funciones que se ejecutan de forma asíncrona.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X