¿Tiene sentido “perder la cabeza” con los CMS?

DevOpsProyectosSoftware
Aníbal Santos Gómez, Senior Tech Engineer de innusual

Aníbal Santos Gómez, Senior Tech Engineer de innusual, analiza en esta tribuna las ventajas e invoncenientes en el uso de los CMS “Headless”, así como los escenarios donde tiene sentido aplicarlos.

Seguro que conoces o has trabajado con algún Content Management System (Sistema de gestión de contenido, en adelante CMS), un tipo de aplicacion que nos permite administrar contenido digital de manera colaborativa.

Pero, has oído hablar de los Headless CMS? Estos CMS tienen muchas virtudes, pero no son para todos los públicos. En este artículo hablaremos de, por qué elegir un CMS “descabezado”.

Antes de hablar de Headless, hablemos de arquitectura. El término JAMstack aparece en 2016 con el objetivo de construir webs 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 escenarios.

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.

Un aspecto previo 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 fundamental 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”?

Para responder a esta pregunta, deberíamos intentar cubrir las siguientes premisas:

  • 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.

Bajo estas premisas podemos identificar diferentes casos de uso:

    • Aplicaciones con contenido multilenguaje, el comercio electrónico, y las plataformas e-learning donde existen grandes volúmenes 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 web 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.

También podemos identificar requisitos no funcionales en los que seguirá muy efectivo emplear un headless CMS:

  • En la mejora de 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, 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 sí, 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 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 como con cualquier tecnología, también tiene sus peros. Requieren menos esfuerzo que sistemas de desarrollo personalizado pero aún queda lejos de tender a mínimos . La curva de aprendizaje es 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 IT. 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.

Autor

Últimos Whitepapers