Presentación de Node.js

Conocí Node.js cuando me lo comentó un colega que trabaja en un proyecto web grande. No sé qué tal le irá, pero en su día hablaba maravillas.

A ver si le echo un vistazo a fondo, tiene muy buena pinta, pero como tú mismo dices siempre lo he visto muy "de servidor". Me planteé en su día cascar V8 o Node como sistema de script para un jueguecillo que estaba haciendo, pero el binding es un dolor y no me quedó muy claro si se puede hacer en caliente o no, así que acabé ni intentándolo.

Node me hubiera venido genial, ya que como dices está basado en eventos y encima permite prototipado de objetos, perfecto para juegos. A ver si le echo un vistazo más a fondo o alguien se curra una librería/aplicación para hacer más amigables los bindings.

En el curro estamos ya empezando con node Está muy bien, pero es para lo que es. Es decir, node viene de puta madre, por ejemplo, para hacer aplicaciones en tiempo real (Es tremendamente rápido), para resolver situaciones de mucha concurrencia (Se tarda esencialmente lo mismo en despachar 1 petición que 500 si hablamos de un proceso sencillo) o si tenemos la necesidad de mantener una conexión persistente con el cliente. Ahora, si lo que quieres es un blog, usa wordpress xD

Y ojo, aunque es relativamente joven (más de dos años ya) sí que hay muchísimas cosas hechas, desde conectores y ORMs para un montón de BDs (Postgres, MySQL, SQLite, MongoDB, SQL Server...), hasta clientes para APIs de decenas de servicios (Amazon S3, redes sociales, dropbox, github, google...), Pasando por cientos de módulos y frameworks que facilitan bastante el coñazo apestoso de desarrollar una aplicación en js.

Y de verdad lo digo, ver como uno cambia una cosa en una aplicación hecha en un rato y que al mismo puto instante se cambie en otros 10 ordenadores (No tenemos más, aunque también iría bien con 50 xD) conectados a la web, llama la atención. Y no conectados en local, si no compartiendo todos una conexión mala

Es cierto que echa para atrás, porque es más feo que un pie, pero yo creo que cuando esto explote veremos bastantes cosas nuevas por la web, que no es poco.

#7 wut? No, para nada (o no te he entendido bien.)

#9 creo que se refiere a que puedes tener esos 10 servidores (replicados o lo que sea) y meter la actualización en caliente con un pequeño restart. Imagina por ejemplo un servidor típico de imágenes, replicado para balancear la carga. En cuanto testées bien el JS en el entorno de pruebas lo metes en producción y el cambio se activa en caliente sin downtime ni leches.

No es que el cliente lo vea en vivo, sino que los cambios se replican a todos los servidores fácilmente. Lo de que vea el cliente en vivo lo que sea se puede hacer obviamente, pero es cosa de la implementación (como tú mismo dices AJAX, websockets...)

EDIT: Releyendo, creo que se refiere a Socket.IO.

#5 Chicken Scheme no conozco (echaré un vistazo) pero LUA si he trasteado con ello y acaba siendo un dolor los bindings (es donde fallan la mayoría de sistemas de script.)

#11 no, no, Socket.IO realiza la abstracción y selecciona el mejor tipo de conexión permanente que pueda para el cliente... sin usar programas externos.

yo aun no tengo claro que es node.js :/ o su aplicación real

#15 no seria mejor opencl+node.js ? XD

Vale, os he ido leyendo y tal, y no se si es que no me queda muy claro, pero yo , mas que nada por el ultimo post ( #17 ) , me suena mas a por ejemplo los metodos ajax de jQuery.

$.post( pagina_que_te_da_la_respuesta , datos_que_envias , funcion_callback )

Es decir, lo que hace node es pedir datos, y qndo los tengas, haces algo con esos datos??

Solo eso? , si es solo eso, supongo que sera muy eficiente, o igual lo he entendido yo mal .

A ver si me lo podeis explicar mejor =)

EDIT:

Viendo mas ejemplos en la web, lo que veo es que esto sería para montar la parte del servidor, no? es decir, node es el que se encargaría de dar la información a quien se la pida.

Voy a ver como se conectaria con mysql y esas cosas....

#18 básicamente has pillado bien el concepto. OJO, por mucho que sea el complemento perfecto a AJAX no se limita sólo a web. Vale para TOOOOODO tipo de aplicaciones. De hecho yo ahora estoy haciendo una aplicación cliente en Node (híbrida en realidad, pero el servidor es solo para ver estadísticas.)

Como a mí me gusta resumirlo: Node no es más que JavaScript desembebido+framework orientado a eventos asíncronos. El uso que le des es cosa tuya.

#19 wat???? Para nada xD

#21 buah, te había entendido fatal. Sipe, Node puede hacer de servidor web y lo que haga falta. Al fin y al cabo HTTP ni siquiera tiene estado y Node maneja sockets, así que es un candidato ideal.

Sin embargo Node no es un servidor web. HTTP no es más que un módulo que puedes usar o no. Es de los pocos que vienen en las librerías incluídas por defecto (core, el mínimo) aunque en el propio manual comentan que está en el límite de lo que se podría considerar aceptable para core.

Aún así, usar Node como webserver para algo que requiera escalar a lo grande es una aberración en mi opinión. ¿Para qué usar Node si tienes servidores optimizados para ello?

#27 Me gustaría saber que le hace especial sobre otros competidores (php,phyton,ror). Comentais que trabaja sobre un solo hilo, php tambien trabaja sobre un unico hilo no?
La clave aquí es darte cuenta de la comparación engañosa entre PHP y Node: estás comparando una pequeña parte del "stack" web típico con un sistema software de propósito general... ¡son incomparables! (fíjate que con PHP no podrías hacer el trabajo de Node, aunque sí puedas al revés.)

En efecto PHP trabaja sobre un sólo hilo en cada petición (no es más que un procesador "enganchado" al servidor web) pero el servidor web sobre el que se ejecuta no tiene por qué trabajar sobre un sólo hilo. Por ejemplo, con Apache se tira normalmente sobre varios hilos o procesos (o híbrido.)

RoR es aún peor comparación, puesto que no es más que un framework de aplicaciones web sobre Ruby. Podrías compararlo con Ruby a secas en todo caso. La comparación con Ruby/Python es más acertada en cierto modo, pero sigue errado en un aspecto fundamental. Lo que hace especial la arquitectura de Node es que está basado en eventos y que estos son asíncronos (haciendo uso de callbacks.) Esto lo podrías comparar con usar Python+Twisted. Las diferencias en este caso serían menores, excepto por aspectos como el rendimiento (habría que hacer benchmarks, aquí ya no me atrevo a decir nada) y sobre todo el lenguaje.

¡OJO! El lenguaje es un aspecto bastante importante. Javascript es lo que es, con sus ventajas y desventajas. A mí me gusta mucho el prototipado de objetos y los aspectos funcionales del lenguaje, aunque me disgusta bastante que el código puede(acabar, siendo(){unaputa(locura(){})}) si te descuidas. De hecho creo que es la razón por la que es tan odiado, es el lenguaje menos elegante que te puedas echar en cara y permite hacer mierdas MUUUUUY gordas. Por suerte o por desgracia CoffeeScript arrela un poco la situación.

Lo unico que casi he entendido es que es capaz manejar varias peticiones al mismo tiempo sin tener que hacer colas. Quiza te refieres a eso #15.
No es que no haga colas en realidad, lo explico mejor en el siguiente punto.

Y tambien me gustaria saber porque resulta mas escalable que otras opciones. Por que la aplicacion se puede distribuir en varios servidores con mas facilidad?
La escalabilidad viene por todo lo que he comentado antes. El uso de procesos/hilos no escala porque requiere costosos cambios de contexto (incluso en los "ligeros" hilos) mientras que la arquitectura basada en eventos escala linealmente. Si una petición la despachas en n, 1000 peticiones las depachas en 1000*n (en el mundo ideal de Yupilandia.) No hay cambios de contexto asociados ni ningún otro tipo de overhead aparte del inherente al problema (y el despachado de los eventos, obviamente, pero este escala linealmente también.)

Además, al ser una arquitectura asíncrona no te quedan hilos bloqueados gastando preciosos recursos. Cada vez que un hilo está esperando I/O y queda bloqueado gasta recursos. Para uno o dos hilos no pasa nada, pero con miles de usuarios empieza a ser un problema.

EDIT: Aquí tienes un post butthurt de un hater de Node.js. Te lo pongo para que tengas ambos puntos de vista.

Creo que Node en efecto tiene problemas pero el artículo va algo desencaminado. No le falta razón del todo, pero IMHO, no es más que algo escrito sin mucho entendimiento de qué y para qué es Node salpicado con butthurtismo (el blog del menda es un poco butthurt en general xD), pero bueno, ahí lo dejo...

EDIT2: Aquí alguien con argumentos más sólidos.

Ya que habláis de benchmarks aquí dejo algo que puede ser de ayuda.

http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks