En el blog de Joose publican hoy un interesante proyecto. Básicamente, aprovecha la capacidad de proceso de los navegadores de los visitantes a la página para servir información a otros visitantes, de forma que una aplicación de Google App Engine actúa como intermediaria en lugar de como servidora de recursos.

Funcionamiento

• Cuando un usuario realiza una petición de una página del site
• ... la petición se gestiona por una aplicación de Google App Engine
• ... que pone la petición en una cola
• Mientras tanto en otro equipo que ejecuta el servidor de aplicaciones Javascript dentro de un Worker de Google Gears (recuerda el artículo reciente sobre concurrencia) dentro del navegador
• ... un cliente Comet mantiene una conexión pseudo-permanente con la aplicación de Google App Engine
• ... busca en la cola de peticiones y empieza a procesarla
• ... cuando ha terminado, le envía la respuesta a la aplicación de Google App Engine
• ... la que inmediatamente envía la petición de vuelta al cliente que originó la petición en un primer momento.

Ventajas

• Las peticiones de recursos al servidor se reducen porque cada cliente puede compartir parte de sus propios recursos con el resto de clientes.
• Funciona con Javascript
• Permite una integración transparente entre cliente y servidor.

Inconvenientes

• Cada servidor de aplicaciones se ejecuta sin ningún tipo de seguridad
• Por razones de seguridad, la respuesta del servidor de aplicaciones debe ser JSON. No puede ser HTML puro, porque cualquier cliente no autenticado podría inyectar scripts maliciosos en el flujo de datos.
• Google App Engine desgraciamente no provee una buena forma de implementar aplicaciones de estilo Comet con peticiones prolongadas porque tienen reglas muy estrictas respecto al tiempo de espera (timeout) de las peticiones.
• El servidor web incorporado en el SDK de Google App Engine no es multi-hilo. Por tanto, la aplicación no puede ser comprobada (fácilmente) con el SDK sino que debe ser desplegada en el sistema de producción.
• La implementación es muy muy conceptual en el sentido de hacer las cosas más simples que funcionen, sin comprobación de errores ni de condiciones de carrera (race condition) respecto a la cola de peticiones.
• No hay ninguna forma incluida para persistir datos en la demo actual. En cualquier caso, las aplicaciones podrían usar cualquier tipo de servicio web que esté accesible via JavaScript.
• Actualmente no hay forma de leer o escribir cabeceras HTTP desde las aplicaciones.

Demo de cliente. Se trata de un simple contador que sólo funcionará si se ha iniciado un servidor desde el iframe incorporado en el artículo del autor, hay otro visitante ejecutando dicho servidor o se tiene abierta la demo del servidor. Aquí se puede ver el código del servidor.