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

Soy nuevo en este tipo de cosas, pero últimamente he oído hablar mucho de lo bueno que es Node.js. Teniendo en cuenta lo mucho que me gusta 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 como Bitly - toma algún contenido, lo archiva.

De toda la tarea que he estado haciendo en los últimos días, he obtenido 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 de JavaScript
  • utiliza el gran motor V8 JavaScript
  • es muy bueno cuando se necesita hacer varias cosas al mismo tiempo
  • está basado en eventos, por lo que todas las cosas maravillosas del tipo Ajax se pueden hacer en el lado del servidor
  • nos permite compartir código entre el navegador y el backend
  • nos permite hablar con MySQL

Algunas de las fuentes que he encontrado son:

Teniendo en cuenta que Node.js se puede ejecutar casi out-of-the-box en Amazon's EC2 instancias, estoy tratando de entender qué tipo de problemas requieren Node.js en comparación con cualquiera de los poderosos reyes por ahí como PHP, Python y Ruby. Entiendo que realmente depende de la experiencia que uno tenga en un lenguaje, pero mi pregunta cae más en la categoría general de: ¿Cuándo utilizar un marco de trabajo en particular y para qué tipo de problemas es particularmente adecuado?

Yvette Colomb
Pregunta editada 2º noviembre 2018 в 11:23
Programación
javascript web-applications node.js
21º febrero 2011 в 5:20
19 vistas
Solución

Has hecho un gran trabajo al resumir lo que es impresionante de Node.js. Mi opinión es que Node.js es especialmente adecuado para aplicaciones en las que se desea mantener una conexión persistente desde el navegador hasta el servidor. Usando una técnica conocida como "long-polling", puedes escribir una aplicación que envíe actualizaciones al usuario en tiempo real. Hacer long-polling en muchos de los gigantes de la web, como Ruby on Rails o Django, crearía una inmensa carga en el servidor, porque cada cliente activo se come un proceso del servidor. Esta situación equivale a un ataque tarpit. Cuando se utiliza algo como Node.js, el servidor no tiene necesidad de mantener hilos separados para cada conexión abierta.

Esto significa que puedes crear una aplicación de chat basada en el navegador en Node.js que casi no necesita recursos del sistema para servir a un gran número de clientes. Cada vez que quieras hacer este tipo de seguimiento largo, Node.js es una gran opción.

Vale la pena mencionar que tanto Ruby como 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 callbacks, y sobresale aquí. Además, ser capaz de serializar y deserializar con JSON nativo tanto en el cliente como en el servidor es bastante ingenioso.

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

Vale la pena señalar que Node.js también es genial para situaciones en las que se reutiliza mucho código en la brecha cliente/servidor. El marco de trabajo Meteor hace que esto sea realmente fácil, y mucha gente está sugiriendo que esto 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, para que el código que se ejecuta en el navegador pueda manipularlo fácilmente y pasarlo de vuelta.

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

Martin
Respuesta editada 14º mayo 2014 в 3:56
Comentarios (4)

Creo que Node.js es el más adecuado para las 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 (¿o robot? ¿o sensor?) haga con la aplicación tenga que ser visto por otros usuarios inmediatamente, sin necesidad de actualizar la página.

También debo mencionar que Socket.IO en combinación con Node.js reducirá su latencia en tiempo real aún más de lo que es posible con el polling largo. Socket.IO recurrirá al polling largo en 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 los hilos puede ser mejor abordada con Node.js. O cualquier situación en la que necesites que la aplicación sea 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 de cerca con Nginx para las peticiones HTTP normales. Así que si construimos con Node.js, podemos servir nuestros recursos normales con bastante eficacia, 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.

Comentarios (3)

Para abreviar:

Node.js es muy adecuado para aplicaciones que tienen muchas conexiones concurrentes y cada petición sólo 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 Blog técnico de Mixu: Understanding the node.js event loop.

Peter Mortensen
Respuesta editada 14º marzo 2014 в 6:20
Comentarios (0)