Índice de contenidos
- ¿Qué es Headless WordPress?
- ¿Cómo funciona la arquitectura Headless?
- ¿Por qué usar una arquitectura Headless?
- Conclusión
¿Qué es Headless WordPress?
Literalmente la palabra headless significa «sin cabeza», pero en el contexto del desarrollo web significa una separación entre el gestor de contenidos (CMS) y la capa de presentación, es decir, en este caso WordPress sería utilizado únicamente para gestionar el contenido sin tener ningún tema instalado.
Por otro lado tendríamos el front-end (la capa de presentación), una aplicación (una web, aplicación móvil…) separada del back-end que se comunica a través de una API para obtener el contenido y posteriormente presentarlo al usuario final.
¿Cómo funciona la arquitectura Headless?
Como hemos dicho antes, a diferencia de una arquitectura tradicional y monolítica donde la lógica de negocio y la presentación están estrechamente vinculadas, en una arquitectura Headless hay una separación de responsabilidades entre el front-end y el back-end.
Mientras que el back-end se ocupará de gestionar el contenido, la lógica de negocio y almacenar los datos en una base de datos, el front-end haciendo uso generalmente de HTML, CSS y JavaScript, se ocupará únicamente de la presentación del contenido y datos recibidos a través de la REST API que WordPress ofrece de manera nativa, presentando de esta manera el contenido acorde a un diseño final.
Gracias a la REST API de WordPress que actuará como el puente entre back-end y front-end, la Web App podrá fácilmente solicitar los datos necesarios a WP para la presentación final de una página.
Existe un gran abanico de opciones a la hora de utilizar una librería o framework para el desarrollo del front end, entre los más populares están React, Vue, Angular, Next.js, Gatsby y Astro (entre otros)
¿Cuándo usar Headless WordPress?
Cómo podrás imaginar existen ventajas y desventajas a la hora de utilizar este tipo de arquitectura.
Algunas ventajas a destacar son:
- Flexibilidad a la hora de elegir las tecnologías a utilizar en la aplicación front-end.
Para los desarrolladores esto es un gran plus. - Seguridad, ya que se aísla el back-end haciendo más difícil los ataques a la base de datos.
- Rendimiento ya que se reduce la carga en el servidor, se cargan únicamente los archivos HTML con los recursos necesarios para la presentación e interactividad sin tener que cargar enteramente WordPress.
- Experiencia del usuario (UX), hay una mayor flexibilidad a la hora de ofrecer experiencias personalizadas y con el uso de la REST API podemos solicitar los datos necesarios sin tener que recargar la página.
- Escalabilidad, gracias a esta separación de responsabilidades se pueden añadir o eliminar recursos más fácilmente.
Por otro lado, algunas de las desventajas que podemos encontrar son:
- Una mayor complejidad que la arquitectura monolítica tradicional.
- Costes adicionales debido a su complejidad require más trabajo de desarrollo e infraestructura:
- Posiblemente requiriendo servidores adicionales para el front-end.
- El mantenimiento será más costoso ya que es necesario mantener tanto el front-end como el back-end y tener un equipo con habilidades que cubran ambas necesidades.
Un ejemplo básico sería el uso de algún plugin para WordPress que de normal interactúe con el tema o plantilla alterando la presentación del contenido, al prescindir del tema tradicional en una arquitectura Headless el plugin no funcionaría como tal sin requerir un trabajo extra para su compatibilidad con el front-end. - Mayor trabajo para mantener la experiencia del editor de bloques Gutenberg, si lo que se desea es mantener una representación exacta de lo que se ve en el editor con lo que se mostrará en el front-end.
- Requiere de desarrolladores con conocimientos adicionales a los típicos necesarios para un sitio WordPress tradicional.
- Limitaciones con algunas de las novedades en WordPress como Full site editing
Conclusión
Aunque he cubierto algunos de los puntos más importantes a la hora de considerar usar Headless, optar por esta arquitectura es interesante por muchas razones, pero hay que tener en cuenta todos estos aspectos a la hora de tomar una decisión.
A pesar de tener grandes ventajas, y no sólo para los desarrolladores los cuales tendemos a querer usar siempre las últimas tecnologías y frameworks de moda, no siempre es lo más adecuado para un cliente con un presupuesto ajustado que a la larga les resultaría demasiado costoso y perjudicial para su negocio.