Presentación de Node.js

PiradoIV

Me resulta extraño que no se haya hablado de Node.js, una plataforma muy interesante para desarrollar aplicaciones de red con mucha carga.

"Node.js es una plataforma creada con el motor JavaScript de Chrome, para desarrollar aplicaciones de red rápidas y escalables. Node.js se basa en un modelo que responde a eventos, sin cuellos de botella de Entrada/Salida que lo hacen ligero y eficiente, perfecto para aplicaciones en tiempo real con mucha carga de datos y que corren a través de múltiples dispositivos."

Pros

Las bondades de Node.js todavía están por descubrir, todavía no había (que yo conozca) un sistema tan centrado en los eventos (programación asíncrona he leído por ahí que lo llaman). Sin embargo, sí que han podido demostrar lo bien que se defiende bajo una carga intensiva de trabajo, especialmente cuando otras tecnologías sensibles de quedarse colgadas (por ejemplo una base de datos), no afecten al resto de peticiones que le llegan a la aplicación.

Sus usos también están todavía por descubrir, he visto algunas demos montando servidores web y de chat y realmente tiene muy buena pinta. Aplicaciones cliente no he visto ninguna de momento, pero por lo menos ya podemos escribir código JavaScript fuera del navegador.

Viene con un sistema de descarga de módulos al estilo apt-get, como ya has podido ver en otras tecnologías como Ruby, Drupal, ...

Contras

Es una tecnología joven, demasiado joven. Tanto que ahora mismo, si estás buscando una biblioteca que haga tal cosa o tal otra, seguramente te la vas a tener que escribir tú mismo. Sí que existen algunos proyectos, pero todo es muy reciente:

· Express (Web Framework)

Si bien Node.js es muy escalable, escribir en JavaScript es susceptible de que se nos vaya de las manos y acabe convirtiéndose en el monstruo del espagueti volador, tendrás que andar con ojo.

Conclusión

Merece mucho la pena seguirle la pista a cualquier tecnología que gire en torno a JavaScript, parece que se está convirtiendo en un lenguaje bastante polivalente gracias a proyectos como este, Unity (motor 3D), Appcelerator (aplicaciones móviles y de escritorio) y tantos otros.

Ya existen empresas interesadas en desarrolladores para Node.js (tablón de trabajo).

Webcasts

Ahí van un par de videos de presentación muy interesantes, están en inglés.

¡Saludos!

4
elkaoD

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.

1 respuesta
X-Crim

pues vaya pintaza, no lo conocía.

scumah

En el curro estamos ya empezando con node :D 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 :P

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.

1 respuesta
eisenfaust

Reiventando la rueda (esta vez Erlang y OTP) en Javascript y 38 años tarde.

De momento es un proyecto popular (quizás el que más), pero a ver lo que dura hasta que salga algo parecido en Lua, IO o cualquiera que sea el lenguaje de scripting cool del momento. Y así iterando hasta el infinito xD

Buen hilo.

#2 Puedes probar a usar Lua o Chicken Scheme para scripting de juegos. Si no me equivoco son más eficientes que un V8 y en portabilidad andan a la par.

2 respuestas
Tig

Yo también lo estoy tocando un poco, aunque no he hecho mucho javascript y me cuesta ir pillando los conceptos.

1 mes después
EnZo

#4 "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"

Algo parecido a un servidor de sockets pero por protocolo http?

1 respuesta
elkaoD

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

1 respuesta
EnZo

#8 Es que entonces el que no te ha entendido soy yo.

Para que esos 10 ordenadores vean ese cambio al instante tienen que estar refrescando de forma continua (Hablando en terminos de web, porque no se si el ejemplo que dices era en web o no). O de lo contrario estar conectado de forma permanente al servidor como si fuese un servidor socket.

1 respuesta
elkaoD

#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.)

1 respuesta
EnZo

#10 Si, eso he entendido yo que tenia que estar usando sockets. Pero no se si del navegador (websocket, cosa que me extraña porque es algo que está muy verde). Y ajax va a ser que no, porque necesita estar haciendo peticiones igualmente aunque sean en segundo plano.

Así que creo que se referiria a un cliente realizado en otro lenguaje, supongo...

1 respuesta
elkaoD

#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.

1 respuesta
EnZo

#12 Mas que el mejor, es el mejor posible. Ya que su primera opcion es websocket (que practicamente no funciona en IE). Si nó, tirara de un swf donde logicamente necesitas flash player. Como tercera opcion ya usa peticiones AJAX que ya no son conexiones sockets.
De ahí que me extrañe que esten usando Socket.IO tan pronto.

1 respuesta
elkaoD

#13 selecciona el mejor tipo de conexión permanente que pueda

xD

Socket.IO puede funcionar sin SWF aunque está de los primeros de la lista al ser bastante conveniente, siendo casi como un websocket. A malas, malas puede usar una conexión abierta en el HTTP (sí, como un GET infinito, y esta conexión si es de socket.)

elkaoD

BUMP

Estoy trasteando con Node y me lo estoy pasando pipa. Es una lástima haya tocado tan poco JS client-side, me voy a tener que poner en serio. Ya se me han ocurrido 4 o 5 proyectillos ;) Me ha gustado tanto que me he planteado seriamente usarlo para el PFC.

#5 por lo que he visto lo realmente cojonudo de Node es precisamente eso, que es JS y no Erlang. Diría que son muy, muy parecidos. Sin embargo no veo muy adecuado un lenguaje funcional para despachar peticiones.

De hecho, la comparación no llega a ser acertada del todo. Son dos formas ligeramente diferentes de atacar el problema: Node no está nada orientado a concurrencia real, la ejecución se realiza en un sólo hilo, para lo bueno y para lo malo. Está enfocado a despachar peticiones y manejar IO asíncrona, eventos difícilmente paralelizables (la e/s va en serie.) Yo los veo más complementarios de hecho, creo que harían buen equipo (aunque creo que, para buen equipo, ¡Node.js+CUDA!)

Échale un vistazo, en serio, está bastante bien. No diría que es reinvertar la rueda, creo que JS es un candidato bastante viable. Closures+programación imperativa+prototipos = WIN. A mí me ha enamorado la forma de trabajar en Node y creo que ningún otro lenguaje de programación la igualaría.

2 respuestas
BLZKZ

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

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

1 respuesta
elkaoD

#16 depende, OpenCL es un estándar abierto pero CUDA está mejor documentado y ofrece más funcionalidad. Además en esta última versión permiten acceder a los framebuffers de OpenGL sin descargar a memoria, así que por fin tiene sentido para aplicaciones gráficas xD

Node.js yo lo describiría como JavaScript desembebido, ni más ni menos. Es un lenguaje interpretado más para el escritorio/servidor.

La aplicación real de Node.js son aplicaciones orientadas a eventos donde los eventos se despachen rápido y sin apenas intervención de la CPU y la respuesta de estos sea asíncrona. Node se ejecuta en un sólo hilo (por tanto, en un sólo core) por lo que funciona con callbacks sobre todo. Me explico: es útil para las tareas ligadas a la E/S. Llamas a la operación de E/S pasándole un callback y te olvidas de todo. Es útil porque es escalable de cojones. Además es especialmente interesante porque la arquitectura de JS es cojonuda para aplicaciones con callbacks y encima tienes el mismo lenguaje embebido en millones de clientes (navegadores web.)

Aplicaciones prácticas:

  • Páginas/aplicaciones web dinámicas (a lo GMail por ejemplo.)
  • Servidores de juego.
  • Coordinación de un clúster.

Aplicaciones menos prácticas:

  • Aplicaciones que tiren de CPU (la IA de un juego, por ejemplo.)
  • Páginas web semiestáticas (la típica web PHP que hace fetch de la BD, imprime y fin.) Para eso mejor usar un servidor normal y corriente.
1 respuesta
MisKo

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....

2 respuestas
EnZo

#18 Es un apache+php tengo entendido

1 respuesta
elkaoD

#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

1 respuesta
EnZo

#20 Me referia a que puede hacer las dos funciones en uno. No que se escriba en php ni que use apache ni nada parecido.
nodejs puede hacer de servidor web no?

1 respuesta
elkaoD

#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?

1 respuesta
EnZo

#22 Está claro que para un blog no vale. Pero para un facebook vendria de perlas no?

1 respuesta
elkaoD

#23 para un Facebook usaría una solución mixta. Contenido estático con servidor tradicional y unos cuantos servidores de Node replicados con un balanceador de carga sirviendo AJAX a saco (a poder ser websockets.)

Ojo, todo esto te lo digo con nula experiencia con Node en entornos reales, a lo mejor hasta me sorprende.

eisenfaust

Si no me equivoco hacen algo parecido. El back-end es C++, utilizan PHP para lo que todos sabemos y Erlang maneja colas y entregas (por ejemplo juega un papel muy importante en el chat).

Hay mucha literatura sobre el tema y aplicable a node guardando las distancias.

1 comentario moderado
EnZo

Despues de leeros me ha picado el gusanillo y en vez de aprender phyton quiero aprender antes node. Está muy divertido y me siento comodo programando en el porque ya sabia JS. Aunque su mecanica de trabajo es muy distinta de la que estoy acostumbrao (PHP).
La unica pega que le veo es que tienes que programar algunas cosas de base que otros lenguajes ya te daban mascadas. Aunque no paran de salir librerias y modulos para agilizar esto. Es cuestion de buscar :)

Pero venia aquí para que me aclaraseis un poco como funciona en cuanto terminos de peticiones y respuestas.
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?

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.

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?

PD: Para los que sepan php y quieran aprender nodejs http://phpjs.org/ viene de perlas para agilizar algunas tareas.

1 respuesta
elkaoD

#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.

1 1 respuesta
EnZo

#28 Ya se que no son del todo igual. Pero si se les puede comparar en rendimiento como servidor web. Aunque para eso habria que comparar apache+php vs nodejs.

Dicen que es mas lento, pero no tienen cifras para rebatirlo... Y hablan sobre otras opciones

Su argumento mas usado es que usa javascript como lenguaje. Y a ellos parece que les gusta poco xD

Lo que no he entendido del todo es que insinua que si rapido no tiene porque ser escalable. Y viceversa. Pero que tiene que ver? Pone como ejemplo mysql que dice que es rapida pero no es escalable. Oracle no es escalable a la vez que rapida? No entiendo que tiene que ver una cosa con la otra.

Son argumentos sin mucho fundamento a mi parecer.

1 respuesta
eisenfaust

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

2 respuestas