Pregunta ¿Qué es Node.js? [cerrado]


No entiendo completamente lo que Node.js se trata de. Tal vez sea porque soy principalmente un desarrollador de aplicaciones comerciales basado en la web. ¿Qué es y para qué sirve?

Mi entendimiento hasta ahora es que:

  1. El modelo de programación se basa en eventos, especialmente la forma en que maneja E / S.
  2. Usa JavaScript y el analizador es V8.
  3. Se puede usar fácilmente para crear aplicaciones de servidor simultáneas.

¿Son correctos mis entendimientos? En caso afirmativo, ¿cuáles son los beneficios de E / S con eve, es solo más para las cosas de concurrencia? Además, ¿la dirección de Node.js es convertirse en un modelo de programación basado en JavaScript (basado en V8)?


507
2017-12-10 23:05


origen


Respuestas:


Creo que las ventajas son:

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

  2. Capacidad para manejar miles de conexiones concurrentes con una sobrecarga mínima en un solo proceso.

  3. JavaScript es perfecto para bucles de eventos con objetos y cierres de funciones de primera clase. La gente ya sabe cómo usarlo de esta manera habiéndolo usado en el navegador para responder a los eventos iniciados por el usuario.

  4. Mucha gente ya conoce JavaScript, incluso personas que no dicen ser programadores. Es posiblemente el lenguaje de programación más popular.

  5. El uso de JavaScript en un servidor web y en el navegador reduce la falta de coincidencia 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 formulario duplicado se puede compartir entre el servidor y el cliente, etc.


213
2017-12-14 19:37



Yo uso Node.js en el trabajo, y creo que es 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 gran lenguaje para codificar. Y usted volverá a pensar a diario su propia comprensión de las "mejores prácticas" y los patrones de código bien estructurado. En este momento hay una enorme cantidad de ideas que fluyen hacia Node.js, y trabajar en él te expone a todo este pensamiento: un gran levantamiento mental de pesas.

Node.js en producción es definitivamente posible, pero está lejos del despliegue "llave en mano" aparentemente prometido por la documentación. Con Node.js v0.6.x, "cluster" se ha integrado en la plataforma, proporcionando uno de los componentes esenciales, pero mi script "production.js" todavía tiene ~ 150 líneas de lógica para manejar cosas como crear el 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 Apache hace para PHP. Para ser justo, Ruby on Rails tiene esto exacto problema. Se soluciona 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 al infierno y viceversa) como Nginx (o apache / Lighttd) El servidor web puede servir eficientemente contenido estático, acceder al registro, reescribir URL, terminar SSL, hacer cumplir las reglas de acceso y administrar múltiples subservicios. Para las solicitudes que llegan al servicio de nodo real, el servidor web transmite la solicitud a través de. 2) Usando un marco como Unicornio que gestionará los procesos de los trabajadores, los reciclará periódicamente, etc. Aún no he encontrado un marco de trabajo de Node.js que parezca totalmente cocido; puede existir, pero aún no lo he encontrado y todavía uso ~ 150 líneas en mi "producción.js" rodado a mano.

Marcos de lectura como Exprimir hace que parezca que la práctica estándar es servir todo a través de un servicio de Node.js de jack-of-all-all-trades ... "app.use (express.static (__ dirname + '/ public'))". Para servicios y desarrollo de carga inferior, eso probablemente sea correcto. Pero tan pronto como tratas de cargar mucho tu servicio y hacerlo funcionar 24 horas al día, 7 días a la semana, descubrirás rápidamente las motivaciones que impulsan a los grandes sitios a tener un código-C bien horneado y reforzado como Nginx Frente a su sitio y manejando todas las solicitudes de contenido estático (... hasta que configure un CDN, me gusta Amazon CloudFront)). Para una visión un tanto cómica y descaradamente negativa de esto, ver este chico.

Node.js también encuentra cada vez más usos no relacionados con el servicio. Incluso si está utilizando otra cosa para servir contenido web, aún puede usar Node.js como una herramienta de compilación, usando npm módulos para organizar su código, Browserify coserlo en un solo activo, y uglify-js minificarlo para su despliegue. Para tratar con la web, JavaScript es perfecto partido de impedancia y con frecuencia eso lo convierte en la ruta de ataque más fácil. Por ejemplo, si quieres arrastrarte por un montón de JSON cargas útiles de respuesta, deberías usar mi guión bajo CLI módulo, el cinturón de herramientas de datos estructurados.

Pros contras:

  • Pro: para un tipo servidor, escribir JavaScript en el back-end ha sido un "fármaco de entrada" para aprender patrones modernos de UI. Ya no me asusta escribir código de cliente.
  • Pro: tiende a fomentar la correcta comprobación de errores (se devuelve prácticamente todas las devoluciones de llamadas, molestando al programador para que lo maneje; async.js y otras bibliotecas manejan el paradigma "falla si alguna de estas subtareas falla" mucho mejor que el código síncrono típico) )
  • Pro: algunas tareas interesantes y normalmente difíciles se vuelven triviales, como obtener estado en tareas en vuelo, comunicarse entre trabajadores o compartir estado de caché
  • Pro: gran comunidad y toneladas de geniales bibliotecas basadas en un sólido administrador de paquetes (npm)
  • Con: JavaScript no tiene una biblioteca estándar. Se acostumbra tanto a la funcionalidad de importación que se siente extraño cuando usa JSON.parse o algún otro método de compilació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 si no está satisfecho con la implementación predeterminada. Esto conduce a una evolución rápida, pero también a cierto nivel de confusión.

En comparación con 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 requeridas frente a PHP o Ruby.
  • Pro: Escribir patrones paralelos es fácil. Imagine que necesita obtener tres (o N) blobs de Memcached. Haz esto en PHP ... ¿acabas de escribir el código que busca el primer blob, luego el segundo y luego el tercero? Wow, eso es lento. Hay un especial PECL módulo para solucionar ese problema específico para Memcached, pero ¿qué sucede si desea buscar algunos datos de Memcached en paralelo con su consulta de base de datos? En Node.js, como el paradigma es asincrónico, tener una solicitud web hacer varias cosas en paralelo es muy natural.
  • Con: El código asíncrono 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 sólida comprensión de lo que realmente significa la ejecución concurrente. Aún así, es muchísimo menos difícil que escribir cualquier tipo de código multiproceso con bloqueo.
  • Con: Si una solicitud de cálculo intensivo se ejecuta para, por ejemplo, 100 ms, se detendrá el procesamiento de otras solicitudes que se están manejando en el mismo proceso Node.js ... AKA, cooperativo-multitarea. Esto se puede mitigar con el patrón Web Workers (derivando un subproceso para hacer frente a la costosa tarea). Alternativamente, podría usar una gran cantidad de trabajadores de Node.js y solo dejar que cada uno maneje una sola solicitud al mismo tiempo (aún bastante eficiente porque no hay proceso de reciclaje).
  • Con: ejecutar un sistema de producción es MUCHO más complicado que un CGI modelo como Apache + PHP, Perl, Rubí, etc. Las excepciones no controladas derrumbarán todo el proceso, necesitando la lógica para reiniciar los trabajos fallidos (ver racimo) Los módulos con código nativo defectuoso pueden dañar el proceso. Cada vez que un trabajador muere, las solicitudes que maneja se descartan, por lo que una API defectuosa puede degradar fácilmente el servicio para otras API cohosted.

Versus escribir un servicio "real" en Java / C # / C (¿C realmente?)

  • Pro: Hacer asincrónicamente en Node.js es más fácil que hacerlo con seguridad de subprocesos en cualquier otro lado y podría decirse que proporciona un mayor beneficio. Node.js es, con mucho, el paradigma asincrónico menos doloroso en el que he trabajado. Con buenas bibliotecas, es solo un poco más difícil que escribir código sincrónico.
  • Pro: sin errores de subprocesamiento múltiple / bloqueo. Es cierto que usted invierte por adelantado al escribir un código más detallado que expresa un flujo de trabajo asíncrono adecuado sin operaciones de bloqueo. Y necesita escribir algunas pruebas y hacer que la cosa funcione (es un lenguaje de scripting y los nombres de variables de digitación de grasa solo se captan en el tiempo de prueba de la unidad). PERO, una vez que lo haces funcionar, el área de superficie para heisenbugs - problemas extraños que solo se manifiestan una vez en un millón de ejecuciones - esa superficie es mucho más baja. Los impuestos que escriben el código de Node.js se cargan en primer plano 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 probar esto con palabras, pero JSON, tipado dinámico, notación lambda, herencia prototípica, módulos livianos, lo que sea ... simplemente tiende a tomar menos código para expresar las mismas ideas.
  • Con: ¿Tal vez realmente te gusta mucho codificar servicios en Java?

Para otra perspectiva sobre JavaScript y Node.js, echa un vistazo De Java a Node.js, una publicación de 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 bibliotecas JavaScript DEFINIR tu experiencia. La mayoría de las personas usa al menos dos, un asistente de patrón asincrónico (Step, Futures, Async) y un módulo de azúcar JavaScript (Underscore.js)

Ayuda / JavaScript Sugar:

  • Underscore.js - utilizar esta. Solo hazlo. Hace que su código sea agradable y legible con cosas como _.isString () y _.isArray (). En caso contrario, no estoy seguro de cómo escribir un código seguro. Además, para una línea de comandos mejorada, echa un vistazo a la mía Underscore-CLI.

Módulos de patrón asincrónico:

  • Paso - una forma muy elegante de expresar combinaciones de acciones seriales y paralelas. Mi recomendación personal. Ver mi publicacion en qué se parece el código de paso.
  • Futuros - Una forma mucho más flexible (¿es realmente una buena cosa?) de expresar pedidos a través de requisitos. Puede expresar cosas como "comenzar a, b, c en paralelo. Cuando A y B terminan, comienza AB. Cuando A y C finalizan, inicia AC". Dicha flexibilidad requiere más cuidado para evitar errores en su flujo de trabajo (como nunca llamar a la devolución de llamada, o llamarlo varias veces). Ver 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. Empecé con esto antes de mi conversión religiosa al paso y la posterior realización de que todos los patrones en Async podrían expresarse en Paso con un solo paradigma más legible.
  • TameJS - Escrito por OKCupid, es un precompilador que agrega un nuevo lenguaje primitivo "en espera" para escribir elegantemente flujos de trabajo seriales y paralelos. El patrón se ve increíble, pero requiere precompilación. Todavía me estoy decidiendo por este.
  • StreamlineJS - competidor de TameJS. Me estoy inclinando hacia Tame, pero puedes tomar tu propia decisión.

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

Marco web:

  • Exprimir Gran marco de Ruby on Rails-esk para organizar sitios web. Usa JADE como un motor de plantillas XML / HTML, que hace que construir HTML sea mucho menos doloroso, casi elegante incluso.
  • jQuery Si bien 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 tipo CSS para 'consultar' para conjuntos de elementos DOM que luego pueden ser operados (establecer manejadores, propiedades, estilos, etc.). En el mismo sentido, Twitter Oreja Marco de CSS, Backbone.js por un MVC patrón, y Browserify.js para unir todos tus archivos de JavaScript en un solo archivo. Todos estos módulos se están convirtiendo en estándares de facto, por lo que al menos debería verificarlos si no los conoce.

Pruebas:

  • JSHint - Debe usar; No usé esto al principio, lo que ahora parece incomprensible. JSLint agrega varias de las verificaciones básicas que obtienes con un lenguaje compilado como Java. Paréntesis no coincidentes, variables no declaradas, tipos de muchas formas y tamaños. También puede activar varias formas de lo que llamo "modo anal" donde verifica el estilo del espacio en blanco y otras cosas, lo que está bien si es su taza de té, pero el valor real proviene de obtener información instantánea sobre el número de línea exacto donde olvidaste un cierre ")" ... sin tener que ejecutar tu código y presionar la línea ofensiva. "JSHint" es una variante más configurable de Douglas Crockfordes JSLint.
  • Moca competidor de Votos 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.
  • Votos Votos es realmente bastante elegante. E imprime un informe encantador (- espec) que le muestra qué casos de prueba pasaron o fallaron. Dedique 30 minutos a aprenderlo, y puede crear pruebas básicas para sus módulos con un mínimo esfuerzo.
  • Zombi - Pruebas sin cabeza para HTML y JavaScript usando JSDom como un "navegador" virtual. Cosas muy poderosas Combínalo con Repetición para obtener pruebas deterministas a la velocidad del rayo del código en el navegador.
  • Un comentario sobre cómo "pensar sobre" las pruebas:
    • La prueba no es opcional. Con un lenguaje dinámico como JavaScript, hay muy pocos controles estáticos. Por ejemplo, pasar dos parámetros a un método que espera 4 no se romperá hasta que se ejecute el código. Barra bastante baja para crear errores en JavaScript. Las pruebas básicas son esenciales para compensar la falta de verificación con los lenguajes compilados.
    • Olvídate de la validación, solo 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 más se dispara. Demostrar que su código se ejecuta sin lanzar atrapa el 80% de los errores y hará tanto para mejorar la confianza de su código que se encontrará retrocediendo y agregando los casos de validación con matices que omitió.
    • Comience poco a poco y rompa la barrera de inercia. Todos somos perezosos y presionados por el tiempo, y es fácil ver las pruebas como "trabajo extra". Así que comienza pequeño. Escriba el caso de prueba 0: cargue su módulo e informe el éxito. Si te obligas a hacer justamente esto, entonces la barrera inercial a la prueba se rompe. Eso es <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 rompe", es decir, que no se devuelve un error. El caso de prueba 1 debería demorar menos de un minuto. Una vez que la inercia se ha ido, es fácil expandir gradualmente su cobertura de prueba.
    • Ahora evoluciona tus pruebas con tu código. No se deje intimidar por cómo se vería la prueba "correcta" de extremo a extremo con los servidores simulados y todo eso. El código comienza de manera simple y evoluciona para manejar casos nuevos; las pruebas también deberían. A medida que agregue 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 casos nuevos para cubrir el código defectuoso. Cuando depure y pierda la confianza en un fragmento de código, vuelva atrás y agregue pruebas para demostrar que está haciendo lo que cree que es. Capture cadenas de datos de ejemplo (de otros servicios que llame, sitios web que raspe, lo que sea) y aliméntelos con su código de análisis sintáctico. Unos pocos casos aquí, una validación mejorada allí, y terminará con un código altamente confiable.

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


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

Node.js es BASADO EN EVENTO y ASINCRÓNICO / SIN BLOQUEO. Los eventos, como una conexión HTTP entrante, dispararán una función de JavaScript que hace un poco de trabajo y activa otras tareas asíncronas, como conectarse a una base de datos o extraer contenido de otro servidor. Una vez que estas tareas se han iniciado, la función de evento finaliza y Node.js vuelve a dormirse. Tan pronto como sucede algo más, como la conexión de la base de datos o el servidor externo que responde con contenido, se activan las funciones de devolución de llamada y se ejecuta más código JavaScript, lo que puede desencadenar aún más tareas asincrónicas (como una consulta de base de datos). De esta forma, Node.js intercalará actividades para múltiples flujos de trabajo paralelos, ejecutando cualquier actividad que se desbloquee en cualquier momento. Esta es la razón por la cual Node.js hace un gran trabajo administrando miles de conexiones simultáneas.

¿Por qué no simplemente usar 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. Hacer girar un nuevo proceso requiere significativamente más memoria, un megabyte en algunas plataformas. Pero el costo real es la sobrecarga asociada con el cambio de contexto. Cuando tienes 10 ^ 6 hilos del kernel, el kernel tiene que trabajar mucho para descubrir quién debería ejecutar a continuación. Se ha dedicado un montón de trabajo a la creación de un planificador O (1) para Linux, pero al final, es mucho más eficiente tener un solo proceso controlado por eventos que 10 ^ 6 procesos que compiten por el tiempo de CPU. Además, en condiciones de sobrecarga, el modelo multiproceso se comporta muy mal, haciendo que la administración y los servicios de administración sean críticos, especialmente SSHD (lo que significa que ni siquiera puede iniciar sesión en la caja para averiguar qué tan mal está realmente).

Node.js es SINGLE THREADED y BLOQUEO GRATIS. Node.js, como una opción de diseño muy deliberada solo tiene un único hilo por proceso. Debido a esto, es fundamentalmente imposible que múltiples hilos accedan a los datos simultáneamente. Por lo tanto, no se necesitan bloqueos. Los hilos son duros. Realmente muy duro. Si no lo crees, no has hecho suficiente programación con hilos. Obtener el bloqueo correcto es difícil y genera errores que son realmente difíciles de rastrear. La eliminación de bloqueos y multihebras hace que una de las clases de errores más desagradables desaparezca. Esta podría ser la mayor ventaja del nodo.

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

Dos caminos:

  1. Para grandes tareas informáticas, como la codificación de imágenes, Node.js puede iniciar procesos secundarios o enviar mensajes a procesos de trabajo adicionales. En este diseño, tendrías un hilo administrando el flujo de eventos y N procesos haciendo tareas pesadas de cálculo y masticando las otras 15 CPU.
  2. Para escalar el rendimiento en un servicio web, debe ejecutar múltiples servidores Node.js en un solo cuadro, uno por núcleo, usando racimo (Con Node.js v0.6.x, el módulo oficial de "clúster" vinculado aquí reemplaza la versión de learnboost que tiene una API diferente). Estos servidores locales de Node.js pueden 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 te 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 la memoria caché de la CPU, de forma más eficaz utilizando el ancho de banda de la memoria.

Node.js te permite hacer cosas realmente poderosas sin sudar. Supongamos que tiene un programa Node.js que hace una variedad de tareas, escucha en un TCP puerto para comandos, 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 presionar una URL y verificar el estado de su proceso de ejecución. Agregue algunos botones y tiene un "portal de administración". Si tiene un script en ejecución Perl / Python / Ruby, simplemente "lanzar en un portal de administración" no es exactamente simple.

¿Pero no es JavaScript lento / malo / malo / engendro del demonio? JavaScript tiene algunas extrañas rarezas, pero con "las partes buenas" hay un lenguaje muy poderoso allí, y en cualquier caso, JavaScript es EL idioma en el cliente (navegador). JavaScript está aquí para quedarse; otros lenguajes apuntan a él como IL, y el talento de clase mundial está compitiendo para producir los motores de 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 extremadamente rápido. V8 es el último y mejor motor de javascript, al menos para este mes. Sopla los otros lenguajes de scripting tanto en eficiencia como en estabilidad (mirándote, Ruby). Y solo va a mejorar con enormes equipos que trabajan en el problema de Microsoft, Google y Mozilla, compitiendo para crear el mejor motor de JavaScript (ya no es un "intérprete" de JavaScript, ya que todos los motores modernos hacen toneladas de JIT compilando bajo el capó con interpretación solo como una reserva para el código de ejecutar una vez). Sí, todos desearíamos poder arreglar algunas de las opciones de lenguaje de JavaScript más antiguas, pero en realidad no es tan malo. Y el lenguaje es tan malditamente flexible que realmente no está codificando JavaScript, está codificando Step o jQuery: más que cualquier otro idioma, en JavaScript, las bibliotecas definen la experiencia. Para construir aplicaciones web, de todos modos tiene que saber JavaScript de todos modos, por lo que codificar con él en el servidor tiene una especie de sinergia de conjunto de habilidades. Me ha hecho no temer escribir código de cliente.

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

Hablando de JavaScript, ¿qué es un "cierre"? - Una forma bastante elegante de decir que conservas las variables de ámbito léxico en las cadenas de llamadas. ;) Me gusta 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();

Vea cómo puede usar simplemente "myData" sin hacer nada incómodo como esconderlo en un objeto. Y a diferencia de Java, la variable "myData" no tiene que ser de solo lectura. Esta potente función de lenguaje hace que la programación asíncrona sea mucho menos prolija y menos dolorosa.

Escribir código asíncrono siempre va a ser más complejo que escribir un script sencillo de un solo subproceso, pero con Node.js no es mucho más difícil y obtiene muchos beneficios además de la eficiencia y escalabilidad de miles de conexiones simultáneas. ..


620
2017-07-21 20:37



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

Node.js es simplemente una biblioteca escrita para V8 que tiene E / S con evented. Este concepto es un poco más complicado de explicar, y estoy seguro de que alguien responderá con una mejor explicación que yo ... Lo esencial es que en lugar de hacer alguna entrada o salida y esperar a que suceda, simplemente no lo hagas Espere a que termine. Entonces, por ejemplo, pregunte por la última hora editada de un archivo:

// Pseudo code
stat( 'somefile' )

Eso podría tomar un par de milisegundos, o podría tomar unos segundos. Con evented E / S simplemente desactive la solicitud y, en lugar de esperar, adjunte una devolución de llamada que se ejecutará cuando finalice la solicitud:

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

Esto se parece mucho al código JavaScript en el navegador (por ejemplo, con Ajax funcionalidad de estilo).

Para obtener más información, debe consultar el artículo Node.js es realmente emocionante que fue mi introducción a la biblioteca / plataforma ... Lo encontré bastante bien.


86
2017-12-10 23:19



Node.js es una herramienta de línea de comandos de código abierto creada para el código JavaScript del lado del servidor. Puedes descargar un tarball, compila e instala la fuente. Te permite ejecutar programas de JavaScript.

El JavaScript es ejecutado por V8, un motor de JavaScript desarrollado por Google que se usa 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.

Entendiendo node.js es la mejor explicación de node.js He encontrado hasta ahora.

Los siguientes son algunos buenos artículos sobre el tema.


36
2018-01-04 10:12



Los cierres son una forma de ejecutar código en el contexto en el que se creó.

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

Cuando la tarea se completa, la función de devolución de llamada se ejecutará en el contexto con las variables, este 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 administrar el contexto de las funciones que se ejecutan de forma asíncrona.


13
2018-04-12 00:56



Dos buenos ejemplos se refieren a cómo administrar plantillas y usar mejoras progresivas con ella. Solo necesita algunas piezas ligeras de código JavaScript para que funcione perfectamente.

Recomiendo encarecidamente que mires y leas estos artículos:

Elija cualquier idioma e intente recordar cómo administraría sus plantillas de archivos HTML y lo que tenía que hacer para actualizar una sola CSS nombre de clase en su DOM estructura (por ejemplo, un usuario hizo clic en un elemento de menú y desea que se marque como "seleccionado" y actualice el contenido de la página).

Con Node.js es tan simple como hacerlo en código JavaScript del lado del cliente. Obtenga su nodo DOM y aplique su clase CSS a eso. Obtenga su nodo DOM y innerHTML su contenido (necesitará un código JavaScript adicional para hacer esto. Lea el artículo para obtener más información).

Otro buen ejemplo es que puede hacer que su página web sea compatible tanto con JavaScript activado como desactivado con el mismo código. Imagine que tiene una selección de fecha hecha en JavaScript que permitiría a sus usuarios recoger cualquier fecha usando un calendario. Puede escribir (o usar) la misma pieza de código JavaScript para que funcione con su JavaScript activado o desactivado.


8
2018-02-28 23:44



Existe una muy buena analogía del lugar de comida rápida que mejor explica el modelo de Node.js impulsado por eventos, vea el artículo completo, Node.js, consultorios médicos y restaurantes de comida rápida: comprensión de la programación basada en eventos

Aquí hay un resumen:

Si la unión de comida rápida siguió un modelo tradicional basado en hilos, ordenaría su comida y esperaría hasta que la recibiera. La persona que está detrás de usted no podrá realizar el pedido hasta que se haya completado su pedido. En un modelo impulsado por eventos, usted ordena su comida y luego se sale de la fila para esperar. Todos los demás son libres de ordenar.

Node.js está basado en eventos, pero la mayoría de los servidores web están basados ​​en subprocesos. York explica cómo funciona Node.js:

  • Utiliza su navegador web para realizar una solicitud de "/about.html" en un Servidor web Node.js

  • El servidor Node.js acepta su solicitud y llama a una función para recuperar ese archivo del disco.

  • Mientras el servidor Node.js está esperando que se recupere el archivo, servicios la siguiente solicitud web.

  • Cuando se recupera el archivo, hay una función de devolución de llamada que es insertado en la cola de los servidores Node.js

  • El servidor Node.js ejecuta esa función que en este caso sería renderice la página "/about.html" y envíela de nuevo a su navegador web ".


7
2017-12-19 23:28



Bien, Entiendo que 

  • El objetivo de Node es proporcionar una manera fácil   para construir programas de red escalables.
  • Nodo es similar en diseño e influenciado por sistemas como Ruby's Event Machine o Python's Twisted.
  • Evented I / O para V8 javascript.

Para mí eso significa que tenías razón en las tres suposiciones. ¡La biblioteca parece prometedora!


6
2017-12-10 23:17



Además, no olvide mencionar que el V8 de Google es MUY rápido. En realidad, convierte el código JavaScript en código de máquina con el rendimiento combinado del binario compilado. Así que junto con todas las otras cosas geniales, es increíblemente rápido.


6
2017-11-29 15:15