Drupal con arquitectura desacoplada

Dentro de la serie de artículos divulgativos en torno a Drupal a publicar en OpenWebinars, iba tocando uno acerca de las posibilidades reales de uso de este popular CMS en la actualidad. Para actualizar un poco la visión que podamos tener y por poner el foco en ciertas propuestas que sin ser específicamente “modernas” (Drupal headless es un enfoque que empezó a modelarse hace ya algunos años) si es cierto que puede aportar un poco de luz a la hora de adoptar nuestro CMS favorito como base tecnológica para un proyecto e incluso facilitarlo si el know-how del equipo está en otra dirección. Como propuesta integradora, tal vez no sea mala idea pensar en Drupal para construir ese sistema que tienes en mente. ¿Tienes personas expertas en PHP-Drupal-Symfony en tu equipo? ¿no? Veamos si pueden construirse alternativas que faciliten las cosas. Hasta ahora habíamos pensado en CMS’s como Drupal o Wordpress como en un todo del que había que asumir un expertise completo en backend y frontend a la hora de construir un proyecto pero ¿Y si pudiésemos reducir el alcance? Aquí aparece la estrategia Headless o “Drupal desacoplado”.

Imagínate que no quieres correr riesgos en tu proyecto y prefieres estabilizar el CMS como “motor de contenidos”, enfocándolo a un uso parcial como backend y base de datos mientras apuestas por una estrategia de implementación de un front-end separado, que te sea relativamente sencillo de modificar para realizar cambios y “modernizándolo” (manteniendolo actualizado) en función de los cambios de tendencia en cuanto a diseño y experiencia de usuario. Algo parecido a realizar modificaciones sobre la interfaz que ven los usuarios y visitantes del sitio web sin que haya que preocuparse del sistema que está detrás gestionando contenidos. Con Drupal es posible: es el llamado enfoque Headless, literalmente “descabezado” o para ser más exactos “Desacoplado”.

Este enfoque ha ido ganando sitio en los últimos tiempos y ha demostrado ser más que una apuesta segura - por si piensas que es novedoso o no está solidamente testado-. De hecho apareció hace unos tres años a partir de un breve manifiesto que planteaba las siguientes cuestiones a afrontar:

We want Drupal to be the preferred back-end content management system for designers and front-end developers.
We believe that Drupal’s main strengths lie in the power and flexibility of its back-end; its primary value to users is its ability to architect and display complex content models.
We believe that client-side front-end frameworks are the future of the web.
It is critically important for Drupal to be services oriented first, not HTML oriented first, or risk becoming irrelevant.

Que traducido y de forma resumida, plantea algo como:

“Creemos que las principales fortalezas de Drupal residen en su fuerza y flexibilidad en su backend. Creemos también que los frameworks para front-end son el futuro de la web. Es muy importante que Drupal se oriente primero a servicios, no a HTML.”

Un enfoque que ha ido ganando peso progresivamente

¿Por qué?

1- Integra a Drupal en el futuro del desarrollo web: Drupal era un CMS muy monolítico y esta visión permite tratarlo como un elemento “parcial” dentro de un proyecto, introduciendo la plataforma dentro de las tendencias a nivel de desarrollo de front-end sin tener que renunciar explícitamente a sus potencialidades a nivel de backend.

[BANNER_SUSCRIPCION]

2- Crea dos mundos diferenciados y permite la persistencia: ya no es obligatorio refactorizar un sitio web completo o pensar en tener que reimplementarlo por completo a partir de cambios en la interfaz del visitante, lo que permitía un punto de fuga tecnológico que afectaba, entre otras cosas, a su propia cuota de mercado: dejar atrás Drupal en aras de otra tecnología u otro CMS en cuanto se avecinaba un gran cambio a realizar si dicha plataforma facilitaba mejor las nuevas funcionalidades. Muchos proyectos que debían representar solo un evolutivo al final terminaban siendo una verdadera migración y las compañías dejaban atrás Drupal. Con este enfoque Drupal permanece en los sistemas como herramienta de gestión de contenidos a nivel editorial, administrativo y sistémico.

3- Todos y todas ganamos en flexibilidad: liberamos a los expertos en front-end de tener que trabajar con las pautas y directrices propias del back-end, facilitamos el absoluto control sobre la experiencia de usuarios para ellos. ¿Un front-end basado en un framework javascript popular? Angular, Node, Backbone, Ember…todo es posible. Que la plataforma web se centre solo en servir contenidos y sin preocuparse de formateados ni adaptaciones puede hacer optimizar los tiempos y velocidades y volverlo todo mucho más ágil. ¡Flexibilidad en todas partes!

4- Content As A Service (CaaS): Enfoque bastante interesante que apareció hace unos años y ya está totalmente instalado. En realidad ¿De quien es el contenido? ¿Quién lo crea? ¿Los administradores de tu propia plataforma? ¿Vienen recopilados de sindicaciones externas? ¿Son proveídos por terceros? es más ¿A dónde van? ¿Diferentes plataformas como clientes? ¿Aplicación móvil? piensa en un sistema central que reune, recopila, ordena y prepara contenidos de diferentes orígenes y también diferentes destinos. Pon en uso la API Restful y chuta contenidos en diferentes formatos en todas las direcciones necesarias…json, xml o hal_json (con módulo ad-hoc). Aquí puedes consultar todo lo referente a la API RESTful de Drupal 8.

5- En definitiva, lanzar Drupal hacía el futuro: a modo de resumen de las cuestiones anteriores, se trabaja ya con una visión de aprovechamiento de las fortalezas de la plataforma y se integran las fortalezas de otros enfoques, frameworks y procesos de negocio para conseguir que Drupal tenga un futuro y se vincule a los avances que se han producido estos últimos años.

Conceptos

Hay una tríada de conceptos que conviene tener claro a la hora de decidirse por este enfoque, para saber al menos el alcance conceptual que implica y el rumbo que va a tomar el proyecto si nos decidimos proponer algo así. Repasemos los tres elementos fundamentales del enfoque.

1- Frontend desacoplado

La presentación puede ser construida de muchas maneras diferentes. Con un frontend dinámico basado en tecnología js, un sistema generador estático, una aplicación móvil o incluso ¡otro CMS!. Piénsalo, puedes tener un CMS como Drupal detrás y delante otro diferente con el que conviva en paz y amor.
Las posibilidades se abren.

2- Contenido vía servicios web

El contenido estará disponible a través de web services tipo Rest y generalmente formateados como JSON. Y a lanzar entidades.

3- Backend CMS

Un sistema gestor de contenidos “clásico” (entre comillas, también evoluciona y mejora). Con la interfaz de administración habitual. Con las funcionalidades necesarias para crear usuarios, otorgar permisos y definir, jerarquizar, categorizar y agrupar contenidos, como siempre.

Estrategias posibles

Como es lógico, a partir de la combinatoria de las posibilidades presentadas se establecen diferentes marcos para construir plataformas, diferentes enfoques que están articulados para ser seleccionados por su mayor predisposición a cumplir con los requisitos y fines del proyecto que tengas entre manos. Recopila toda la información posible, unifica y decídete por una visión al respecto para tu proyecto:

1- Una visión CMS doble

Desacopla un CMS con otro CMS para su frontend. Imagínate que tienes expertos en una tecnología específica y no quieres pasar un proceso de cambio a un frontend específico. ¿Un Drupal en backend y un Wordpress en front-end? ¡es posible! (y cada cual con sus parafilias, claro).

2- Una visión estática

Que la interfaz se construya a través de un generador un poco “dry”, en modo estático. Imagínate que renderizas frontend desde un generador como el de Github.io y a través de llamadas API vía js traes el contenido.

3- Una visión híbrida

Que solo una parte del sitio web sea dinámica e interactiva y que desde esa parte se hagan las peticiones necesarias para esas zonas de contenidos.

4- Una visión native-app

El frontend es en sí mismo una aplicación mobile para usuarios.

5- Una visión single-page

Lanzar aplicaciones vía navegador que van construidas con Angular, Backbone o cualquier otra modernez.

¿Te apetece probar? instálate un Drupal 8, crea un tipo de contenido elemental de dos campos (título y descripción, por ejemplo), dale a la opción “Extender”, Web Services y configura la vista de web services para realizar peticiones a este tipo de contenidos.