Arquitectura de referencia para gestores de contenido

Información general

Icono arquitecturas de referencia
Tipo de recurso
Arquitectura de referencia
Etiquetas

Objetivos, características y beneficios

La arquitectura de referencia de gestores de contenido (CMS) define un enfoque estándar para implementar soluciones de gestión y difusión de información dirigidas a ciudadanía, personal interno o colectivos específicos en los Organismos de la Junta de Andalucía.
Esta arquitectura proporciona una base alineada con los principios y el diseño establecidos, facilitando entornos de trabajo organizados, escalables y mantenibles para la creación, publicación y reutilización de contenido a lo largo del tiempo.

Objetivos

  • Gestión eficiente de contenido: facilitar la creación, edición, publicación y organización del contenido para usuarios no técnicos.
  • Escalabilidad: permiten el crecimiento del sistema y la extensión de las funcionalidades mediante módulos, plugins e integraciones.
  • Interoperabilidad y multicanalidad: facilitan la integración con otros sistemas (ERP, CRM, buscadores, …) y la difusión del contenido en múltiples canales mediante un sistema de APIs.
  • Experiencia de usuario optimizada: ofrecen interfaces rápidas, accesibles y adaptables a distintos dispositivos.
  • Mantenibilidad y extensibilidad: facilitan la evolución del sistema con un coste técnico contenido.             

Características  

  • API-first: (REST/JSON:API) para asegurar el acceso a los datos siguiendo estándares comunes de intercambio de información.
  • Usabilidad: se ofrece una experiencia de usuario común y compartida acorde con las buenas prácticas definidas por la Agencia.
  • Reutilización: el uso de soluciones y componentes reutilizables, simplifican y agilizan el desarrollo de nuevos productos fomentando la reutilización y la optimización de recursos a emplear.
  • Escalabilidad y seguridad: gracias a la infraestructura sobre la que se construyen los portales se pueden ajustar los recursos según demanda y proporcionar un nivel de seguridad mayor ante posibles comportamientos maliciosos.
  • Independencia: si bien cada nuevo gestor de contenido parte de un catálogo común de funcionalidades y módulos, cada nueva instancia es una instancia independiente del resto y puede seguir su propio ciclo de vida.
  • Gobierno del dato: la instalación de un nuevo gestor de contenido trae la definición de una serie de tipos de contenidos, funcionalidades y estructuras comunes definidas por la Agencia. De esta manera, la información que se publique siempre será conforme a los estándares definidos. 

Beneficios

  • Velocidad de desarrollo:  un gestor de contenido permite crear un portal web de forma rápida gracias a sus funcionalidades integradas. Desde el punto de vista técnico, ofrece módulos y plugins que amplían fácilmente sus capacidades. En cuanto a la gestión de contenido, proporciona una interfaz sencilla pensada para usuarios no técnicos, facilitando la creación y organización de contenidos
  • Mejor rendimiento: se ofrecen herramientas y configuraciones de sistema que garantizan el mejor rendimiento posible.
  • Omnicanalidad: todo el contenido generado se gestiona en el CMS y, gracias a sus funcionalidades nativas, se puede servir el mismo a través de servicios APIs para que pueda ser consumido en distintas plataformas de front-end (web, móvil, apps, kioskos, etc.).
  • Personalización: si bien la base de partida es una solución preconfigurada, se deja abierta la posibilidad a los equipos de desarrollo para introducir nuevas funcionalidades, proponer mejoras a las existentes y crear soluciones específicas para el proyecto.
  • Orientado a estándares abiertos: al usarse estándares abiertos se garantiza la compatibilidad con otros sistemas y se minimizan posibles costes de cambio de tecnología. 
    Al tratarse principalmente de productos de software libre, que usan estándares abiertos y código fuente accesible, se reduce el impacto de un posible cambio de tecnología. Y, en el caso de elegir una arquitectura desacoplada se mejora aun este aspecto, facilitando la integración o el cambio hacia otra solución. 

Principios

Partiendo con la premisa de que se deben seguir todos los principios generales definidos en la arquitectura global de contexto y que aplican al desarrollo de gestores de contenido, se añaden algunos específicos para los gestores de contenido:

  • Orientado al contenido
  • Mínimo privilegio
  • Estandarizar el uso de taxonomías y tipos de contenido 

Orientado al contenido

Cada producto digital que haga uso de un gestor de contenido debe estar enfocado en ofrecer el contenido como un servicio. De esta manera, componentes de terceros pueden acceder a la información y explotarla mediante servicios específicos con total independencia de la plataforma de gestión.

De la misma manera se definen tipos de contenido estándar, que estarán disponibles en cada nueva instancia del gestor de contenido. Estos se podrán extender, modificar o añadir nuevos tipos según la necesidad del producto a desarrollar. 

Mínimo privilegio 

Se aplica a la gestión de usuarios y permisos, asignando solo los permisos estrictamente necesarios a cada rol que se defina. De esta manera se asegura que cada usuario, dependiendo del rol asignado, tendrá solamente los permisos necesarios para desempeñar sus tareas.

De este modo se reduce el riesgo de errores o accesos indebidos, se mejora la seguridad del sistema y se facilita la administración del portal 

Estandarizar el uso de taxonomías y tipos de contenido

Se trata de un principio fundamental para cualquier gestor de contenido, permite clasificar y estructurar el contenido según criterios lógicos mediante categorías. De esta manera se facilita la navegación y búsqueda, se permite la creación de vistas de contenidos dinámicas, mejora la experiencia del usuario y la gestión editorial. 

Componentes

Dentro de la arquitectura de gestión de contenidos es posible implementar las aplicaciones o portales de distintas maneras, dependiendo de los requerimientos funcionales y técnicos y las necesidades de la organización. Actualmente se ofrecen tres alternativas:

  • Arquitectura acoplada: el gestor de contenido se encarga tanto de la capa de presentación y de la capa de gestión y creación de contenidos (backend).
  • Arquitectura desacoplada: el gestor de contenido se encarga principalmente de la capa de gestión, creación e indexación de los contenidos. La capa de presentación se materializa utilizando el resto de las arquitecturas de referencia (SPA o microfrontends), comunicándose a través de APIs publicadas y gobernadas dentro de la arquitectura de APIs.
  • Arquitectura híbrida: el gestor de contenido sirve tanto para la creación y organización del contenido como de su presentación a los usuarios finales, sin embargo, se apoya a un sistema de APIs adicional para poder acceder a más información y ofrecer datos más completos y puede incluir componentes frontend que presentan información procedente de la API

A continuación, se muestra el diagrama de componentes identificados para una arquitectura orientada a gestores de contenido:

En las tres alternativas anteriores, para poder tener una arquitectura completa y funcional, serán necesarios los siguientes componentes:

Sistema de gestión de contenido (CMS)

Se trata del propio gestor de contenidos, incluyendo la lógica de negocio relacionada con los contenidos y sus tipos, la creación y edición, la gestión de usuarios, permisos de acceso, grupos, taxonomías, etc.

Proxy inverso

Permite el enrutado del tráfico hacia los diferentes componentes (servicios de presentación) que conforman la capa frontend. Además sirve para mejorar el rendimiento del sistema, distribuyendo la carga y protegiendo al backend. Puede incluir cacheo de contenido estático y protección contra DDoS.

Base de datos

El núcleo de persistencia del CMS, se encarga de almacenar contenido estructurado, datos, configuraciones, información de usuarios y textos.

Caché

Componente para la mejora del rendimiento del sistema, acelera el acceso a los datos usados con más frecuencia, es ideal para mantener sesiones, el uso de tokens y la reutilización de fragmentos de contenido.

Motor de búsqueda e indexación

Componente para mejorar el acceso a la información que se genera en el CMS y facilitar la búsqueda. En una arquitectura acoplada no es un componente indispensable, sin embargo, en los modelos desacoplado e hibrido es fundamental que toda la información se indexe para que luego sea explotada por la capa de presentación.

Servicios de presentación (SPA o Microfrontends)

Componente para la implementación de aplicaciones, portales o secciones que renderizarán todo o parte de un portal o aplicación basado en gestión de contenidos. Obligatorio en una solución desacoplada, opcional en una solución hibrida, podrán ser microfrontends o single page application.

Servicios de backend (Microservicios o funciones) para acceso a la información

Permiten el acceso a la información generada por el CMS e indexada, o a información externa. Opcional tenerlos en el ámbito de una solución totalmente desacoplada y se puede usar también en una solución hibrida para acceder a información que no está guardada en la base de datos del gestor de contenidos. 

Patrones de arquitectura y diseño

Un gestor de contenidos presenta una serie de patrones específicos que guían el diseño y el desarrollo. Seguir esos patrones es fundamental para poder construir productos digitales estables, resilientes, mantenibles y escalables, en definitiva, siguiendo los patrones de desarrollo y diseño se garantiza la implementación de gestores de contenido de calidad. 

Materialized view

Consiste en crear y mantener una vista pre-calculada de datos persistentes que se actualiza de manera automática cada vez que estos cambien. El objetivo es reducir la latencia en lectura y mejorar el rendimiento general de un sistema con alto volumen de consultas.

Las ventajas que conlleva están principalmente en tiempos rápidos de consulta, escalabilidad en fase de lectura y presentación y una menor carga en la base de datos principal.

Por el otro lado añade complejidad a nivel de sincronización y aumenta el riesgo de presentar datos obsoletos si la actualización falla.

En la arquitectura de CMS, este patrón aplica a la capa de interoperabilidad, que se encarga de APIficar los datos y ofrecerlos para el consumo y a la capa del propio CMS, que actúa como un productor y gestor de datos.  

Principios que aplican:

  • Desacoplamiento de components.
  • Escalabilidad bajo demanda.
  • Calidad del dato.

Plugins

Es un patrón que permite extender las funcionalidades del producto mediante módulos o plugin adicionales que se integran dinámicamente.  

Este patrón aplica en la arquitectura aquí descrita en el propio CMS, ya que el paradigma principal para el desarrollo de nuevas funcionalidades se basa en la implementación de las mismas en plugins (módulos) separados, cada uno dedicado a ofrecer una funcionalidad.

Principios que aplican:

  • Desacoplamiento de componentes.
  • Design driven development.
  • Escalabilidad bajo demanda.
  • Software libre / Open Source.

API Gateway

Es un punto de entrada único para las solicitudes dirigidas a los servicios de backend. Gestiona el enrutamiento, autenticación, control de tráfico y agregación de las respuestas.

En el ámbito de un CMS permite centralizar el acceso a las APIs de contenido para mejorar la seguridad y simplificando el front-end.

Principios que aplican:

  • Fuente única de la verdad.
  • API First & Open API.
  • Zero Trust. 

Pila tecnológica

 

ComponenteSoluciónDescripción
Sistema Gestor de contenido 

Drupal

Wordpress 

Gestión de contenidos, usuarios, roles, tipos de contenidos, vocabularios, etc. 
Base de datos 

MySQL

MariaDB 

Sirve para almacenar toda la información y todas las configuraciones del gestor de contenido. 
Caché Redis Caché para la mejora del rendimiento y el acceso a los datos usados con más frecuencia. 
Proxy inverso + Cache Web Varnish Componente para la mejora del rendimiento del gestor y protección contra DDoS, además de incorporar caché web. 
Motor de búsqueda e indexación 

Elasticsearch 

Punto central de indexación y relevancia de los resultados de búsqueda de contenidos. 

El resto de los componentes que se visualizan en el diagrama (Microfrontend, SPA, Funciones, Microservicios, APIs, Servicios de Interoperabilidad) están englobados en otras arquitecturas de referencia que complementan a la arquitectura de referencia de Gestión de Contenidos, y estarán descritos en su correspondiente apartado. 

Escenarios de aplicación

A continuación, se van a mostrar y describir una serie de posibles aplicaciones de uso de un gestor de contenido.

Desarrollo de un portal web o una intranet para un Organismo

  • Escenario

Un organismo de la Junta de Andalucía solicita el desarrollo de un nuevo portal web como punto de acceso de información de carácter permanente dirigido a la ciudadanía o a colectivos específicos, permitiendo el envío de peticiones a través de formularios, la consulta en buscadores de información, o la integración de otros servicios digitales.

  • Descripción

Se instala una nueva instancia del arquetipo de gestor de contenidos Drupal en su última versión disponible al momento de la solicitud. Tras la instalación, el arquetipo ofrece una serie de tipos de contenidos por defecto, un tema gráfico de administración común y un sistema de permisos y flujo editorial aprobado que sirve para igualar la experiencia de uso para todos los empleados de los Organismos de la Junta de Andalucía.

La instalación, despliegue y asignación de recursos iniciales seguirá las normas e indicaciones definidas asegurando conformidad con los estándares.  

En el caso de ser necesario algún desarrollo de nuevas funcionalidades específicas, el equipo encargado se ocupará de definir los requisitos, comprobar que ninguna de las funcionalidades disponibles en el catálogo cubra las necesidades y procederá al desarrollo.

En el caso que exista una funcionalidad que cubra parte de los requisitos, el equipo de desarrollo, junto con el equipo de la Oficina técnica, tomarán la decisión de extender la funcionalidad disponible o adaptar los requisitos a la funcionalidad existente.

Como alternativa, podrá valorarse la adopción de una solución desacoplada, en la que el gestor de contenidos se utilice exclusivamente para la creación, edición, organización y almacenamiento de la información, mientras que la capa de presentación se delegue en un framework de frontend. Para ello, será necesario indexar la información que vaya a mostrarse y desarrollar los servicios necesarios que permitan a la capa de frontend acceder a dichos contenidos y presentarlos adecuadamente.

Desarrollo de un micrositio para un evento

  • Escenario

Un organismo de la Junta de Andalucía solicita el desarrollo de un portal web pequeño para la promoción de un evento durante un tiempo determinado. El portal contará con un máximo de 20 páginas de consulta, incorporará algunos videos y galerías de imágenes y un formulario de contacto para solicitar información sobre el evento.

  • Descripción

Se instalará una nueva instancia del arquetipo Wordpress para micrositios en su última versión disponible al momento de la solicitud. Se informará a los responsables del Organismo de las funcionalidades incluidas en la instalación, que podrán serán suficientes para cubrir los requisitos descritos, o extenderse mediante la instalación de plugins adicionales.

La instalación, despliegue y asignación de recursos iniciales seguirán las normas e indicaciones definidas, asegurando la conformidad con los estándares y la mantenibilidad futura.

En este caso no se contempla el desarrollo de nuevas funcionalidades específicas, siendo el nivel de personalización más limitado. Esto se debe a que la naturaleza del arquetipo Wordpress para micrositios está en ofrecer un producto pequeño y rápido de instalar y desplegar para gestores de contenidos simples y pensado para portales que tienen una vida relativamente corta. 

Referencias

Referencias técnicas: