Drupal headless: cuándo tiene sentido desacoplar el frontend

La arquitectura headless o decoupled — donde Drupal actúa como backend de contenido y un framework JavaScript (React, Next.js, Vue, Nuxt) renderiza el frontend — es una tendencia que ha ganado mucha tracción en los últimos años. Pero no es la solución correcta para todos los proyectos. Antes de adoptar este enfoque, conviene entender qué ganas, qué pierdes y cuándo está justificado el esfuerzo adicional.

En Keliam hemos implementado tanto proyectos Drupal tradicionales como arquitecturas headless para clientes con requisitos específicos de rendimiento, experiencia de usuario o integración con aplicaciones móviles, siempre desde nuestro servicio de desarrollo Drupal.

Fully decoupled vs progressively decoupled

Existen dos variantes de la arquitectura desacoplada. En el modelo fully decoupled, Drupal solo sirve contenido a través de JSON:API o GraphQL y el frontend es una aplicación completamente independiente. No se usa el sistema de temas de Drupal ni ninguna renderización del lado del servidor de Drupal.

En el modelo progressively decoupled, Drupal sigue renderizando la estructura base de la página pero ciertos componentes interactivos se implementan con frameworks JavaScript que consumen datos de la API. Este enfoque es menos disruptivo y permite aprovechar las herramientas de gestión de layout y previsualización de Drupal.

JSON:API vs GraphQL: qué API elegir

Drupal soporta ambas opciones. JSON:API viene incluido en el core desde Drupal 9 y expone automáticamente todas las entidades con filtrado, paginación, inclusión de relaciones y sparse fieldsets. Es la opción más directa y con mejor soporte oficial.

GraphQL requiere el módulo contribuido GraphQL (versión 4), pero ofrece la ventaja de que el frontend define exactamente qué datos necesita en cada query, reduciendo el over-fetching. Para frontends con muchas vistas diferentes que necesitan combinaciones específicas de datos, GraphQL puede resultar más eficiente en términos de transferencia de datos.

Retos del headless: lo que nadie te cuenta

La arquitectura headless introduce complejidades que en Drupal monolítico vienen resueltas de serie. La previsualización de contenido antes de publicar requiere configuración adicional (o herramientas como Gatsby Preview, Next.js Draft Mode). El sistema de permisos y acceso a contenido necesita replicarse en la capa API. Los formularios deben gestionarse mediante llamadas API en lugar del sistema de formularios de Drupal. Y el SEO — meta tags, sitemaps, redirects — hay que implementarlo en el frontend.

El coste de desarrollo y mantenimiento de un proyecto headless es significativamente mayor: necesitas dos equipos (o un equipo con doble competencia) para mantener backend y frontend, y cada cambio en la estructura de contenido puede requerir ajustes en ambos lados.

Cuándo sí y cuándo no

El headless tiene sentido cuando: necesitas servir el mismo contenido en web, app nativa y otros canales; el frontend requiere interactividad compleja tipo SPA que Drupal no puede ofrecer nativamente; o tienes requisitos de rendimiento extremos donde un frontend estático (SSG) o edge-rendered ofrece ventajas claras.

No tiene sentido cuando: el sitio es principalmente informativo con interactividad limitada; el equipo no tiene experiencia con frameworks JS modernos; o el presupuesto y el timeline no permiten el esfuerzo adicional de mantener dos stacks. Si estás evaluando si el headless es adecuado para tu proyecto, podemos ayudarte a tomar la decisión con un análisis objetivo de tu caso.