Real Time

[dual3nigma]

Que tal compañeros!!!!!

Les traigo mi último experimento que estoy por subir a github http://bit.ly/uMoGyi Prueben abrirlo en dos navegadores diferentes (webkit y gecko porfavor) y publicar algo.

Me ha interesado mucho este tema de las aplicaciones realtime, gracias a tecnologías como HTML5 y nodejs pronto podemos esperar que todas nuestras aplicaciones sean en tiempo real. Hasta ahora con lenguajes como python y ruby es posible obvio, pero un tanto doloroso...

Derby http://derbyjs.com/ es un framework MVC muy interesante, al principio lo probe y debo de confesar que me molesto un poco su actitud "mágica" de funcionar. Derby utiliza Racer https://github.com/codeparty/racer para mantener sincronizados los datos, ósea que también se encarga de resolver los conflictos que pueden surgir, etc. Derby utiliza Redis http://redis.io/ uno de los nuevos populares NoSQL o "data structure server".

En fin, el punto es que con este framework pude tener en un par de horas una aplicación real time, de forma sencillisima, suficiente de hablar, les muestro el código.

Empecemos con la "vista":

Código HTML:

<Body:>
  <div class="container">
    <div class="principal">
      <div class="publicaciones">((_wall.publicaciones > publicacion))</div>
    </div>
  </div>
 
<publicacion:>
  <blockquote>
    <p>{{.texto}}</p>
    <small>{{.fecha}}</small>
  </blockquote>
 

Para los que están familiarizados con los sistemas de templates modernos no será difícil apreciar la lógica, lo importante es que en Derby tenemos "Bindings" como en Flex ✝, Windows Presentation Foundation, etc. que se utiliza de esta forma ((_wall.publicaciones)), con esto las publicaciones se sincronizaran automáticamente en todos los lugares, estúpidamente sencillo no creen?

Algo que destaca mucho aquí es que con nodejs podemos compartir código, de echo en Derby escribes el código del frontend en el backend.... en cierta forma....

Vean por ejemplo mi "controlador":

Código Javascript:

ready(function(model) {
  exports.publicar = function () {
    // lo que se va a publicar
    var texto = view.htmlEscape(model.get('_nuevaPublicacion'));
 
    // agregar al principio
    model.insertBefore('_wall.publicaciones', 0, {
      texto: texto,
      // formato bonito
      fecha: dias[hoy.getDay()]+', '+hoy.getDate()+' de '+meses[hoy.getMonth()]+' a las '+hoy.getHours()+':'+hoy.getMinutes()
    });
  };
});
 

Estoy utilizando el modelo que funciona de manera transparente tanto en el backend como en el front end.


Bueno, prueben la app y me cuenta, yo mientras me apuro a subir el código a github para contarles mas.

Preguntas, comentarios? Que opinan? Creen que este tipo de tecnologías sustituirán a los apenas crecientes Ext.JS, SproutCore, Backbone.js??

Saludos

[Null_]

Maravilloso, últimamente me has sorprendido con tantas cosas que experimentas ¬¬ jaja

[dual3nigma]

Por aqui me hacen varias observaciones que vale la pena comentar. Recuerdan como con los métodos tradicionales de realtime como comet, server side events, etc. Tiene que renderar una vez la página desde el servidor y de ahí con Javascript comprobar que haya actualizaciones y si las hay $('.publicaciones').append('<publicacion />'); o para evitar eso cargar las publicaciones desde Javascript, pero entonces ya no es indexable, etc

Pues con Derby las "vistas" se comparten, no tienes que escribir dos códigos, esa "vista" que puse arriba se utilizara tanto en el backend como en el frontend.

[dual3nigma]

Ya pueden consultar el código en github: https://github.com/dual3nigma/Muro

Ningún comentario aun? Ahora que trate de no hablar mal de cristalab, jajaja no es cierto, échenle un ojo al código y me cuentan ;)

Saludos :D

[cvander]

Acabo de ver el demo y me gusta muchísimo. También me sumo a que tus experimentos están bastante buenos.

De hecho, es un chat bastante fácil y práctico de utilizar. Qué tal con la implementación y el tema del puerto (veo que usas el 3000), puede lograrse que corra en el 80 junto a apache para implementarlo en un servidor web?

[Aijoona]

Iniciado por cvander

Acabo de ver el demo y me gusta muchísimo. También me sumo a que tus experimentos están bastante buenos.

De hecho, es un chat bastante fácil y práctico de utilizar. Qué tal con la implementación y el tema del puerto (veo que usas el 3000), puede lograrse que corra en el 80 junto a apache para implementarlo en un servidor web?

El problema de ir por el puerto 80 es que asumis que es un request http, y eso conlleva headers que se vuelven muy costosos en comunicaciones en realtime.

[cvander]

Lo comprendo, pero si quisieras que fuera un servicio real y quieres asegurarte que no tengas problemas de conexión por puertos (firewalls y demás) es lo que toca hacer, no?

[Aijoona]

Según la especificación (RFC 6455):

The WebSocket Protocol attempts to address the goals of existing bidirectional HTTP technologies in the context of the existing HTTP infrastructure; as such, it is designed to work over HTTP ports 80 and 443

No necesariamente tiene que ser el puerto 80. De cualquier manera, cuando esta tecncología sea algo más común seguramente sea de practica global mandarlo por el puerto 80.

[dual3nigma]

Hola!!!! Gracias por comentar y disculpen la demora.

Nooooooo, no querras correr node.js sobre apache, me imagino que lo ven algo así como mode_wsgi para python, pero no, apache es cosa del pasado fue pensado con otro tipo de aplicaciones en mente. "Ya nadie va a usar apache"

Veran les explico un poco de como debe de funcionar este tema de los puertos. Con node.js se busca aplicaciones que puedan responder millones de requests. Esto se conoce como "load balancing" para lograr esto la solución común es correr varios procesos de la aplicación en lo cual node.js es muy generso debido a la poca cantidad de recursos que consume.

Supongamos que tengo mi aplicación en server.js, para correrla haré: node server.js. Este servidor lo pondré en el puerto 3000 por ejemplo de modo que corra en http://localhost:3000 en mi servidor esta dirección no estará accesible a todos sino solo local, lo que necesito ahora es una herramienta como nginx que me escuche las peticiones en el puerto 80 y las routee a mi aplicación en puerto 3000, por que no puse a mi servidor a correr en el puerto 80? por que este routeador se encargara de que cuando mi servidor en el puerto 3000 no pueda mas, habrá otra instancia, ósea otro node server.js pero esta vez corriendo en 3001 por ejemplo para así tener una aplicación con "high availability" o "scaling"

Queda mas claro? Servicios como heroku hacen todo este proceso muy fácil al ser solo necesario indicar scale=2 o scale=3, o así es en Google App Engine, no creo que ahí es instances: 2, pero bueno, el punto es que eso es lo que te facilitan esos servicios.

Ahora el tema de los WebSockets no hay que confundirlo, eso es otra cosa. No puedes abrir un websocket desde la barra de tu navegador, no funciona de esa forma. A ver, vamonos a lo básico, cuando escribes una dirección en la barra de tu navegador por ejemplo www.forosdelweb.com estas haciendo una solicitud http al servidor en el puerto 80, puedes indicar otro puerto, pero no otro protocolo, las paginas web se sirven mediante el protocolo http, es la forma que es. Y puedes tener un servidor node.js escuchando tales solicitudes en el puerto que quieras para servir una pagina web.

Otro cantar seria si fueran websockets, ese es otro protocolo. Si me pongo técnico, bueno en realidad WebSockets utiliza HTTP un poco, ya que se manda una solicitud http upgrade, para cambiar de protocolo.... y en este caso tu servidor node.js debe estar escuchando igual esta clase de solicitudes en el puerto que quieras.

Queda mas claro? o peor xD

Saludos!!!

[cvander]

Muy buena la aclaración. Entendí la gran razón por la cual vas a preocuparte de usar otro servidor de proxy para conectarte al puerto donde tienes abierto el servidor.

[mostaza4]

el ejemplo esta caido :/