¿Cómo decidir cuándo usar Node.js?

2194
votos

Soy nuevo en este tipo de cosas, pero últimamente he escuchado mucho sobre lo bueno que es Node.js. Teniendo en cuenta lo mucho que me encanta trabajar con jQuery y JavaScript en general, no puedo evitar preguntarme cómo decidir cuándo usar Node.js. La aplicación web que tengo en mente es algo así como Bitly : toma algo de contenido y lo archiva.

De todos los deberes que he estado haciendo en los últimos días, obtuve la siguiente información. Node.js

  • es una herramienta de línea de comandos que se puede ejecutar como un servidor web normal y permite ejecutar programas JavaScript
  • utiliza el gran motor JavaScript V8
  • es muy bueno cuando necesitas hacer varias cosas al mismo tiempo
  • está basado en eventos, por lo que todas las cosas maravillosas similares a Ajax se pueden hacer en el lado del servidor
  • nos permite compartir código entre el navegador y el backend
  • hablemos con MySQL

Algunas de las fuentes con las que me he encontrado son:

Teniendo en cuenta que Node.js se puede ejecutar casi de inmediato en las instancias EC2 de Amazon , estoy tratando de comprender qué tipo de problemas requieren Node.js en comparación con cualquiera de los reyes poderosos como PHP , Python y Ruby. . Entiendo que realmente depende de la experiencia que uno tenga en un idioma, pero mi pregunta cae más en la categoría general de: ¿Cuándo usar un marco en particular y para qué tipo de problemas es particularmente adecuado?

1
1354
votos

Hiciste un gran trabajo al resumir lo asombroso de Node.js. Mi sensación es que Node.js es especialmente adecuado para aplicaciones en las que le gustaría mantener una conexión persistente desde el navegador hasta el servidor. Usando una técnica conocida como "sondeo largo" , puede escribir una aplicación que envíe actualizaciones al usuario en tiempo real. Hacer un sondeo largo en muchos de los gigantes de la web, como Ruby on Rails o Django , crearía una carga inmensa en el servidor, porque cada cliente activo consume un proceso de servidor. Esta situación equivale a un ataque de tarpito . Cuando usa algo como Node.js, el servidor no necesita mantener subprocesos separados para cada conexión abierta.

Esto significa que puede crear una aplicación de chat basada en navegador en Node.js que casi no requiere recursos del sistema para atender a una gran cantidad de clientes. Siempre que desee realizar este tipo de sondeo largo, Node.js es una excelente opción.

Vale la pena mencionar que Ruby y Python tienen herramientas para hacer este tipo de cosas ( eventmachine y twisted , respectivamente), pero que Node.js lo hace excepcionalmente bien, y desde cero. JavaScript está excepcionalmente bien situado para un modelo de concurrencia basado en devolución de llamada, y se destaca aquí. Además, poder serializar y deserializar con JSON nativo tanto para el cliente como para el servidor es bastante ingenioso.

Espero leer otras respuestas aquí, esta es una pregunta fantástica.

Vale la pena señalar que Node.js también es excelente para situaciones en las que reutilizará una gran cantidad de código en la brecha cliente / servidor. El marco Meteor hace que esto sea realmente fácil, y mucha gente sugiere que este podría ser el futuro del desarrollo web. Puedo decir por experiencia que es muy divertido escribir código en Meteor, y una gran parte de esto es pasar menos tiempo pensando en cómo vas a reestructurar tus datos, por lo que el código que se ejecuta en el navegador puede fácilmente manipularlo y devolverlo.

Aquí hay un artículo sobre Pyramid y Long Polling , que resulta muy fácil de configurar con un poco de ayuda de gevent: TicTacToe y Long Polling with Pyramid .

4
  • 12
    Sí, creo que es muy importante pensar que 'node.js es especialmente adecuado para aplicaciones que requieren una conexión persistente desde el navegador hasta el servidor. - como programas de chat o juegos interactivos 'Si uno solo está construyendo una aplicación que no necesariamente necesita comunicación entre el usuario y el servidor, desarrollar con otros marcos estaría bien y tomaría mucho menos tiempo. user482594 27 de septiembre de 2011 a las 7:03
  • 1
    Gracias por esto ... Grandes preguntas y respuestas ;-) También lo pensaría en términos de dominar una gran tecnología para el desarrollo frontal y posterior en algunas diferentes;)Stokedout 8 de enero de 2013 a las 11:27
  • 12
    ¿Por qué utilizar el sondeo largo? ¿Qué pasó con el futuro y los enchufes ? hitautodestruct 11/02/2016 a las 7:46
  • 1
    Mi respuesta corta es el proceso en segundo plano. La solicitud y la respuesta (incluida la API de descanso) se pueden lograr con cualquier otro idioma y servidor. Entonces, para aquellos que estén pensando en convertir sus proyectos web en node. ¡Piensa de nuevo que es lo mismo! Use el nodo como un proceso en segundo plano, como leer correos electrónicos con imap, procesamiento de imágenes, cargar archivos en la nube o cualquier proceso largo o interminable que esté principalmente orientado a eventos ...Vikas 20 de marzo de 2016 a las 12:27
409
votos

Creo que Node.js es más adecuado para aplicaciones en tiempo real: juegos en línea, herramientas de colaboración, salas de chat o cualquier cosa en la que lo que un usuario (¿robot? ¿O sensor?) Haga con la aplicación deba ser visto por otros usuarios de inmediato. sin actualizar la página.

También debo mencionar que Socket.IO en combinación con Node.js reducirá su latencia en tiempo real incluso más de lo que es posible con un sondeo largo. Socket.IO recurrirá al sondeo largo como el peor de los casos y, en su lugar, utilizará sockets web o incluso Flash si están disponibles.

Pero también debo mencionar que casi cualquier situación en la que el código pueda bloquearse debido a subprocesos se puede abordar mejor con Node.js. O cualquier situación en la que necesite que la aplicación esté impulsada por eventos.

Además, Ryan Dahl dijo en una charla a la que asistí una vez que los puntos de referencia de Node.js rivalizan estrechamente con Nginx para las solicitudes HTTP antiguas regulares. Entonces, si compilamos con Node.js, podemos servir nuestros recursos normales de manera bastante efectiva, y cuando necesitamos las cosas impulsadas por eventos, está listo para manejarlo.

Además, es todo JavaScript todo el tiempo. Lingua Franca en toda la pila.

3
  • 17
    Solo una observación de alguien que cambia entre .Net y Node. Los diferentes idiomas para diferentes áreas del sistema ayudan mucho cuando se cambia de contexto. Cuando miro Javascript, estoy trabajando en el cliente, C # significa el servidor de aplicaciones, SQL = base de datos. Trabajando en Javascript en todo momento, me he encontrado confundiendo las capas, o simplemente tomando más tiempo para cambiar de contexto. Es probable que esto sea un artefacto de trabajar en la pila .NET todo el día y asentir por la noche, pero marca la diferencia. Michael Blackburn 8 de septiembre de 2015 a las 15:29
  • 9
    Curiosamente, la práctica de personas transculturales que cambian de dialecto cuando se mueven entre la cultura principal y la nativa se llama "cambio de código". Michael Blackburn 8 de septiembre de 2015 a las 15:31
  • 1
    El otro día estaba pensando en cómo podría asignar diferentes colores a mis diferentes .jsarchivos de alguna manera. Verde para el lado del cliente, azul para el lado del servidor. Yo mismo sigo "perdiéndome". AJB 30/12/15 a las 18:46
209
votos

Razones para usar NodeJS:

  • Ejecuta Javascript, por lo que puede usar el mismo idioma en el servidor y el cliente, e incluso compartir algún código entre ellos (por ejemplo, para la validación de formularios o para representar vistas en cualquier extremo).

  • El sistema impulsado por eventos de un solo subproceso es rápido incluso cuando se manejan muchas solicitudes a la vez, y también simple, en comparación con los marcos tradicionales de Java o ROR de subprocesos múltiples .

  • El grupo cada vez mayor de paquetes accesibles a través de NPM , incluidas bibliotecas / módulos del lado del cliente y del servidor, así como herramientas de línea de comandos para el desarrollo web. La mayoría de estos están convenientemente alojados en github, donde a veces puede informar un problema y encontrarlo solucionado en cuestión de horas. Es bueno tener todo bajo un mismo techo, con informes de problemas estandarizados y fácil bifurcación.

  • Se ha convertido en el entorno estándar de facto en el que ejecutar herramientas relacionadas con Javascript y otras herramientas relacionadas con la web , incluidos los corredores de tareas, minificadores, embellecedores, linters, preprocesadores, agrupadores y procesadores de análisis.

  • Parece bastante adecuado para la creación de prototipos, el desarrollo ágil y la iteración rápida de productos .

Razones para no usar NodeJS:

  • Ejecuta Javascript, que no tiene verificación de tipo en tiempo de compilación. Para sistemas o proyectos grandes y complejos de seguridad crítica que incluyen la colaboración entre diferentes organizaciones, un lenguaje que fomente las interfaces contractuales y proporcione una verificación de tipo estática puede ahorrarle algo de tiempo de depuración (y explosiones ) a largo plazo. (Aunque la JVM está bloqueada null, utilice Haskell para sus reactores nucleares).

  • Sumado a eso, muchos de los paquetes en NPM son un poco crudos y aún están en rápido desarrollo. Algunas bibliotecas para marcos más antiguos se han sometido a una década de pruebas y corrección de errores, y ahora son muy estables . Npmjs.org no tiene ningún mecanismo para calificar paquetes , lo que ha llevado a una proliferación de paquetes que hacen más o menos lo mismo, de los cuales un gran porcentaje ya no se mantiene.

  • Infierno de devolución de llamada anidado. (Por supuesto que hay 20 soluciones diferentes para esto ...)

  • El creciente grupo de paquetes puede hacer que un proyecto de NodeJS parezca radicalmente diferente del siguiente. Existe una gran diversidad de implementaciones debido a la gran cantidad de opciones disponibles (por ejemplo, Express / Sails.js / Meteor / Derby ). Esto a veces puede dificultar que un nuevo desarrollador se involucre en un proyecto de Node. Compare eso con un desarrollador de Rails que se une a un proyecto existente: debería poder familiarizarse con la aplicación con bastante rapidez, porque se anima a todas las aplicaciones de Rails a utilizar una estructura similar .

  • Tratar con archivos puede ser un poco molesto. Las cosas que son triviales en otros idiomas, como leer una línea de un archivo de texto, son lo suficientemente extrañas como para hacer con Node.js que hay una pregunta de StackOverflow sobre eso con más de 80 votos positivos. No existe una forma sencilla de leer un registro a la vez de un archivo CSV . Etc.

Me encanta NodeJS, es rápido, salvaje y divertido, pero me preocupa que tenga poco interés en la corrección demostrable. Esperemos que eventualmente podamos fusionar lo mejor de ambos mundos. Estoy ansioso por ver qué reemplazará a Node en el futuro ... :)

8
  • 1
    @nane Sí, creo que pueden abordar ese problema, sin embargo, debe limitarse a usar solo bibliotecas escritas en lenguajes con seguridad de tipos, o aceptar que no todo su código base está escrito de forma estática. Pero un argumento es: dado que debe escribir buenas pruebas para su código independientemente del idioma, entonces su nivel de confianza debe ser igual incluso para el código escrito dinámicamente. Si aceptamos ese argumento, las ventajas de la tipificación fuerte se reducen a ayudar en el tiempo de desarrollo / depuración, la demostrabilidad y la optimización . joeytwiddle 23/08/15 a las 16:46
  • 1
    @kervin, estoy de acuerdo en que algunos puntos de referencia serían geniales, pero me decepcionó lo que pude encontrar en línea. Algunos han argumentado que el rendimiento de .NET es comparable al de Node, pero que lo que realmente está haciendo es crucial. Node puede ser excelente para entregar pequeños mensajes con muchas conexiones simultáneas, pero no tan bueno para cálculos matemáticos pesados. Una buena comparación de rendimiento necesitaría probar una variedad de situaciones. joeytwiddle 23/08/15 a las 16:59
  • 2
    @joeytwiddle, ¿no ayudarían cosas como Typescript a Node.js cuando se trata de manejar programas complejos más grandes y verificación de tipo estática? CodeMonkey 3 de septiembre de 2015 a las 6:33
  • 2
    @joeytwiddle por lo que vale, puede usar stillmaintained.com para determinar si un paquete npm aún se mantiene o no (ya que la mayoría están en github). Además, npm searchy npm showle mostrará la fecha del último lanzamiento de un paquete. Dan 3 de noviembre de 2015 a las 12:38
  • 3
    Al comparar rieles con nodo, confunde una plataforma con un marco. Rails es un marco para Ruby al igual que Sails y meteor son marcos para Javascript. BonsaiOak 26/02/2016 a las 15:10
206
votos

Para hacerlo breve:

Node.js es adecuado para aplicaciones que tienen muchas conexiones simultáneas y cada solicitud solo necesita muy pocos ciclos de CPU, porque el bucle de eventos (con todos los demás clientes) se bloquea durante la ejecución de una función.

Un buen artículo sobre el bucle de eventos en Node.js es el blog de tecnología de Mixu: Comprender el ciclo de eventos Node.js .

0
127
votos

Tengo un ejemplo del mundo real en el que he usado Node.js. La empresa en la que trabajo consiguió un cliente que quería tener un sitio web HTML estático simple. Este sitio web es para vender un artículo usando PayPal y el cliente también quería tener un contador que muestre la cantidad de artículos vendidos. El cliente esperaba tener una gran cantidad de visitantes en este sitio web. Decidí hacer el contador usando Node.js y el marco Express.js .

La aplicación Node.js fue simple. Obtenga la cantidad de artículos vendidos de una base de datos de Redis , aumente el contador cuando se venda el artículo y proporcione el valor del contador a los usuarios a través de la API .

Algunas razones por las que elegí usar Node.js en este caso

  1. Es muy ligero y rápido. Ha habido más de 200000 visitas en este sitio web en tres semanas y los recursos mínimos del servidor han podido manejarlo todo.
  2. El contador es muy fácil de hacer en tiempo real.
  3. Node.js fue fácil de configurar.
  4. Hay muchos módulos disponibles de forma gratuita. Por ejemplo, encontré un módulo Node.js para PayPal.

En este caso, Node.js fue una elección increíble.

3
  • 7
    ¿Cómo organizas algo así? ¿Tienes que configurar nodejs en el servidor de producción entonces? ¿En linux? Miguel Stevens 14/04/2014 a las 15:25
  • 1
    Hay algunas PaaS como nodejitsu y Heroku. O puede configurar nodejs en una caja de Linux, es decir, desde amazon ec2. ver: lauradhamilton.com/…harry young 15 de julio de 2015 a las 23:17
  • 13
    200.000 visitas en 1.814.400 segundos. No es relevante en absoluto. Incluso bash podría atender tantas solicitudes en el servidor más lento. Servidor Scratch. VM más lenta. Tiberiu-Ionuț Stan 1 de mayo de 2016 a las 10:52
105
votos

Las razones más importantes para comenzar su próximo proyecto usando Node ...

  • A todos los tipos más geniales les gusta ... así que debe ser divertido.
  • Puedes pasar el rato en la nevera y tener muchas aventuras de Node de las que presumir.
  • Eres un pionero en lo que respecta a los costos de alojamiento en la nube.
  • He hecho eso con Rails
  • Odias las implementaciones de IIS
  • Su antiguo trabajo de TI se está volviendo bastante aburrido y desearía estar en una nueva y brillante Start Up.

Que esperar ...

  • Se sentirá seguro y protegido con Express sin todo el software de relleno del servidor que nunca necesitó.
  • Corre como un cohete y escala bien.
  • Lo sueñas. Lo instalaste. El paquete de nodos repo npmjs.org es el mayor ecosistema de bibliotecas de código abierto del mundo.
  • Tu cerebro se deformará en el tiempo en la tierra de las devoluciones de llamada anidadas ...
  • ... hasta que aprenda a cumplir sus promesas .
  • Sequelize y Passport son sus nuevos amigos de API.
  • La depuración en su mayoría de código asincrónico se volverá umm ... interesante .
  • Es hora de que todos los noders dominen Mecanografiado .

¿Quién lo usa?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • He aquí por qué cambiaron a Node .
4
  • 18
    Sí, podría haber respondido a esta pregunta de la manera tradicional. Creo que estoy calificado para hacerlo, pero la mayor parte ya se ha dicho y pensé que un poco de diversión alegre rompería la monotonía. Aporto regularmente respuestas técnicas a otras preguntas. Tony O'Hagan 14 de junio de 2014 a las 4:24
  • 1
    Las devoluciones de llamada anidadas se pueden evitar utilizando generadores ES6 para código asíncronorefactor 19 de mayo de 2016 a las 12:25
  • 1
    @CleanCrispCode: ¡Sí, de hecho! ES6 ha adoptado el estilo C # async/, awaitpor lo que ahora podemos implementar un código de nodo asíncrono mucho más limpio que también es compatible con try/ catch. En 2016/17, los codificadores JS cambiarán a ES6. Tony O'Hagan 20 de mayo de 2016 a las 0:12
  • 1
    diez mil veces este "Se sentirá seguro y protegido con Express sin todo el software de relleno del servidor que nunca necesitó"Simone Poggi 27/07/2016 a las 8:19
60
votos

No hay nada como Silver Bullet. Todo viene con algún costo asociado. Es como si comes alimentos grasos, comprometerás tu salud y los alimentos saludables no vienen con especias como los alimentos grasos. Es una elección individual si quieren salud o especias como en su comida. De la misma manera que Node.js considera que se usa en un escenario específico. Si su aplicación no encaja en ese escenario, no debe considerarla para el desarrollo de su aplicación. Solo estoy pensando en lo mismo:

Cuándo usar Node.JS

  1. Si el código del lado del servidor requiere muy pocos ciclos de CPU. En otro mundo, está realizando una operación sin bloqueo y no tiene un algoritmo / trabajo pesado que consume muchos ciclos de CPU.
  2. Si tiene experiencia en Javascript y se siente cómodo escribiendo código de un solo subproceso al igual que JS del lado del cliente.

Cuándo NO usar Node.JS

  1. La solicitud de su servidor depende de un trabajo / algoritmo que consuma mucho CPU.

Consideración de escalabilidad con Node.JS

  1. Node.JS en sí no utiliza todo el núcleo del sistema subyacente y es de un solo subproceso de forma predeterminada, debe escribir la lógica por su cuenta para utilizar el procesador de múltiples núcleos y hacerlo de múltiples subprocesos.

Alternativas de Node.JS

Hay otras opciones para usar en lugar de Node.JS, sin embargo, Vert.x parece ser bastante prometedor y tiene muchas características adicionales como polygot y mejores consideraciones de escalabilidad.

6
  • 24
    No estoy seguro de que "Si su solicitud del lado del servidor incluye operaciones de bloqueo como File IO o Socket IO" se enumeran en "Cuando NO se debe usar". Si mi entendimiento es correcto, una de las fortalezas de node.js es que tiene poderosos medios asincrónicos para manejar IO sin bloquear. Por lo tanto, Node.js puede verse como "una cura" para bloquear IO. Ondrej Peterka 24 de mayo de 2013 a las 13:00
  • 3
    @OndraPeterka: Tiene razón en que Node.js es una cura para bloquear IO del servidor, sin embargo, si su controlador de solicitudes en el servidor mismo está haciendo una llamada de bloqueo a algún otro servicio web / operación de archivo, Node.js no ayudaría aquí. No bloquea la E / S solo para las solicitudes entrantes al servidor, pero no para las solicitudes salientes del controlador de solicitudes de su aplicación. Ajay Tiwari 5 de junio de 2013 a las 7:28
  • 4
    @ajay de nodejs.org dicen "E / S sin bloqueo", marque sus "Cuando NO" 2 y 3.Omar Al-Ithawi 6 de junio de 2013 a las 8:23
  • 5
    con la versión actual, el nodo en realidad es compatible con el soporte de múltiples núcleos mediante el uso de clúster. Esto realmente aumenta el rendimiento de la aplicación Node al menos dos veces. Sin embargo, creo que el rendimiento debería ser más del doble cuando estabilizan la biblioteca del clúster. Nam Nguyen 12/0913 a las 20:05
  • 4
    Puede usar node.js para cálculos pesados. Utilice fork. Consulte stackoverflow.com/questions/9546225/… . Node maneja muy bien varios núcleos con el clustermódulo. nodejs.org/api/cluster.htmlJess 14 de mayo de 2014 a las 19:44
41
votos

Otra gran cosa que creo que nadie ha mencionado sobre Node.js es la increíble comunidad, el sistema de administración de paquetes (npm) y la cantidad de módulos que existen que puede incluir simplemente incluyéndolos en su archivo package.json.

4
  • 6
    Y estos paquetes son relativamente nuevos, por lo que tienen el beneficio de la retrospectiva y tienden a ajustarse a los estándares web recientes. joeytwiddle 19/07/2013 a las 21:46
  • 3
    Con el debido respeto, muchos paquetes en npm son terribles, porque npm no tiene un mecanismo para calificar paquetes . ¿Alguien en retrospectiva desde CPAN ? Dan Dascalescu 13 feb 2014 a las 13:45
  • Lástima que ninguna de las bibliotecas de websockets pueda satisfacer las especificaciones rfc 6455. Los fanboys de node.js son sordos, tontos y ciegos cuando se da este hecho. r3wt 1 de agosto de 2014 a las 6:32
  • 1
    No sé cuándo hizo el comentario, pero a partir de ahora, la biblioteca ws admite esa especificaciónJonathan Gray 10 de noviembre de 2014 a las 4:14
36
votos

Mi pieza: nodejs es excelente para crear sistemas en tiempo real como análisis, aplicaciones de chat, apis, servidores de anuncios, etc. ¡Demonios, hice mi primera aplicación de chat usando nodejs y socket.io en menos de 2 horas y eso también durante la semana de exámenes!

Editar

Han pasado varios años desde que comencé a usar nodejs y lo he usado para hacer muchas cosas diferentes, incluidos servidores de archivos estáticos, análisis simples, aplicaciones de chat y mucho más. Esta es mi opinión sobre cuándo usar nodejs

Cuándo usar

Al hacer un sistema que ponga énfasis en la concurrencia y la velocidad.

  • Sockets solo servidores como aplicaciones de chat, aplicaciones de irc, etc.
  • Redes sociales que ponen énfasis en recursos en tiempo real como geolocalización, transmisión de video, transmisión de audio, etc.
  • Manejo de pequeños fragmentos de datos muy rápido como una aplicación web de análisis.
  • Como exponer una API REST only.

Cuando no usar

Es un servidor web muy versátil, por lo que puede usarlo donde quiera, pero probablemente no en estos lugares.

  • Blogs simples y sitios estáticos.
  • Como un servidor de archivos estático.

Tenga en cuenta que solo soy quisquilloso. Para los servidores de archivos estáticos, apache es mejor principalmente porque está ampliamente disponible. La comunidad de nodejs se ha vuelto más grande y madura a lo largo de los años y es seguro decir que nodejs se puede usar en casi todas partes si tiene su propia elección de alojamiento.

2
  • Los blogs simples aún pueden beneficiarse de Node.js. Para servir archivos estáticos, aún puede usar Node.js y si la carga aumenta, simplemente agregue el proxy inverso Nginx delante de él, según las mejores prácticas actuales. El servidor httpd de Apache es un dinosaurio que está muriendo; consulte esta encuesta de Netcraft . Endrju 5 de ene. De 2016 a las 9:53
  • Yo diría lo contrario: eche un vistazo a ghost.org , se ve increíble y está construido sobre NodeJs: colaboración, edición de artículos en tiempo real. Además, crear una página simple en NodeJs, digamos usar sailsjs.org , es fácil, rápido y no necesita preocuparse por aprender ninguno de los lenguajes de programación del lado del servidorBery 16 de junio de 2016 a las 9:52
30
votos

Se puede utilizar donde

  • Aplicaciones que son altamente impulsadas por eventos y están fuertemente ligadas a E / S
  • Aplicaciones que manejan una gran cantidad de conexiones a otros sistemas
  • Aplicaciones en tiempo real (Node.js fue diseñado desde cero para tiempo real y para que sea fácil de usar).
  • Aplicaciones que hacen malabares con gran cantidad de información que fluye hacia y desde otras fuentes
  • Aplicaciones escalables de alto tráfico
  • Aplicaciones móviles que tienen que comunicarse con la API y la base de datos de la plataforma, sin tener que hacer muchos análisis de datos
  • Desarrolle aplicaciones en red
  • Aplicaciones que necesitan hablar con el back-end muy a menudo

En el ámbito móvil, las empresas de máxima audiencia han confiado en Node.js para sus soluciones móviles. ¿Mira por qué?

LinkedIn es un usuario destacado. Toda su pila móvil se basa en Node.js. Pasaron de ejecutar 15 servidores con 15 instancias en cada máquina física, a solo 4 instancias, ¡que pueden manejar el doble del tráfico!

eBay lanzó ql.io, un lenguaje de consulta web para API HTTP, que usa Node.js como pila de tiempo de ejecución. Pudieron ajustar una estación de trabajo Ubuntu regular con calidad de desarrollador para manejar más de 120,000 conexiones activas por proceso node.js, ¡y cada conexión consumía aproximadamente 2kB de memoria!

Walmart rediseñó su aplicación móvil para usar Node.js y envió su procesamiento de JavaScript al servidor.

Lea más en: http://www.pixelatesbits.com/a-closer-look-at-mobile-app-development-with-node-js/

20
votos

Nodo mejor para el manejo de solicitudes concurrentes -

Entonces, comencemos con una historia. Desde los últimos 2 años estoy trabajando en JavaScript y desarrollando web front end y lo estoy disfrutando. Los chicos de back-end nos proporcionan algunas API escritas en Java, python (no nos importa) y simplemente escribimos una llamada AJAX, obtenemos nuestros datos y ¡adivina qué! hemos terminado. Pero en realidad no es tan fácil, si los datos que estamos obteniendo no son correctos o hay algún error en el servidor, entonces nos atascamos y tenemos que contactar a nuestros chicos de back-end por correo o chat (a veces también en WhatsApp :)). no es genial. ¿Qué pasa si escribimos nuestras API en JavaScript y llamamos a esas API desde nuestra interfaz? Sí, eso es muy bueno porque si enfrentamos algún problema en la API, podemos investigarlo. Adivina qué ! puedes hacer esto ahora, ¿cómo? - Node está ahí para ti.

Ok, acordé que puede escribir su API en JavaScript, pero ¿qué pasa si estoy de acuerdo con el problema anterior? ¿Tiene alguna otra razón para usar node for rest API?

así que aquí comienza la magia. Sí, tengo otras razones para usar node para nuestras API.

Volvamos a nuestro sistema de API de descanso tradicional que se basa en la operación de bloqueo o en el subproceso. Suponga que se producen dos solicitudes simultáneas (r1 y r2), cada una de las cuales requiere la operación de la base de datos. Entonces, en el sistema tradicional, lo que sucederá:

1. Modo de espera: nuestro servidor comienza a atender la r1solicitud y espera la respuesta de la consulta. una vez finalizado r1, el servidor comienza a servir r2y lo hace de la misma manera. Entonces, esperar no es una buena idea porque no tenemos tanto tiempo.

2. Forma de subprocesos : nuestro servidor creará dos subprocesos para ambas solicitudes r1y cumplirá r2su propósito después de consultar la base de datos, por lo que es genial, pero consume memoria porque puede ver que comenzamos dos subprocesos y el problema aumenta cuando ambas solicitudes consultan los mismos datos. entonces tienes que lidiar con problemas de interbloqueo. Así que es mejor que esperar, pero todavía hay problemas.

Ahora aquí está, cómo lo hará el nodo:

3. Nodeway: Cuando misma petición concurrente viene en el nodo a continuación, se registrará un evento con su devolución de llamada y seguir adelante no va a esperar a que la consulta de respuestas para una request.So particular, cuando r1la solicitud viene a continuación, bucle de eventos del nodo (si hay un bucle de eventos en el nodo que sirve para este propósito.) registrar un evento con su función de devolución de llamada y seguir adelante para atender la r2solicitud y, de manera similar, registrar su evento con su devolución de llamada. Siempre que una consulta finaliza, desencadena su evento correspondiente y ejecuta su devolución de llamada hasta su finalización sin ser interrumpida.

Entonces, sin esperas, sin subprocesos, sin consumo de memoria, sí, esta es una forma de nodo para servir la API de descanso.

1
  • 1
    Hola Anshul. ¿Puede elaborar o sugerir algún recurso sobre cómo puede ocurrir un interbloqueo en el modo de subprocesamiento? jsbisht 14 de marzo de 2015 a las 17:10
dieciséis
votos

Mi única razón más para elegir Node.js para un nuevo proyecto es:

Ser capaz de realizar un desarrollo puro basado en la nube

He usado Cloud9 IDE durante un tiempo y ahora no puedo imaginarme sin él, cubre todos los ciclos de vida del desarrollo. Todo lo que necesita es un navegador y puede codificar en cualquier momento y en cualquier dispositivo. No es necesario registrar el código en una computadora (como en casa) y luego pagar en otra computadora (como en el lugar de trabajo).

Por supuesto, tal vez exista un IDE basado en la nube para otros lenguajes o plataformas (Cloud 9 IDE también está agregando soporte para otros lenguajes), pero usar Cloud 9 para desarrollar Node.js es realmente una gran experiencia para mí.

2
  • 1
    En realidad, Cloud9 IDE y los demás (como el que yo uso) admiten casi todo tipo de lenguaje web. Wanny Miarelli 24 feb 2015 a las 18:40
  • 7
    ¿Hablas en serio amigo? este es el criterio para elegir una pila? :) ¡feliz de que esté funcionando para ti! matanster 18/03/15 a las 20:15
15
votos

Una cosa más que ofrece el nodo es la capacidad de crear múltiples instancias v8 de nodo utilizando el proceso hijo del nodo ( childProcess.fork (), cada uno de los cuales requiere 10 MB de memoria según los documentos) sobre la marcha, sin afectar el proceso principal que ejecuta el servidor. Por lo tanto, descargar un trabajo en segundo plano que requiere una gran carga del servidor se convierte en un juego de niños y podemos eliminarlos fácilmente cuando sea necesario.

He estado usando mucho el nodo y en la mayoría de las aplicaciones que creamos, requieren conexiones de servidor al mismo tiempo, por lo tanto, un tráfico de red pesado. Los marcos como Express.js y los nuevos Koajs (que eliminaron el infierno de devolución de llamada) han hecho que trabajar en el nodo sea aún más fácil.

15
votos

Ponerse longjohns de amianto ...

Ayer mi título con Publicaciones Packt, Programación reactiva con JavaScript . No es realmente un título centrado en Node.js; Los primeros capítulos están destinados a cubrir la teoría, y los capítulos posteriores con mucho código cubren la práctica. Debido a que realmente no pensé que sería apropiado no darles a los lectores un servidor web, Node.js parecía, con mucho, la opción obvia. El caso se cerró incluso antes de que se abriera.

Podría haber dado una visión muy optimista de mi experiencia con Node.js. En cambio, fui honesto sobre los puntos buenos y los malos que encontré.

Permítanme incluir algunas citas que son relevantes aquí:

Warning: Node.js and its ecosystem are hot--hot enough to burn you badly!

When I was a teacher’s assistant in math, one of the non-obvious suggestions I was told was not to tell a student that something was “easy.” The reason was somewhat obvious in retrospect: if you tell people something is easy, someone who doesn’t see a solution may end up feeling (even more) stupid, because not only do they not get how to solve the problem, but the problem they are too stupid to understand is an easy one!

There are gotchas that don’t just annoy people coming from Python / Django, which immediately reloads the source if you change anything. With Node.js, the default behavior is that if you make one change, the old version continues to be active until the end of time or until you manually stop and restart the server. This inappropriate behavior doesn’t just annoy Pythonistas; it also irritates native Node.js users who provide various workarounds. The StackOverflow question “Auto-reload of files in Node.js” has, at the time of this writing, over 200 upvotes and 19 answers; an edit directs the user to a nanny script, node-supervisor, with homepage at http://tinyurl.com/reactjs-node-supervisor. This problem affords new users with great opportunity to feel stupid because they thought they had fixed the problem, but the old, buggy behavior is completely unchanged. And it is easy to forget to bounce the server; I have done so multiple times. And the message I would like to give is, “No, you’re not stupid because this behavior of Node.js bit your back; it’s just that the designers of Node.js saw no reason to provide appropriate behavior here. Do try to cope with it, perhaps taking a little help from node-supervisor or another solution, but please don’t walk away feeling that you’re stupid. You’re not the one with the problem; the problem is in Node.js’s default behavior.”

This section, after some debate, was left in, precisely because I don't want to give an impression of “It’s easy.” I cut my hands repeatedly while getting things to work, and I don’t want to smooth over difficulties and set you up to believe that getting Node.js and its ecosystem to function well is a straightforward matter and if it’s not straightforward for you too, you don’t know what you’re doing. If you don’t run into obnoxious difficulties using Node.js, that’s wonderful. If you do, I would hope that you don’t walk away feeling, “I’m stupid—there must be something wrong with me.” You’re not stupid if you experience nasty surprises dealing with Node.js. It’s not you! It’s Node.js and its ecosystem!

El Apéndice, que realmente no quería después del crescendo creciente en los últimos capítulos y la conclusión, habla sobre lo que pude encontrar en el ecosistema y proporcionó una solución para el literalismo idiota:

Another database that seemed like a perfect fit, and may yet be redeemable, is a server-side implementation of the HTML5 key-value store. This approach has the cardinal advantage of an API that most good front-end developers understand well enough. For that matter, it’s also an API that most not-so-good front-end developers understand well enough. But with the node-localstorage package, while dictionary-syntax access is not offered (you want to use localStorage.setItem(key, value) or localStorage.getItem(key), not localStorage[key]), the full localStorage semantics are implemented, including a default 5MB quota—WHY? Do server-side JavaScript developers need to be protected from themselves?

For client-side database capabilities, a 5MB quota per website is really a generous and useful amount of breathing room to let developers work with it. You could set a much lower quota and still offer developers an immeasurable improvement over limping along with cookie management. A 5MB limit doesn’t lend itself very quickly to Big Data client-side processing, but there is a really quite generous allowance that resourceful developers can use to do a lot. But on the other hand, 5MB is not a particularly large portion of most disks purchased any time recently, meaning that if you and a website disagree about what is reasonable use of disk space, or some site is simply hoggish, it does not really cost you much and you are in no danger of a swamped hard drive unless your hard drive was already too full. Maybe we would be better off if the balance were a little less or a little more, but overall it’s a decent solution to address the intrinsic tension for a client-side context.

However, it might gently be pointed out that when you are the one writing code for your server, you don’t need any additional protection from making your database more than a tolerable 5MB in size. Most developers will neither need nor want tools acting as a nanny and protecting them from storing more than 5MB of server-side data. And the 5MB quota that is a golden balancing act on the client-side is rather a bit silly on a Node.js server. (And, for a database for multiple users such as is covered in this Appendix, it might be pointed out, slightly painfully, that that’s not 5MB per user account unless you create a separate database on disk for each user account; that’s 5MB shared between all user accounts together. That could get painful if you go viral!) The documentation states that the quota is customizable, but an email a week ago to the developer asking how to change the quota is unanswered, as was the StackOverflow question asking the same. The only answer I have been able to find is in the Github CoffeeScript source, where it is listed as an optional second integer argument to a constructor. So that’s easy enough, and you could specify a quota equal to a disk or partition size. But besides porting a feature that does not make sense, the tool’s author has failed completely to follow a very standard convention of interpreting 0 as meaning “unlimited” for a variable or function where an integer is to specify a maximum limit for some resource use. The best thing to do with this misfeature is probably to specify that the quota is Infinity:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Intercambiando dos comentarios en orden:

People needlessly shot themselves in the foot constantly using JavaScript as a whole, and part of JavaScript being made respectable language was a Douglas Crockford saying in essence, “JavaScript as a language has some really good parts and some really bad parts. Here are the good parts. Just forget that anything else is there.” Perhaps the hot Node.js ecosystem will grow its own “Douglas Crockford,” who will say, “The Node.js ecosystem is a coding Wild West, but there are some real gems to be found. Here’s a roadmap. Here are the areas to avoid at almost any cost. Here are the areas with some of the richest paydirt to be found in ANY language or environment.”

Perhaps someone else can take those words as a challenge, and follow Crockford’s lead and write up “the good parts” and / or “the better parts” for Node.js and its ecosystem. I’d buy a copy!

And given the degree of enthusiasm and sheer work-hours on all projects, it may be warranted in a year, or two, or three, to sharply temper any remarks about an immature ecosystem made at the time of this writing. It really may make sense in five years to say, “The 2015 Node.js ecosystem had several minefields. The 2020 Node.js ecosystem has multiple paradises.”

0
9
votos

Si su aplicación ata principalmente a web apis u otros canales io, otorgue o tome una interfaz de usuario, node.js puede ser una elección justa para usted, especialmente si desea exprimir la mayor escalabilidad o, si su idioma principal en la vida es javascript (o una especie de transpiladores de javascript). Si crea microservicios, node.js también está bien. Node.js también es adecuado para cualquier proyecto que sea pequeño o simple.

Su principal punto de venta es que permite a los front-end asumir la responsabilidad de las cosas de back-end en lugar de la división típica. Otro punto de venta justificable es si su fuerza de trabajo está orientada a JavaScript para empezar.

Sin embargo, más allá de cierto punto, no puede escalar su código sin terribles trucos para forzar la modularidad, la legibilidad y el control de flujo. Sin embargo, a algunas personas les gustan esos trucos, especialmente si provienen de un entorno de JavaScript impulsado por eventos, parecen familiares o perdonables.

En particular, cuando su aplicación necesita realizar flujos síncronos, comienza a sangrar sobre soluciones a medio cocer que lo ralentizan considerablemente en términos de su proceso de desarrollo. Si tiene partes de cálculo intensivo en su aplicación, pise con precaución seleccionando (solo) node.js. Tal vez http://koajs.com/ u otras novedades alivien esos aspectos originalmente espinosos, en comparación con cuando usé originalmente node.js o escribí esto.

4
  • 3
    Hay muchos enfoques existentes para escalar aplicaciones Node.js, y no parece que proporciones ninguna referencia con respecto a las afirmaciones de "soluciones a medias", "hacks terribles" y "API terribles". ¿Te importaría expandir esos? Sven Slootweg 9 de marzo de 2015 a las 2:40
  • Lo dejo como ejercicio para el lector, pero basta con mirar las llamadas soluciones para el control de flujo. matanster 9 de marzo de 2015 a las 11:39
  • 2
    Esa no es realmente una respuesta. Afirma que las soluciones existentes son "terribles trucos", pero no señala ninguna de ellas. ¿Ha considerado que es posible que simplemente no comprenda o no conozca los métodos correctos para escalar aplicaciones Node.js? Sven Slootweg 9/03/15 a las 19:11
  • Actualicé un poco mi respuesta. Quizás todavía tengas quejas, pero si crees que está mal deberías comentar con detalles ... en lugar de señalar una falta de las mismas en la respuesta. Eso sería más productivo para la comunidad en mi opinión. matanster 18/03/15 a las 21:38
-2
votos

Puedo compartir algunos puntos dónde y por qué usar node js.

  1. Para aplicaciones en tiempo real como el chat, la edición colaborativa es mejor, usamos nodejs, ya que es una base de eventos donde se disparan los eventos y los datos a los clientes desde el servidor.
  2. Simple y fácil de entender, ya que es una base de JavaScript donde la mayoría de la gente tiene una idea.
  3. La mayoría de las aplicaciones web actuales van hacia js angular y backbone, con node es fácil interactuar con el código del lado del cliente ya que ambos usarán datos json.
  4. Muchos complementos disponibles.

Inconvenientes: -

  1. Node admitirá la mayoría de las bases de datos, pero lo mejor es mongodb, que no admitirá uniones complejas y otras.
  2. Errores de compilación ... el desarrollador debe manejar todas y cada una de las excepciones de otra manera si alguna aplicación de acuerdo de error deja de funcionar donde nuevamente debemos ir e iniciarla manualmente o usando cualquier herramienta de automatización.

Conclusión: - Es mejor usar Nodejs para aplicaciones simples y en tiempo real ... si tiene una lógica de negocios muy grande y una funcionalidad compleja, mejor no debe usar nodejs. Si desea crear una aplicación junto con el chat y cualquier funcionalidad colaborativa, el nodo se puede utilizar en partes específicas y debe ir con su tecnología de conveniencia.

-3
votos
  1. Node es ideal para prototipos rápidos, pero nunca lo volvería a usar para nada complejo. Pasé 20 años desarrollando una relación con un compilador y seguro que lo extraño.

  2. Node es especialmente doloroso para mantener el código que no ha visitado por un tiempo. El tipo de información y la detección de errores en el tiempo de compilación son COSAS BUENAS. ¿Por qué tirar todo eso? ¿Para qué? Y maldición, cuando algo va hacia el sur, la pila a menudo resulta completamente inútil.

3
  • 2
    Si bien no obtiene la verificación en tiempo de compilación, JSDoc le permite agregar cualquier tipo de información que desee para que las cosas tengan más sentido cuando regrese. Las funciones correctamente descompuestas (pequeñas) también suelen ser bastante fáciles de asimilar debido a su entorno bien definido (el cierre). Los seguimientos de pila defectuosos a menudo se pueden resolver con un poco de re-factorización para asegurarse de que no está dividiendo su lógica con una devolución de llamada asíncrona en el medio. Mantener sus devoluciones de llamada asíncronas dentro del mismo cierre facilita el razonamiento y el mantenimiento. Rich Remer 17/10/2014 a las 20:16
  • 2
    He pasado 30 años con lenguajes compilados, pero después de usarlo durante solo un año, JavaScript es ahora mi idioma preferido. Es tan productivo: puedo hacer mucho más con mucho menos código que Java C # C ++ o C. Pero es una mentalidad diferente. Las variables no escritas son en realidad una ventaja en muchos casos. JSLINT es esencial. Cuando necesita hacer cosas al mismo tiempo, las devoluciones de llamada asincrónicas son mucho más seguras, más fáciles y, en última instancia, más productivas que cualquier idioma en el que tenga que usar hilos. Y tienes que saber JavaScript de todos modos porque es el idioma del navegador. James 29 de mayo de 2015 a las 16:19
  • Simpatizo con las preocupaciones planteadas y observo que se han hecho algunos esfuerzos para abordarlas, aunque ciertamente no se aplican universalmente. Hay un proyecto asombroso llamado Tern que puede proporcionar derivación de tipos a partir del análisis estático de código y bibliotecas Javascript. Tiene complementos para varios editores. También hay Typecript, JSDoc y BetterJS . Y luego está Go , ¡uno de los muchos lenguajes de compilación en Javascript ! joeytwiddle 26 de noviembre de 2015 a las 4:13