¿Sitios Web Single Page Interface Céntricos Servidor prácticamente sin estado? ¿Bromeas?

En TheServerSide.com he publicado un artículo sobre como es posible construir sitios web céntricos en el servidor que sean prácticamente sin estado.

Para facilitar su lectura lo escribo también en español.

El Single Page Interface (SPI) es un paradigma del diseño web que promueve que cualquier sitio web (o aplicación web) puede funcionar completamente en la misma página sin recarga, preservando el SEO, con soporte de botones atrás/adelante (navegación por la historia en general). SPI soluciona muchos problemas de la navegación basada páginas y proporciona una experiencia más rica del usuario, el paradigma de SPI es ya habitual para las aplicaciones web… ¿porqué no para los SITIOS WEB? El Manifiesto Single Page Interface muestra algunas ideas técnicas de cómo alcanzar este objetivo para sitios web.

Mucha gente piensa que SPI implica toneladas de código a medida de Javascript (es decir un enfoque cliente-céntrico), hay dos razones genéricas:

1. RIA = Javascript
2. Debido a que los enfoques céntricos en el servidor necesitan mucha memoria en el servidor pues el estado visual es gestionado en el servidor, asumible en aplicaciones web pero no en sitios web.

La primera declaración es parcialmente verdad, por supuesto RIA implica el uso extensivo de Javascript, pero RIA no implica cliente-céntrico.

RIA es:

1. Un sitio web bonito: es decir HTML, CSS e imágenes bonitas, nada que ver con Javascript
2. Cambios de la página parciales sin recarga de página: implica Javascript, pero el Javascript se puede servir desde el servidor
3. Cambios bonitos en la representación visual conducidos por los movimientos del ratón y cambios visuales temporizados (generalmente movimientos y cambios de opacidad): apenas suponen cambios en los atributos class y style de los elementos. Ciertamente esta clase de efectos visuales no se pueden procesar en el servidor, una librería JavaScript adecuada para este fin puede ser muy útil, ¿pero estos efectos visuales implican necesariamente un enfoque cliente-céntrico del sitio web/aplicación?

La segunda razón, la necesidad de mucha memoria en el servidor en los enfoques server-centric, es mucho más difícil de refutar.

El manejo de un sitio web complejo SPI equivalente a centenares de páginas es extremadamente difícil con un enfoque cliente-céntrico, debido a la debilidad de Javascript, a problemas de seguridad, a la necesidad de puentes a medida de comunicación cliente-servidor, en el mejor de los casos será necesaria la colaboración del servidor. Todo podría ser más fácil si el sitio web se cargara completamente en memoria, pero como se puede suponer este acercamiento no es práctico y consume innecesariamente mucha memoria en el cliente y ancho de banda.

La alternativa es un enfoque céntrico en el servidor.

Los sitios web SPI es un tema muy nuevo y casi huérfano en tecnología web, más aun céntrico en el servidor, es muy difícil encontrar una tecnología capaz de proporcionar gran flexibilidad, amigable con los botones atrás y adelante y compatible SEO.

Es difícil pero no imposible, ItsNat desde hace tiempo se ha especializado en este paradigma emergente aplicado a sitios y aplicaciones web.

Cuando desarrollaba este sitio web SPI demostrativo tuve mucho cuidado con usar la menor memoria posible en el servidor, apliqué las mejores técnicas proporcionadas por ItsNat para este fin:

1. Cacheado de zonas estáticas del HTML: si una zona es estática, es decir, no se requiere renderizar con datos dinámicos de ninguna clase, esta zona puede ser declarada como cacheable en plantillas (de tipo página o fragmentos), las zonas cacheadas están ausentes  en el servidor porque se comparten entre los usuarios como texto serializado (no DOM), ItsNat envía al cliente estas zonas cacheadas cuando se necesita.
2. Uso de listeners/eventos definidos por el usuario globales para evitar que los elementos pulsables se reflejaran en el DOM servidor como alternativa a registrar mouse event listeners en cada uno ellos (el enfoque más simple y más puro serrvidor-céntrico de ItsNat).

A pesar de las técnicas anteriores, algunos estados consumían mucha memoria, por ejemplo la lista de televisiones LCD, esta lista se debe renderizar en el servidor con los datos extraídos de una base de datos (simulada). Como esta zona es renderizada con datos dinámicos no puede ser estática, aunque se hayan usado user events en los links que sirven para mostrar los detalles del producto.

Me di cuenta de que esta lista de modelos de TV no iba a ser utilizada más adelante tras su renderización en el servidor y envío al cliente, como mucho este sub-árbol DOM será substuido más adelante completamente cuando se cargue un nuevo estado de la página.

¿Qué pasa si eliminamos los subárboles DOM que ya no van a ser utilizados más pero sólo en el servidor para ahorrar memoria?

De la respuesta a esa pregunta nació la característica más interesante de ItsNat v1.1. Desde esta versión es posible eliminar manualmente sub-árboles DOM que se considera que ya no van a ser modificados (es decir pasan a ser estáticos) con una simple llamada. La misma zona en el cliente permanecerá intacta y podrá modificarse libremente sin el problema de la desincronización cliente-servidor.

La desconexión es reversible, simplemente añadiendo un nuevo nodo en el servidor al nodo padre de la zona desconectada y la zona correspondiente del cliente se sincronizará de nuevo con el servidor o bien a través de una llamada a este método.

Esta nueva característica fue aplicada a la demo, el sitio web resultante es fundamentalmente siin estado y al mismo tiempo céntrico en el servidor y Single Page Interface.