No tires tu viejo framework web Java: la pequeña historia Single Page Interface de Twitter
jmarranzTwitter.com es uno de los sitios web más populares del mundo, poca gente sabe que es a su vez uno de los pocos sitios web Single Page Interface compatible SEO stateless del mundo.
Es decir es SPI en el sentido de que evita al máximo cargar páginas, cada click supone un cambio parcial de la página sin cargar una nueva página como tal, la información necesaria es obtenida por AJAX.
Es compatible SEO porque hay páginas que está diseñadas para ser accedidas por robots de buscadores tal y como el de Google y a la vez es la misma página que puede ser vista por un usuario logado. Por ejemplo http://twitter.com/jmarranz es la misma página tanto estando logado como si no lo estás, pero esa página es SPI si estás logado (cuando haces clicks en sus elementos no cambia de página) pero también es una página convencional si no estás logado, es decir al hacer click en esos mismos elementos cambias de página, es este segundo modo el que ve un robot rastreador de webs.
Los robots rastreadores de páginas (crawlers) como el de Google Search no interpretan JavaScript por ello ven el mundo de forma "paginada", por tanto no hay posible uso de AJAX en de la página cargada por el robot, si no existe una alternativa paginada, Google no procesará los estados cargados por AJAX, no es el caso de Twitter.
Es "stateless" o sin estado en el sentido de que Twitter procura que el servidor no tenga información del estado de la página que está viendo el usuario, es decir, datos de sesión web, esto permite que las requests puedan llegar a cualquier nodo de su cluster sin necesidad de compartición de sesiones o afinidad de servidor. Si se observan las peticiones AJAX que hace Twitter se envía un id que representa el estado temporal de la página del usuario indicando algo así como "de ahí para atrás ya lo tengo cargado, quiero las cosas nuevas".
Como veremos más adelante este enfoque SPI es céntrico en el servidor (aunque tiene mucha programación cliente), pero Twitter no ha llegado a la implementación actual en un primer intento, sino que hubo uno anterior cliente céntrico.
Primera versión: cliente céntrica
La primera versión Single Page Interface de Twitter usó un enfoque muy actual en el que "muchos" están últimamente explorando como "el camino a seguir".
La API REST de Twitter devolvía datos en formato JSON que renderizaba en el cliente el navegador a través de JavaScript, partiendo de una página web inicial más o menos sin contenido, contenido que iba obteniendo el navegador con sucesivos requests AJAX a la API REST.
Este enfoque que podemos considerar claramente cliente céntrico (la renderización de la página ocurría fundamentalmente en el cliente) permitía crear un sitio web Single Page Interface stateless para el usuario logado. En su momento se hacía un uso intensivo del sistema de hashbangs #! que permite tener links "compatibles SPI" y a la vez permitir bookmarks.
Desde hace un tiempo Google empezó a indexar los links hashbangs tal que Google pedía al sitio web una página alternativa que es la que verdaderamente indexaba.
Ejemplo:
Cuando Google ve: http://twitter.com/#!jmarranz
Cargará: http://twitter.com/?_escaped_fragment_=/jmarranz
Para ofrecer una versión SEO de las partes comunes tanto para buscadores como para el propio usuario, Twitter creó páginas alternativas. Si por ejemplo http://twitter.com/jmarranz se cargaba con el usuario logado (con las oportunas cookies) y con JavaScript activado, el mundo SPI estaba ahí disponible para el usuario, si no era así Twitter sabía que debía devolver una página completa compatible con los robots tal que los links sin JavaScript se comportaban como links normales cargando páginas completas.
Segunda versión: servidor céntrica o híbrida
A principios del año 2012 se produce lo que aparentemente podría calificarse como una revolución conservadora en la ingeniería web de Twitter, una aparente vuelta a las páginas, a la primera web pre SPI de Twitter, una retro-revolución liderada por Dan Webb
Todo parecía apuntar a un retorno a un sistema paginado clásico ligeramente especiado con JavaScript y AJAX con algunas cargas parciales pero lejos del modelo radical y puntero SPI de la versión actual en aquel momento, la cual parecía que se iba a deshechar prácticamente por completo.
Dan Webb parecía un declarado enemigo del Single Page Interface de acuerdo a un artículo en su blog en contra de los hashbangs de los cuales hablamos anteriormente, importante para conseguir SPI, bookmarking y compatibilidad SEO en todos los navegadores:
http://danwebb.net/2011/5/28/it-is-about-the-hashbangs
Sólo al final del texto del blog de Twitter parece que hay una luz para la esperanza SPI:
"What’s next? We’re currently rolling out this new architecture across the site. Once our pages are running on this new foundation, we will do more to further improve performance. For example, we will implement the History API to allow partial page reloads in browsers that support it, and begin to overhaul the server side of the application."
Las palabras clave son "History API".
Yo mismo alarmado al leer el ataque frontal a los hashbangs por parte del principal ingeniero de la parte web de Twitter, uno de los grandes impulsores del SPI, me atreví infeliz de mi a escribirle para "disuadirle":
https://twitter.com/jmarranz/status/174947731637403648 https://twitter.com/jmarranz/status/208876410016763904
En uno de mis rollos me atrevo a indicarle que mande a paseo su propio sistema REST y renderice parcialmente el HTML en el servidor:
"In AJAX requests avoid JSON and your own REST API, render in server your page chunks and inject the markup into the page with innerHTML as much as possible"
La respuesta de Dan Webb va en la línea de que aunque no parece plantearse el SPI sí se harán actualizaciones parciales via AJAX pero no usando hashbangs sino a través del history API (no siempre disponible).
El último tweet dice lo siguiente:
"we made our perf decisions based on data. It's not about liking or not liking a technique. It's about what we prove is fastest."
La verdad es que pensaba que se refería a un enfoque paginado, la sorpresa es que el enfoque del "nuevo Twitter" era sin saberlo más o menos IGUAL que el que planteaba en uno de mis tweets (aunque yo siempre he defendido los hashbangs):
https://twitter.com/jmarranz/status/208927214874542080
El enfoque híbrido SPI cliente-servidor céntrico del actual Twitter.com
En el tiempo en el que las conversaciones anteriores se llevaron a cabo, el "nuevo" Twitter.com apenas estaba naciendo, cambiando progresivamente el enfoque cliente céntrico puro basado en la API REST de Twitter por otro que podríamos llamar híbrido.
La principal motivación de la nueva arquitectura híbrida respecto a la cliente céntrica era precisamente el rendimiento:
"That architecture broke new ground by offering a number of advantages over a more traditional approach, but it lacked support for various optimizations available only on the server"
Las principales novedades de este enfoque son:
- La página cargada con usuario logado o sin logar es la misma en el caso de página pública visible sin login. Se pone fin al modelo de doble sitio web, usuario logado y no logado compatible SEO.
- Se sigue un enfoque Single Page Interface pero evitando el uso de hashbangs empleándose en su lugar History API. Como esta funcionalidad no está disponible en navegadores antiguos (IE 6-8) en estos navegadores minoritarios se acepta que la navegación de un usuario logado sea mediocremente paginada, en navegadores modernos es SPI al usar History API.
- Los cambios parciales de página se realizan renderizando los trozos a cambiar en el servidor, esto permite reducir y simplificar drásticamente el JavaScript necesario de gestión de la página, acelerar la renderización de los cambios así como disminuir el número de requests necesario debido a la granularidad de la API REST (en una misma request es posible combinar la obtención de varios conjuntos de datos a la vez ya renderizados como HTML el equivalente serían varias requests quizás con resultados vacíos en algunos casos).
¿Qué puede tener este tema de interés para un desarrollador Java?
Pues mucho, teniendo en cuenta que hay una tendencia actual hacia aplicaciones 100% cliente céntrico accediendo al servidor via APIs REST que devuelven JSON con datos.
Por tanto, no tires tan pronto tu viejo framework web, especialmente tu procesador de plantillas, es posible que lo vuelvas a necesitar :)
Nota: sí, este tema me pilla muy de cerca y soy parcial, como autor de ItsNat que es un framework precisamente con un enfoque de este tipo con el que no hace falta que trabajes en Twitter para conseguir hacer sitios web SPI stateless SEO compatibles similares. Pero más allá de mi interés por ItsNat, sinceramente creo en este tipo de arquitectura híbrida de renderización parcial en el servidor y quien ha trabajado conmigo sabe que lo he aplicado lo que he podido y me han dejado (y con resultados innegablemente buenos).
Reader Comments (2)
GitHub es también (casi) un sitio SPI. Para navegadores que no sean IE antiguos, usa el Histopry API en abundancia y siempre renderiza auquello que es necesario.
Personalmenre creo que es de los sitios web que mejor están construídos.
que buen análisis, espero que vengan mas