Headless CMS y JavaScript

¿Cuántas veces has escrito publicaciones o entradas para tu blog, o tal vez has compartido fotos y videos en redes sociales? Probablemente más de lo que puedes contar, ¿verdad? 

En cierto modo, todos somos creadores de contenido en la era digital. Pero, ¿alguna vez te has detenido a pensar cómo se maneja todo ese contenido? Aquí entran en juego los gestores de contenido.

¿ Qué es un CMS ?

Los Content Management System (Sistema de gestión de contenido, en adelante CMS), son aplicaciones, que de diversas formas nos permiten administrar contenido digital de manera colaborativa. 

Actualmente nos encontramos con, CMS Monolítico, el clásico Wordpress donde la interfaz y el propio gestor conviven. Es simple, lo configuras en tu máquina y funciona. Pero si tienes miles de usuarios o miles de plugins instalados, el rendimiento, la seguridad, las actualizaciones, las incompatibilidades, ya no tanto.

Además ¿recuerdas todas esas plantillas de PowerPoint, que eran “copia pega”, unas de otras? Pues en este tipo de productos sucede, que todo se acaba pareciendo, y mucho. 

Por otra parte podemos encontrar herramientas como Framer o Webflow, que son plataformas, no tan orientadas a gestionar el contenido, pero sí nos permiten crear páginas visuales, normalmente eficientes o al menos con un código muy decente.

Son muy intuitivos, al menos para los diseñadores, pero intenta poner a un equipo de marketing o de negocio a cambiar cambiar bloques como si de Figma se tratase. Por no hablar de que aunque ofrecen opciones de personalización en muchos casos son muy rudimentarias.

Por último, tenemos Headless CMS. Tienen muchas virtudes, pero no son para todos los públicos. En este insight hablaremos de, ¿por qué elegir un CMS “descabezado”?.

Headless

Antes de hablar de Headless, hablemos de arquitectura. El término JAMstack, aparece en 2016, donde el objetivo que persigue es construir la web, desacoplando la capa de la interfaz visual, de los datos y la lógica empresarial. 

JAMstack, Javascript, APIs y Markup, es un enfoque que separa el front-end del back-end de un sitio web, donde normalmente el front-end se prerenderiza, y el back-end puede reutilizarse en otros supuestos.

Y Headless CMS, como ya habrás intuido, es una herramienta que nos permite gestionar nuestro contenido, separándolo de un front-end. Este gestor nos proporciona una API que podremos consumir con cualquier cliente. Podemos usarlo dentro de una arquitectura JAMstack pero no es exclusivo de esta.

Separar la interfaz de los datos puede resultar beneficioso en algunos proyectos. Supongamos que tenemos un ecommerce que necesita actualizarse en diferentes sitios web y mercados. No es necesario replicar este cambio manualmente si tenemos una fuente proveniente de un único almacén de datos.

Una cosa importante a tener en cuenta es que un proyecto no tiene por qué ser simplemente monolítico o headless. Puede tener una aplicación web con algunas partes headless o desacopladas y que sean monolíticas en su núcleo.

Es importante comprender las necesidades y condiciones del proyecto específico y determinar si esta es una buena oportunidad para separar el front-end y el back-end.

¿ Tiene sentido “perder la cabeza” ?

Pero eso no significa que los CMS headless sean para todos.

Para responder a esta pregunta, deberíamos intentar cubrir los siguientes puntos como partida.

• La información debería de distribuirse por diferentes canales y dispositivos, como por ejemplo sitios webs, aplicaciones móviles, correos electrónicos, etc.

• Para el proyecto es necesario, o aporta valor el utilizar experiencias de usuario diversas que conllevan diferentes tipos de interfaces o capas de presentación.

• El rendimiento es un aspecto clave que afecta al servicio del sitio web.

• Un sitio web en el que el marketing o editores no tengan muchas o complejas opciones para la modificación del diseño.

• Flexibilidad y escalabilidad porque se planea entregar contenido multiplataforma o se anticipa un crecimiento significativo.

Como casos de uso tendríamos, aplicaciones con contenido multilenguaje, el comercio electrónico, y plataformas e-learning donde existen toneladas de contenido y necesitamos escalabilidad, llegar al público final a través de diferentes medios y donde la información pueda ser creada una única vez.

Sitios orientados al marketing que cambian constantemente y de una forma muy rápida, donde se necesita crear y publicar de manera inmediata y autónoma y también para documentación técnica y no técnica.

Los blogs, newsletters, y sitios de noticias, donde los editores solo tengan que concentrarse en escribir. Portfolios que necesiten libertad creativa y no solo plantillas predefinidas. 

Aplicaciones móviles e IoT, ya que gracias a la API desacoplada podremos entregar el contenido dinámicamente a los usuarios.

¿Dónde sí es muy efectivo? 

Sin duda en mejorar aplicaciones heredadas, donde simplemente conectemos nuestra nueva API, permitiéndonos resolver problemas existentes a la vez que integramos gradualmente esta nueva configuración.

En los supuestos de rebranding, donde simplemente reescribimos la interfaz desde cero, o añadimos el framework de moda y ya está, nuestro sistema simplemente nos está esperando listo para acoplarse de nuevo.

Y por último desarrollos con presupuesto y/o deadlines ajustados donde no se requieren cambios en diseño.

Es muy probable que en los casos de uso anteriores hayas notado que los supuestos que se ejemplifican no son imposibles de lograr sin un Headless CMS, y si, es correcto. En desarrollo existen muchos caminos para lograr solucionar un problema, pero esta herramienta nos facilita estas tareas en los contextos donde se necesita.

Lo bueno y lo malo

Ya tienes una idea todo lo que nos aporta Headless y apuntando directamente a sus bondades, donde realmente brilla es en la la escalabilidad y flexibilidad, dónde podemos dirigirnos a multitud de canales.

También reluce su independencia, donde podemos elegir cualquier tecnología front-end y personalizar cualquier cosa. 

Y una mejor experiencia de desarrollo ya que la API nos permite integrar cualquier tecnología front-end, poniendo énfasis eso sí en el SEO, donde deberíamos ajustar el framework elegido.

Centralización de esfuerzos, donde el contenido se crea una única vez, lo que ahorra tiempo y simplifica el mantenimiento.

Despliegue más rápido, agilizando el proceso de desarrollo y la publicación. 

Pero si, hay peros. Requieren menos esfuerzo que sistemas de desarrollo personalizado pero aún así se necesita bastante. La curva de aprendizaje más alta, requiere mayor conocimiento técnico para su implementación y mantenimiento.

 No limitan la creatividad, pero un equipo de marketing no podrá añadir componentes o plugins de manera sencilla, existirá alguna dependencia en mayor o menor medida del equipo de desarrollo. Tampoco tendremos en muchas soluciones, previsualizaciones.

Se necesitarán desarrolladores capacitados por un lado para el desarrollo de la API, y por otro lado desarrollo e implantación para el resto de canales a donde se dirija el contenido. Recuerda, no hay un plugin para eso.

También se añade una mayor complejidad, la gestión de múltiples tecnologías puede incrementar la complejidad del proyecto.

Conclusiones

La utilización de esta tecnología puede ser una gran elección a la hora de entregar contenido y productos de forma rápida, la flexibilidad y el desacoplamiento que nos ofrece son sin duda la clave.

Es una tecnología que es idónea para todo tipo de empresas, desde pequeñas, startups o grandes corporaciones. Todas ellas deberían de contemplar tener Headless en su stack de adopción ya que en multitud de situaciones es como una navaja suiza.

Es vital diseñar una arquitectura sólida y adecuada a cada necesidad, porque nada es perfecto y si cometemos errores comprometeremos la escalabilidad futura y perderemos las bondades que nos ofrece esta herramienta.

El CMS headless ofrece un conjunto de ventajas significativas para equipos que buscan flexibilidad, escalabilidad y experiencias omnicanal. Sin embargo, es importante considerar las desventajas y evaluar si se cuenta con los recursos técnicos y la experiencia necesarios para su implementación exitosa. En caso de dudas, se recomienda consultar con expertos en la materia para tomar la mejor decisión para su proyecto.

Bibliografia

Catherine Dee - What is a headless website? | Algolia

For fast and secure sites | Jamstack

Going Headless: Use Cases And What It’s Good For — Smashing Magazine