Drupal headless vs decoupled: no son lo mismo
En resumen: Drupal headless vs decoupled no son lo mismo. Esta guía explica las diferencias reales con criterios de producción, basados en la experiencia con tres portales universitarios, para que elijas el enfoque correcto según el coste, el equipo y el SEO.
- Decoupled progresivo: Drupal renderiza la página + islas JavaScript interactivas
- Headless total: Drupal como API pura, frontend independiente en Next.js, Nuxt o Astro
- Comparativa: coste, complejidad operativa, SEO e independencia de equipos
Si buscas información sobre Drupal headless vs decoupled, encontrarás que la mayoría de artículos usa ambos términos como si fueran sinónimos. No lo son, y la diferencia no es semántica: determina cuánto va a costar tu proyecto, cómo se organizará tu equipo y qué problemas vas a heredar en producción.
He trabajado con Drupal en sus distintas modalidades, incluida una arquitectura headless completa sirviendo tres portales universitarios en producción. Esta guía es la explicación que me habría gustado leer antes de elegir: qué es realmente cada enfoque, qué implica y cuándo compensa cada uno.
El punto de partida: el monolito Drupal
Para entender la diferencia hay que partir del Drupal tradicional, el monolito acoplado: Drupal gestiona el contenido y lo renderiza. El editor crea un nodo, Drupal lo procesa a través de su sistema de plantillas Twig y entrega el HTML completo al navegador. Backend y frontend son la misma cosa.
Este enfoque funciona muy bien para una gran cantidad de proyectos: todo está integrado, el SEO sale de serie, la previsualización es nativa y un solo equipo controla todo el ciclo. No hay nada intrínsecamente malo en él.
Los límites aparecen cuando necesitas una experiencia de usuario tipo aplicación, equipos frontend y backend trabajando en paralelo, o servir el mismo contenido a varios canales (web, app móvil, quioscos). Ahí empieza el desacoplamiento, que tiene dos grados.
Qué es Drupal decoupled (progresivo)
Drupal decoupled, más correctamente llamado desacoplamiento progresivo, es el punto intermedio: Drupal sigue renderizando la página, pero cede zonas concretas a aplicaciones JavaScript.
La página la genera Drupal con su tema y sus bloques como siempre, pero dentro de ella hay “islas” interactivas: un buscador en React, un filtro de eventos en Vue, un comparador que consulta una API. Esas islas son pequeñas aplicaciones JavaScript incrustadas que consumen datos de Drupal vía JSON, mientras el resto de la página sigue siendo Drupal tradicional.
Las implicaciones son importantes:
- El SEO y la previsualización se conservan. El contenido principal sigue renderizándose en servidor por Drupal, como siempre.
- La complejidad crece poco. No necesitas montar un frontend independiente ni un pipeline de despliegue nuevo.
- Es incremental. Puedes desacoplar una sección concreta sin rehacer el sitio.
Es la opción sensata cuando el monolito te vale pero hay dos o tres puntos de la interfaz que piden una interactividad que Twig no da.
Qué es Drupal headless (desacoplamiento total)
Drupal headless es el desacoplamiento completo: Drupal deja de renderizar cualquier página visible para el usuario. Se convierte exclusivamente en un gestor de contenido y un motor de API —normalmente JSON:API o endpoints JSON a medida— y todo lo que ve el visitante lo construye una aplicación independiente, típicamente en Next.js, Nuxt o Astro.
En este modelo vives en dos mundos separados: repositorio de frontend y repositorio de backend, despliegues independientes, equipos que pueden trabajar en paralelo sin pisarse. Drupal pasa a ser “el CMS sin cabeza” (headless, literalmente, sin la parte visible).
Es la arquitectura que implementé para tres portales universitarios en producción, con Next.js renderizando en servidor y Express.js agregando datos de Drupal. Todo lo aprendido en ese proyecto —qué funcionó y qué errores cometimos— está en la guía de Drupal headless con Next.js.
Lo que hay que saber antes de dar el paso:
- Ganas rendimiento y escalabilidad del frontend, pero a costa de operar dos sistemas. La caché, además, hay que repensarla: pierdes la madurez de la caché de Drupal en la capa visible (tema del que hablo en la guía de cache bins en Drupal).
- El SEO deja de ser gratis. Depende enteramente de que el frontend renderice en servidor (SSR) o genere estáticos (SSG). Un headless renderizado solo en cliente es un problema de indexación.
- Pierdes comodidades del monolito: previsualización del editor, Layout Builder, administración de menús con reflejo directo en la web. Hay que reconstruirlas o asumir su pérdida.
Comparativa directa
| Monolito | Decoupled progresivo | Headless | |
|---|---|---|---|
| Quién renderiza | Drupal | Drupal + islas JS | El frontend (Next.js, etc.) |
| SEO inicial | Nativo | Nativo | Depende del SSR/SSG |
| Complejidad operativa | Baja | Media-baja | Alta (dos sistemas) |
| Independencia de equipos | Nula | Parcial | Total |
| Multicanal (app, quiosco) | No | Difícil | Natural |
| Previsualización editor | Nativa | Nativa | Hay que construirla |
| Coste inicial | Bajo | Medio | Alto |
Cuándo elegir cada enfoque
Mi criterio después de ver las tres modalidades en producción:
- Monolito: blogs y sitios corporativos, equipos pequeños, plazos ajustados o presupuesto limitado. Si no tienes una razón clara para desacoplar, no desacoples.
- Decoupled progresivo: el sitio funciona bien en Drupal pero necesitas puntos concretos de alta interactividad (buscadores complejos, configuradores, dashboards) sin pagar el coste de un frontend completo.
- Headless: portales de alto tráfico, equipos frontend y backend diferenciados, necesidad multicanal o requisitos de rendimiento que el renderizado de Drupal no alcanza. Fue nuestro caso con los portales universitarios: miles de usuarios simultáneos, contenido agregado de múltiples fuentes y equipos separados por especialidad. Sin esas condiciones, no lo habría justificado.
La regla práctica: desacopla lo mínimo que resuelva tu problema. El headless total es la opción más potente y también la más cara de mantener; el decoupled progresivo cubre la mayoría de necesidades reales a una fracción del coste.
Conclusión
Drupal headless vs decoupled no es una elección de moda sino de grado: el decoupled progresivo mantiene a Drupal al mando de la página con islas JavaScript, mientras que el headless lo convierte en una API pura al servicio de un frontend independiente. El primero es incremental y barato de adoptar; el segundo es una apuesta de arquitectura que solo se justifica con requisitos que el monolito no puede cumplir.
Si te has decidido por el headless total, el siguiente paso es ver cómo se monta de verdad: en la guía de Drupal headless con Next.js detallo la arquitectura completa que llevé a producción, con sus aciertos y sus errores. Y si quieres explorar más contenido técnico, todo lo que publico sobre el CMS está en el hub de Drupal.
Preguntas frecuentes
¿Cuál es la diferencia entre Drupal headless y decoupled?
Drupal decoupled (desacoplamiento progresivo) mantiene a Drupal renderizando la página pero cede zonas concretas a aplicaciones JavaScript incrustadas, como un buscador o un filtro en React. Drupal headless (desacoplamiento total) convierte a Drupal en una API pura que no renderiza nada visible: todo lo construye un frontend independiente, normalmente Next.js, Nuxt o Astro. No son sinónimos y la diferencia afecta al coste, al equipo y al SEO.
¿Qué es Drupal decoupled o desacoplamiento progresivo?
Es el punto intermedio: Drupal sigue generando la página con su tema y sus bloques, pero dentro de ella hay islas interactivas (React, Vue) que consumen datos vía JSON. El SEO y la previsualización se conservan porque el contenido principal se renderiza en servidor, la complejidad crece poco y puedes desacoplar secciones de forma incremental sin rehacer el sitio. Es la opción sensata cuando el monolito vale pero faltan puntos de interactividad.
¿Qué es Drupal headless o desacoplamiento total?
Es el modelo en el que Drupal deja de renderizar cualquier página visible y actúa solo como gestor de contenido y motor de API, normalmente con JSON:API o endpoints a medida. Todo lo que ve el visitante lo construye una aplicación independiente con Next.js, Nuxt o Astro. Vives en dos mundos separados: repositorios y despliegues independientes, y equipos que trabajan en paralelo. Es la arquitectura que se usó para tres portales universitarios en producción.
¿Cuándo elegir Drupal headless en lugar de decoupled?
Elige headless para portales de alto tráfico, equipos frontend y backend diferenciados, necesidades multicanal (web, app, quioscos) o requisitos de rendimiento que el renderizado de Drupal no alcanza. Elige decoupled progresivo cuando el sitio funciona bien en Drupal pero necesitas puntos concretos de alta interactividad sin pagar el coste de un frontend completo. La regla práctica: desacopla lo mínimo que resuelva tu problema.
¿El SEO se pierde en una arquitectura Drupal headless?
No necesariamente, pero deja de ser gratuito. En un headless el SEO depende de que el frontend renderice en servidor (SSR) o genere estáticos (SSG). Un headless renderizado solo en cliente es un problema de indexación porque los buscadores no ejecutan JavaScript. También pierdes la previsualización del editor, Layout Builder y la administración de menús con reflejo directo, que hay que reconstruir o asumir su pérdida.