Story
SPA
Bloomreach

Cómo usar Single Page Applications con el CMS Bloomreach

Francisco Javier López | 18 de marzo de 2020

Las Single Page Applications (SPA) son herramientas muy útiles para crear experiencias atractivas para sus usuarios. Gmail, Google Maps, AirBNB, Netflix, Pinterest, Paypal y muchos más utilizan las SPA para construir una experiencia fluida y escalable.

Sin embargo, en el pasado, las SPA no eran la mejor elección para una tienda online cuando se trataba de administrar el contenido. Afortunadamente, ahora resulta muy sencillo emparejar tu SPA con el CMS correcto para brindar a desarrolladores y marketers el control que necesitan.

Primero deberemos saber qué son las spa o single page applications. El principio central de una SPA es que es una sola página (de ahí su nombre) que en su mayor parte permanece inalterable y sólo unas pocas piezas necesitan actualizarse. Por ejemplo, cuando navegas por tu correo electrónico notarás que no hay muchos cambios durante la navegación: La barra lateral y el encabezado permanecen intactos a medida que navegas por la bandeja de entrada. La SPA solo cambia lo que necesita con cada clic, y tu navegador solo actualiza esa información. Este método hace que el tiempo de carga sea más rápido y que la cantidad de información que un servidor tiene que enviar sea mucho menor y más rentable.

Además de la eficiencia, las SPA tienen éxito entre los desarrolladores porque la separación de los servicios de back-end y front-end hace que la construcción de un nuevo front-end sea mucho más rápida, sin afectar al back-end, ya que el nexo de unión entre ambos se abstrae a una API de llamadas compartida. El backend solo envía contenido, por lo que toda presentación está contenida en el front-end.

En resumen, una SPA brinda a los desarrolladores mucha libertad.

La nueva forma de usar SPA con un CMS

Si las SPA son tan buenas, ¿Por qué no las usa todo el mundo? Lo cierto es que al comienzo de la aparición de las SPA, la libertad que daban a los desarrolladores se vió perjudicada con la desaparición de características de marketing como la vista previa, la edición, la reutilización de contenido y la personalización.

Con la estructura desvinculada de las SPA, el CMS envía el contenido a la SPA, que decidirá cómo se ve. Esta técnica se denomina "headless", ya que el CMS no se encarga de la capa de presentación. El problema es que la edición "what-you-see-is-what-you-get", a la que están acostumbrados los especialistas en marketing, necesita esa capa de presentación. Sin ella, volvemos a la era de piedra digital de añadir contenido en un formulario, hacer clic en publicar y esperar a ver cómo ha quedado. Además, para cualquier nueva adición o cambio en esa SPA, como construir una nueva landing page (conocido como una ruta en una SPA), los técnicos en marketing deberán reunirse con varios desarrolladores para cada cambio, lo que crea un cuello de botella.

Además, debido a que muchos CMS generan sus páginas de edición y personalización, la edición de contenido resulta difícil al usar las SPA.

Entonces, ¿Los marketers están condenados para siempre a no poder usar las SPA? Claro que no, simplemente necesitan un CMS que tenga una arquitectura adaptada para el uso de las mismas. Es decir, uno que cumpla los siguientes requisitos:

  • Basado en peticiones a una API.
  • Contenido de la presentación que se pueda desacoplar.
  • Pueda proporcionar vista previa y edición en vivo.
  • Admita una configuración híbrida.
  • Permita la personalización en el lado del servidor. SPA CMS Headless

Un ejemplo de CMS que admite a la perfección una SPA es BloomReach. El cual da soporte específico para SPA en su catálogo de productos, ya que BloomReach considera que una herramienta empresarial debería fomentar formas de trabajo nuevas y eficientes como ésta. La mejor manera de dar a los desarrolladores libertad es garantizar que Marketing conserve todas las funciones de edición a las que están acostumbrados, y que sea más fácil de programar.

Flexibilidad para los desarrolladores

BloomReach (brXM) siempre ha contado con separación de contenido, código y presentación que lo convierte en un CMS “headless” completo. La arquitectura fue diseñada para su reutilización; y el contenido, los datos y la estructura se puedan compartir entre sites, dispositivos y sistemas de terceros. BloomReach no sólo puede distribuir contenido de esa manera amigable con la API, sino que también puede distribuir la lógica detrás de ese contenido de la misma forma. En el lado del servidor, la plataforma BloomReach puede usar el comportamiento de navegación, datos de terceros y enlaces internos para determinar el "kit de contenido" adecuado para entregar este contenido y lógica en formato JSON, neutral a la presentación. Esta es la clave para que BloomReach sea tan amigable con la SPA.

Soporte híbrido

Muchas empresas usan SPA en una parte de su web, mientras mantienen otras partes como una página tradicional, generada por servidor. La separación de contenido y presentación de BloomReach lo hace posible. Otro aspecto clave de este soporte híbrido es la capacidad de vincular internamente las SPA y las páginas tradicionales. Con BloomReach, esto es posible mediante la capacidad de asignar cada pieza de contenido a una URL individual. Al crear contenido, habrá la opción de hacer un enlace "interno" o "externo". Un enlace interno significa que el contenido puede representarse dentro de la SPA actual, y la SPA solo realizará una actualización parcial de la página (en lugar de realizar una solicitud de página completa). Un enlace externo es el utilizado para acceder al contenido fuera de la SPA.

Este enlace se comunica a través de la API del modelo de página, que genera enlaces para:

  • La URL actual (la página).
  • Por componente.
  • Por modelo de componente (por ejemplo, un menú).
  • Para cada elemento de contenido.
  • Para enlaces de contenido enriquecido.

Por ejemplo, supongamos que tu blog está realizado a través de una SPA mientras que tu página de inicio es una página del lado del servidor tradicional. En la configuración, podemos decir que todo lo que se encuentra debajo de "/blog" tiene el mismo ID de aplicación, por lo que forma parte de la aplicación de blog, también conocida como un elemento secundario heredado.

Otro ejemplo es que si se están enlazando entradas de un blog, se usarán enlaces "internos" y su SPA solo solicitará el nuevo texto e imágenes del blog, mientras que la vinculación desde el blog a la página de inicio será un enlace "externo" y se realizará una carga de página tradicional (no SPA). Con esta configuración de desacoplamiento de contenido y código se puede combinar una o varias SPA con páginas del lado del servidor, o páginas del lado del servidor y una Aplicación React y una Aplicación Angular, o una combinación de cualquiera de los anteriores. Su arquitectura es más escalable y el contenido y la lógica se pueden compartir. Además, los equipos de marketing no necesitan preocuparse de si su contenido está en una SPA o no, pueden crearlo y vincularlo normalmente.

Se mantienen las características necesarias.

Independientemente de cuán flexible sea un sistema a construir, si los técnicos de marketing no pueden hacer su trabajo sin pasar por los desarrolladores para cada actualización, habrá un cuello de botella. Esta es la razón, por la cual, uno de los principales factores del soporte de SPA de BloomReach es garantizar que los marketers puedan actualizar y editar experiencias impulsadas por SPA en la forma en que están acostumbrados a administrar páginas tradicionales.

Previsualización

Para poder editar de la manera “what-you-see-is-what-you-get” (wysiwyg) a la que están acostumbrados los marketers, primero debemos poder ver lo que se puede editar. Sin embargo, el quid de una SPA es que todas las piezas de la web generada se juntan en el front-end, por lo que esto significa que su CMS debe tener un front-end propio adaptado a la edición. BloomReach siempre ha manejado su funcionalidad de vista previa de esta manera.

Analicemos cómo funciona, en este caso, la SPA rápidamente: Para proporcionar una vista previa en el CMS, utiliza un sitio especial de vista previa que se encuentra en un servidor. Actúa como cualquier otro sitio: Un navegador le solicita información, se ejecuta en la base de datos para verificar si tiene la versión más actualizada de esa información y envía la información nueva certificada. La diferencia clave es que está configurada para que podamos encontrar todo el contenido, esté o no publicado. En cierto modo, la vista previa en el CMS está actuando como lo haría al usuario final, con la diferencia de que el front-end mostrado en el CMS está preparado para su edición.

SPA CMS Preview general

Con esta configuración ya implementada, poder obtener una vista previa de las SPA no es un gran salto. La SPA y el CMS tienen un contrato API (definido durante la integración) sobre qué componentes se pueden editar en el CMS: Los metadatos de la API le dicen a la SPA cuáles de estos componentes están presentes, las propiedades de cada componente y un mapa que contiene todo el contenido al que hacen referencia.

La SPA que genera nuestra vista previa tiene su propio modelo de página (también conocido como el mapa de componentes y contenido). Cuando realizamos un cambio editando la vista previa, el CMS compila un nuevo mapa basado en esos cambios. Ésto solo cambia el mapa para nuestra vista previa, por lo que el mapa que obtiene el público y el contenido que están viendo no se ve afectado.

La SPA toma el nuevo mapa y presenta la vista previa actualizada. Al publicar, se reemplaza el mapa antiguo en la base de datos con el nuevo, y cuando un visitante público solicite el mapa, sus servidores le entregarán el nuevo.

SPA CMS preview

Nuevas Páginas

Con las Single Page Applications, se crea una nueva vista (o una nueva ruta), en lugar de una página real. Con el soporte de SPA de BloomReach, un técnico de marketing podría crear estas nuevas vistas de la misma manera en que están acostumbrados a crear páginas. Creará una nueva página en el Modo de edición (como lo haría normalmente), y se le dará una nueva plantilla en la vista previa donde también puede agregar contenido y contenedores. Del lado del CMS, esta nueva plantilla y el contenido que añade se está serializando y agregando al modelo de página, mientras que como editor se puede crear (y eliminar) como de costumbre.

Drag and drop

Gracias a las etiquetas de metadatos que utiliza la API de BloomReach, la lista de componentes y contenido que el CMS le da a la SPA se divide en partes con puntos bien definidos de "inicio" y "fin" en el mapa. Si arrastramos un componente a una nueva ubicación en la vista previa, el CMS notará que el orden ha cambiado y actualizará el orden de esa lista. La SPA luego mostrará la lista en el nuevo orden. Podemos, entonces, mover los componentes de la manera estándar wysiwyg, y la API se adapta para que funcione para la SPA, sin necesidad de ningún desarrollo.

Personalización

Aquí es donde la personalización de Bloomreach basada en componentes del lado del servidor es realmente útil. La personalización de contenido se realiza creando variantes de contenido y componentes, reuniendo los datos correctos de forma nativa y mediante la API, además de segmentar los visitantes para determinar quién ve qué. Cuando un visitante entra en la página, el módulo Relevance de BloomReach personaliza la página en tiempo real:

  1. El navegador (o en este caso la SPA) hace la solicitud del contenido que necesita.
  2. El servidor BloomReach recibe la solicitud y aquí se inicia el módulo Relevance de BloomReach.
  3. El módulo Relevance buscará toda la información y cargará el contenido correcto basado en el perfil que se crea.

Esto sucede cada vez que se solicita algo nuevo, lo que garantiza que el módulo Relevance de BloomReach Experience actualizará constantemente la información que se conoce sobre el visitante.

La elección del contenido correcto para entregar se realiza en el back-end, por lo que el mapa que la API del modelo de página entrega a la SPA ya tiene personalización. Esto significa que no hay una herramienta de personalización Javascript inyectada por el CMS que “pelee” con tu SPA cuando se procesa la página. Además, puedes probar todas las variaciones diferentes, aprovechando la función Experiments.

Entonces, ¿Qué información podemos usar para personalizar dentro de una SPA? Literalmente, todo lo que podamos recopilar: Comportamiento del navegador, hora del día, día de la semana, información de nuestras otras herramientas (como plataformas de marketing o e-commerce). Una forma común de comenzar a usar Relevance (con o sin una SPA) es con las campañas de marketing. Si un cliente hace clic en un anuncio que versa "Cómo comenzar a ahorrar para la jubilación a los 20 años", su vista de la página de inicio mostrará información sobre, por ejemplo, la compra de su primera casa y otras formas de inversión más audaces. Si un cliente entra en una web a través de un anuncio que dice "Cómo empezar un fondo universitario para su hijo", le saldrá una página de inicio que tiene información sobre seguros de vida, consejos sobre presupuestos, inversiones de bajo riesgo…

En resumen, con el desacoplamiento central del contenido y la presentación, la configuración híbrida, las funciones de edición y la personalización del lado del servidor, los desarrolladores pueden usar SPA a nivel empresarial, los técnicos de marketing están satisfechos usando las SPA porque la edición funciona exactamente como están acostumbrados, y tus visitantes obtienen una experiencia increíblemente atractiva que se siente cohesiva en todo momento.

Un win win win.

Opciones para compartir

Francisco Javier López

Francisco Javier López es consultant en Incentro España

Póngase en contacto con Francisco.

siguiente story

Qué es una web SPA o single page applications

Álvaro Rojas | 11 de marzo de 2020