spinner

Aplicaciones ‘front’ SEO friendly gracias a las arquitecturas Serverless

El desarrollo web y de aplicaciones multiplataforma ha tenido en los últimos años un salto cualitativo gracias a la aparición de frameworks y librerías javascript apadrinadas por los principales actores del mundo de la tecnología (Google, Facebook, LinkedIn, …).

A la hora de elegir un stack tecnológico, son muchos los factores a tener en cuenta, como pueden ser las capacidades y experiencia de nuestro equipo, la extensión del proyecto, las distintas plataformas en las que queremos estar presentes o el soporte que la comunidad presta a esas tecnologías, que nos permitirán contar con una mejor documentación, formación y, finalmente, un abanico mayor de desarrolladores en el mercado que puedan participar en nuestro proyecto.

Otra variable muy importante -que suele ser olvidada hasta que se convierte en un problema– es el posicionamiento en buscadores de nuestra aplicación, ya que, en muchas ocasiones y dependiendo del objetivo del proyecto, puede llegar a ser algo crítico.

Tecnologías como Angular, React, Vue, Polymer o Ember no son “SEO friendly” de forma nativa, ya que basan su funcionamiento en la renderización en cliente (CSR), que tiene tanto bondades (sencillez de infraestructura, velocidad, simplicidad de desarrollo, …), como algunos inconvenientes, que detallaremos a continuación.

CSR SEO friendly

Fuente: The Benefits of Server Side Rendering Over Client Side Rendering

A pesar de que los principales buscadores (Google, Yahoo, …) dicen visualizar las aplicaciones como lo haría un usuario “estándar”, se ha comprobado que los resultados no son los esperados y las aplicaciones acaban siendo penalizadas, sufriendo una drástica caída en el posicionamiento.

Con el objetivo de mitigar estos inconvenientes, han aparecido tecnologías auxiliares que permiten renderizar nuestras aplicaciones javascript en servidor (SSR) ofreciendo a los usuarios (humanos y robots) el HTML resultante, lo que facilita la legibilidad a los buscadores y mejora la velocidad y, por tanto, la experiencia de usuario.

SSR aplicaciones Javascript servidor

Fuente: The Benefits of Server Side Rendering Over Client Side Rendering

 

La solución puede resultar, a priori, añeja, y hacernos replantear el stack tecnológico, lo que puede llevar a poner de nuevo sobre la mesa tecnologías del pasado felizmente superadas (PHP + jQuery, WordPress, …), que acababan generando problemas como la gestión de la infraestructura y la escalabilidad de la aplicación.

Estos inconvenientes se solventan desarrollando aplicaciones SPA, basadas en archivos estáticos que facilitan su publicación utilizando soluciones de almacenamiento de bajo coste y totalmente escalables complementadas con CDNs, como por ejemplo, S3 y CloudFront en Amazon Web Services.

Volver a introducir servidores de renderizado en la ecuación en lugar de soluciones serverless como las que nos permiten las aplicaciones SPA, es sin duda un inconveniente a tener en cuenta, pero no deben de asustarnos ya que las posibilidades son diversas y las muchas tecnologías existentes nos permiten afrontar el reto con las suficientes garantías de éxito.

Para diseñar nuestra arquitectura, vamos a utilizar como ejemplo una aplicación orientada al comercio electrónico, como podría ser una tienda de ropa.

arquitectura app AWS

Fuente: elaboración propia

Ignorando el requisito del posicionamiento en buscadores, una buena solución (sobre AWS), sencilla y tradicional podría ser la siguiente:

Como se puede observar, existen dos aplicaciones. La primera es la tienda online accesible y orientada al público en general, compuesta por un SPA desarrollada en cualquier framework/librería javascript (Angular, Vue, React, …), cuya versión de producción se encuentra en algún servicio gestionado de almacenamiento, como sería S3 en Amazon Web Services. Apantallamos la solución con un firewall de seguridad y una CDN para mejorar el rendimiento y dar una capa de caché a nuestra aplicación.

Adicionalmente, cuenta con una API que suministrará a nuestra aplicación toda la información, que no es motivo de análisis en este artículo.

Existe otra aplicación privada, el backend de nuestro proyecto, que nos permitiría gestionar la tienda online añadiendo nuevos artículos, stock, administración de pagos, etc. La arquitectura de la aplicación es similar pero, obviamente, sólo podrán acceder usuarios autorizados.

Esta arquitectura nos aportaría sencillez, elasticidad, seguridad y un rendimiento óptimo (suponiendo que la API también cumple con estos principios) pero no nos solucionaría el requisito del posicionamiento.

Para afrontar el problema, podemos hacerlo de varias maneras. Una de ellas sería redireccionar el tráfico originado por robots (buscadores, etc) a un servidor que nos permitiera renderizar en servidor. Es una buena solución ya que la infraestructura no requiere de gran complejidad debido a que el volumen de visitas sería muy reducido.

Esta solución podría extenderse a todo el público, algo que, obviamente, requiere de una mayor infraestructura. Se puede apantallar con una CDN reduciendo significativamente el número de peticiones.

Pensando en serverless, podríamos adaptar nuestra aplicación de renderizado para que funcione en algún servicio orientado a funciones, como por ejemplo, Api-Gateway + NodeJS (SSR) en Lambda. Probablemente esta no sería el mejor diseño para un proyecto productivo.

Quizás, la solución más elegante y que afectaría positivamente a todos nuestros usuarios sería renderizar en servidor ciertas partes de la aplicación que requieren de ser indexadas por los buscadores, como podrían ser los productos, categorías, etc.

Sería una forma de desacoplar la problemática y no requiere de modificación en el resto de piezas de la arquitectura. Una forma reactiva de plantearlo sería la siguiente:

arquitectura AWS DynamoDB Lambda

Fuente: elaboración propia

En el diagrama se representa como una actualización de artículo/categoría en DynamoDB (base de datos administrada por AWS) lanza un evento que ejecuta una función Lambda que nos permite renderizar en servidor la página del artículo que ha sufrido modificaciones.

Este archivo HTML es alojado en el mismo bucket que contiene la página web y pasa a ser accesible por todos los usuarios, que reducirán el tiempo de carga del artículo.

Esto resuelve también el problema del posicionamiento, ya que los robots visitarán esos mismos archivos HTML, que contienen toda la información necesaria para indexar correctamente el producto.

Aclarar que nuestra pieza dispondrá de una cola para aquellos procesos que puedan fallar (Dead-Letter Queue) y que deberán de ser “rescatados”.

La elección del software por tanto, no sería crítica, ya que en los últimos años han aparecido diversas soluciones para dar respuesta a este nuevo reto y permitirnos elaborar aplicaciones “Universales” o “Isomórficas” de forma relativamente sencilla.

Angular Universal, Rill Framework, Nuxt, Fast-Boot u otras tecnologías son buenas para dar respuesta a lo que parecía ser un problema, que, como hemos podido comprobar, es simplemente un requisito a tener en cuenta que puede ser abordado de distintas e imaginativas maneras.

Imagen: pexels.com

Las opiniones vertidas por el autor son enteramente suyas y no siempre representan la opinión de BBVA Next Technologies.

¿Quieres saber que más cosas hacemos en BBVA Next Technologies?