Los CMS (Content Management System) son unos protagonistas esenciales en el desarrollo web desde hace ya años. Primero veremos las dificultades para dar el salto a otras formas de desarrollar, luego los destinos de ese cambio y acabaremos con sugerencias concretas (y probadas) para romper las cadenas.
Los CMS son fáciles de instalar.
Están pensados para que el usuario sea el rey.
Igual que el Lego o el Tente tienen cientos de piezas disponibles (plugins, plantillas, servicios) para ampliarlos con sencillez.
Vivieron su época de esplendor cuando todas las empresas y profesionales especializadas construían uno propio.
Incluso yo caí en la tentación (por supuesto fue un "proyecto inacabado").
Ahora que podemos desplegar en la nube cientos de instancias con un clic, que la infraestructura se crea en torno al código y que deseamos estar a la última, sufren de mucha competencia.
Vaya por delante que en ningún caso en este artículo trato de demonizar a ninguno de estos sistemas (WordPress, Drupal, Joomla y tantos otros) ni a los que trabajan con ellos, entre los que me encuentro.
Mi objetivo es ir más allá.
Quiero echar un vistazo a una situación muy común:
La dependencia tecnológica de equipos o freelances con respecto a determinados CMS o sistemas de alto nivel para mostrar que opciones tenemos para no perder el tren del desarrollo moderno.
¿Cuáles son las dificultades para dar el salto?
Pongamos primero los pies en la tierra.
Comodidad.
El equipo al completo conoce, lee y bucea en el CMS. Se siente tranquilo, tiene herramientas para generar casi cualquier solución. Ha ganado mucho tiempo por hacer el trabajo siempre con la misma base.
Los días malos, donde el sofá es una cama de espinas, son en los que hay que enfrentarse a actualizaciones de seguridad con código rojo.
O cuando se hace una update de un plugin que resulta que rompe y bloquea el acceso a la web (a veces sin darte cuenta). Imagínate que en un ecommerce no puedas comprar despues de actualizar.
Estas cosas, pasan.
Rigidez.
Los desarrolladores que resuelven los proyectos siempre con una sola herramienta suelen estar aislados del ecosistema de los web developers. Es como una "trinchera del framework".
La elasticidad para incorporar nuevos conocimientos y habilidades puede reducirse, porque el CMS te lo pondrá siempre mucho más sencillo que si lo construyes desde cero o con otra tecnología.
Es algo que he vivido en largas épocas profesionales
Abrirme a otras tecnologías fue muy enriquecedor a varios niveles, también para mi tarea vinculada a mi CMS de cabecera (Drupal).
Perspectiva.
Tiene mucho que ver con la filosofía de trabajo.
Al trabajar con un stack fijo no siempre se ven oportunidades que vayan más allá. Puede incluso que se pierdan oportunidades por querer forzar el uso de un CMS para resolver cualquier problema tecnológico.
De hecho es un síntoma de un antipatrón de arquitectura de software que se llama "Vendor Lock-In", aunque esté más asociado a sistemas propietarios y no tanto a los open source como WordPress y demás.
Tiempo y presupuesto.
Horas y "pasta". Sin duda la combinación de factores más importante de todas.
Si manejamos con soltura un sistema de alto nivel asociaremos el ahorro de tiempo y la ampliación del margen de beneficio a él.
Por supuesto también a las capacidades y habilidades del equipo o del freelance que está al cargo.
El miedo a que el incremento del coste del desarrollo aumente en exceso, paraliza.
Sesga la toma de decisiones, pero sólo un paso hacia adelante hará que el coste mañana no sea mayor aún que hoy.
Alejandro Magno dijo algo como esto:
La fortuna favorece a los audaces.
Sigue leyendo para descubrir que con algo de astucia, un buen plan y una pizca de buena suerte el objetivo no está tan lejano.
Las tres estaciones de destino
Ahora que ya tenemos claro cuáles son los obstáculos a vencer tal vez sería bueno saber hacia dónde vamos a caminar.
Hay tres estaciones donde el recorrido acaba cuando se parte desde un CMS monolítico hacia otra arquitectura.
Desacoplado o decoupled
El renderizado de las páginas generadas con un CMS es una responsabilidad del mismo stack que gestiona otras parcelas de la aplicación como la gestión de usuarios, la estructura de las entidades o la conexión a la capa de persistencia. Es un sistema monolítico y acoplado.
El desacoplamiento no tiene que ser tan complejo como el de los cohetes lunares.
Basta con utilizar un lenguaje de programación que nos va a proveer de una capa extra: JavaScript.
De esta manera, aunque el renderizado inicial de cada página del CMS siga estando acoplado, podemos valernos del JavaScript ejecutado en el cliente para añadir características puntuales.
La ventaja para los editores de contenido es que no pierden el control del Wysiwyg ni la posibilidad de previsualizar el contenido antes de publicarlo. Características esenciales en muchas plataformas basadas en gestor de contenidos.
Desde el propio CMS proveemos información hacia esa nueva capa usando un recurso que tienen prácticamente todos: las API Rest de acceso a datos desde el exterior.
Sitio estático o static site generator
Sigo pensando que el nombre otorgado a este tipo de stack es poco afortunado al traducirlo al castellano, ya que parece que recorta multitud de funcionalidades.
En cualquier caso el JAMStack ha ganado muchos enteros en los últimos años dado que simplifica el despliegue de cualquier web, es más sostenible y abarata los costes del hosting.
Se vuelve a las bases de la web (HTML, CSS y JavaScript) generando el sitio final antes de desplegarlo. Muy conocidos son sistemas como Gatsby, Hugo, Jekyll, Nuxt, Gridsome o tantos otros.
El gestor de contenidos en este punto se convierte en un proveedor de información.
A través de la API el generador de sitios estáticos de turno se conecta para extraer la información que necesita y se "pinta" en elementos estáticos.
Aquí también podemos optimizar la experiencia de usuario con lo que nos ofrece JavaScript: autenticación, comentarios, favoritos...
Headless
Dejar sin cabeza al CMS.
Algunos días apetece hacerlo, ¿verdad?
Es el destino más lejano y costoso de todos, pero también es la puerta más abierta hacia los nuevos flujos de desarrollo web de todas las planteadas.
La premisa es quedarse con lo más cómodo de un CMS (panel de administración, estructuras flexibles, control de usuarios) y deshacerse de una de las partes en la que son más difíciles de optimizar: el frontend.
Nuevamente aparece la extensión hacia el exterior del gestor convirtiéndose en un modelo API-First, donde por encima de todo está la calidad y estructura de la conexión del CMS hacia otros mundos.
Tanto en este caso como en el anterior el editor de contenidos ya pierde el poder de la previsualización. Es un factor clave para llegar sanos y salvos a este punto la comunicación entre equipos y las necesidades para esa parcela de los proyectos.
Mis sugerencias de este tipo de Headless CMS van desde los clásicos con su API hasta específicos como Directus, CosmicJS, Strapi y decenas más.
Estas son las diferencias entre el sistema desacoplado y headless, colocandose el sitio estático en una posición muy similar a la del headless.
Sugerencias prácticas para el desacoplamiento
Llegamos por fin a una colección de propuestas prácticas para echar a andar.
Algunas son ejemplos reales de procesos puestos en marcha y que terminaron en final feliz.
Más que una sugerencia es una obligación.
Antes de iniciar estos cambios la reflexión ante la propuesta de proyecto o una neuva feature debe ser optimista, sí, pero también realista.
Al menos por mi experiencia no suele ser habitual dar los primeros pasos en el inicio de un proyecto salvo por una excepción: que sirva a un sólo propósito.
Cuanto más específico sea el problema a resolver, más fácil será desacoplarse.
Pequeñas asincronías
Es más que probable que ya hayas dado este paso en algún proyecto basado en WordPress, PrestaShop o Magento.
Se trata de desacoplar características que resuelve el CMS pero que por la naturaleza del trabajo o por exigencias del guión hay que confiar en servicios externos.
Un ejemplo es la generación de miniaturas de imágenes. Algo que cualquier gestor de contenidos trae de serie podría resolverse de la mano de servicios como Cloudinary.
Otro muy típico es la captura de la información meteorológica desde una fuente de datos externa. Aquí ya damos los primeros pasos del desacoplamiento.
Integraciones sencillas con redes sociales, resueltas por el equipo de desarrollo y no en la instalación de plugins específicos son otro gran punto de partida.
Desacoplamiento veloz
Manejamos tal cantidad de datos que las tablas donde se muestran cada vez tienen más parámetros de orden y filtrado.
Sí, hay 100 plugins para resolverlo e incluso themes específicos.
De la mano de JavaScript y los frameworks modernos (Vue, React, Angular) tenemos ante nosotros la primera forma de desacoplar el monolito.
Con ellos es mucho más fácil generar esas tablas generadas a partir de una API. La capacidad de filtrado y velocidad de carga serán mayores que usando solo las herramientas del CMS.
Otra, que puede abrir la puerta a un sistema de cacheado de la página generada, es el desacoplamiento de los datos visibles del usuario con el mismo procedimiento anterior.
Cuando el usuario está autenticado en los CMS perdemos la sencillez de crear una caché que acelere la carga de la página. Y a veces solo tenemos como elemento diferenciador un widget en la cabecera de la página con los datos del usuario (el avatar, el nombre y el enlace a su perfil).
Extracción de entidad
Cuántas veces se soluciona la creación del blog de un ecommerce con una instalación del plugin de turno o un WordPress en un subdominio.
Muchas.
¿Y si le damos un pequeño empujón a nuestro stack resolviéndolo de otra forma?
Una gran opción puede ser el empleo de un generador de sitios estáticos. Claro, el gestor de contenidos aquí pierde toda la relevancia. Podría ser el lugar donde se edita el contenido, porque realmente es lo que si seguimos necesitando: el Wysiwyg.
La maquinaria tiene que ser fácil para el cliente, cuando edite el contenido la web debe actualizarse con un click. Para eso hay soluciones varias de pago como Contentful o libres como Netlify CMS.
Otro de los acordes que conseguiremos aprender será el del despliegue de estos contenidos en la nube.
Lo rico de la galleta Oreo
Los pasos anteriores van ganando intensidad, este es de los grandes.
Qué hace mucha gente para comerse una Oreo: Desmontarla para disfrutar el chocolate.
Quedarse con lo mejor.
Así que en un CMS lo más rico y cómodo que suele ser: la administración. Es donde está el core del negocio y la parte más complicada de desacoplar, en mi humilde experiencia.
El paso más radical es deshacerse del frontend generado por el CMS y convertirlo en un sistema que interaccione a través de la API en ambos sentidos.
Aquí sí se elevan los costes y los tiempos, sobre todo si es la primera vez que se hace.
Mi recomendación es plantearlo primero para una función específica que podamos separar:
- Compra de productos digitales en un sitio que no tenía ecommerce
- Formularios de campaña con alta carga de interactividad
- Sistemas que ya deben integrarse con API externa por requisitos técnicos...
Conclusión: Análisis honesto
Antes de iniciar estos cambios la reflexión ante la propuesta de proyecto o una nueva feature debe ser optimista, sí, pero también realista.
Al menos por mi experiencia no suele ser habitual dar los primeros pasos para finiquitar la dependencia en el inicio de un proyecto salvo por una excepción: que resuelva un solo propósito.
Cuanto más específico sea el problema a resolver, más fácil será desacoplarse.
Es un proceso siempre más largo de lo que estimas, pero se convierte en un estímulo perpetuo para ser mañana mejor developer que hoy.
Todos los que trabajamos vinculados a un CMS queremos ser buenos developers. En nuestra mano está ganar aún más calidad profesional y enriquecernos abriéndonos a otra forma de pensar y de desarrollar.
Esto es solo una invitación a hacerlo. 😉