Desde hace un par de años se viene dando un cambio en la forma de desarrollar sitios web que necesitan arquitecturas que contemplen la escalabilidad al máximo.

En el 2005 vimos cómo la introducción de XMLHttpRequest, más conocido como ajax, cambiaba las reglas del juego y elevaba las posibilidades del desarrollo web de una forma más que considerable, propiciando la creación de herramientas que facilitaban mucho más la interacción y que, junto a otras formas no técnicas de pensar y concebir los sitios web, desataron la fiebre web 2.0.

Desde esa época hemos visto aparecer un sinfin de nuevas tecnologías tanto de frontend como de backend que nos permiten hacer crecer nuestros sitios web usando buenas prácticas y con relativamente pocos recursos, al menos muchos menos que los que necesitábamos hace diez años.

De entre todas las opciones que van apareciendo, las tecnologías que más me han interesado recientemente son las permiten implementar patrones mvc o mvvm con javascript, separando totalmente el html + css + js que usamos en el frontend del backend.

Algunas de estas tecnologías aparecen motivadas por técnicas usadas en los frontend de Facebook o Tuenti por ejemplo, que cargaban diferentes partes de su contenido de forma asíncrona al cambiar de sección y sin refrescar todo el layout, mejorando la experiencia de usuario notablemente.

Existen varias opciones: javascriptMVC, knockout y backbone, entre otros. Yo me he decidido finalmente por backbone, básicamente porque me parecía más cercano a la forma que tengo de trabajar con soluciones de frameworks mvc para web y he visto que cuenta con un gran apoyo por parte de desarrolladores frontend.

No hace falta tener mucha experiencia en el desarrollo web para ver las tremendas posibilidades que ofrece backbone en cuanto arquitectura y escalabilidad.

La ventaja más evidente es que nos libramos de tener vistas html mezcladas con código de servidor en el backend. Las vistas se procesan y parsean en el cliente, con javascript, pudiendo usar cualquier motor de plantillas para javascript como mustache.

Mustache parece la mejor opción ya que cada vez más se viene asumiendo como estándar la sintaxis de django para templates html, que se ha adoptado en motores de plantillas de otros lenguajes como en el caso de php en el que disponemos de Twig (usado en Symfony2) o Haanga. Es importante esto si queremos dar compatibilidad a clientes que no tengan habilitado javascript en el navegador, una buena práctica que en algunos casos puede ser totalmente necesaria aplicar.

Esto nos permite tener en un sólo directorio y servir directamente como estático el código html de todas las plantillas de la aplicación web, con las ventajas evidentes de que los maquetadores y diseñadores puedan trabajar con ellas directamente sin tener que conocer el lenguaje de servidor que la web está utilizando, además de poder servir todo el html como estático, reduciendo los recursos necesarios de procesador en nuestra aplicación web y pudiendo cachear todo desde en el cliente con HTTP Cache, usando las directivas de caducidad max-age y s-max-age.

Las plantillas pueden recibir información a través de un objeto json, que normalmente incluirá el Modelo. El modelo se puede integrar muy fácilmente con nuestra API de servicios en el backend, permitiéndonos hacer un CRUD desde el cliente de forma transparente y sin importar la tecnología o tecnologías escogidas en el backend.

Como en todo buen framework MVC para web, disponemos de un router en el que podremos definir las urls de nuestra aplicación siguiendo un esquema de urls ajax basadas en hashbang (utilizando el símbolo #) perfectamente indexable por buscadores.

Cada ruta dispara un evento al que podemos suscribirnos para cargar el contenido necesario en el layout de cada vista. Estas peticiones se hacen mediante ajax, por lo que podemos pensar en las siguientes ventajas:

Primera ventaja: Utilizando correctamente HTTP access control podremos distribuir como queramos, y en base a nuestras necesidades, cada recurso o parte de nuestra aplicación en servidores, clusters o servicios cloud distintos, teniendo cada uno en su propio dominio o subdominio.

Al poder ser nuestro frontend totalmente estático (se basa en html, js y css), podemos utilizar frontales web que únicamente sirvan html o incluso servicios de storage cloud, como Amazon S3 con CloudFront, teniendo distribuida nuestra aplicación geográficamente con un coste inicial bastante bajo si tenemos implamentada una buena estrategia de caché en el cliente y en el backend.

Segunda ventaja: Podemos utilizar diferentes tecnologías para cada parte de nuestra web. Esto lo podíamos hacer ya utilizando Edge Side Includes a nivel de proxy con Varnish por ejemplo, ahora no es necesario aunque podría ser completamente complementario.

Tercera ventaja: Nos obliga a desarrollar la capa de servicios desde el principio, teniéndo nuestra arquitectura frontend-backend desacoplada, respetando totalmente REST, permitiéndonos de una forma cómoda en un futuro usar clientes diferentes al navegador sin tener que plantear hacer una api como una problemática adicional.

Cuarta ventaja: Podemos usar el histórico de Backbone o directamente el History de HTML5 para cachear la navegación del usuario en el navegador, haciendo cosas tan interesantes como el Tree Slider de Github.

Backbone nos da más opciones y herramientas útiles para el desarrollo con javascript, pero creo que las que he mencionado son lo suficientemente interesantes como para motivarnos a pensar en otras formas de plantear nuestros sitios web en el futuro.

Incluso en algunos casos podremos plantear prototipos de nuestros productos, perfectamente testables en html, antes de tomar ninguna decisión tecnológica de backend e incluso antes de tener que desarrollarlos.

Las posibilidades son increíblemente atractivas.

PD: El título es sólo para llamar vuestra atención, actualmente prefiero el sexo a backbone.js.