Joomla y Next.js: headless sin perder la ACL

A Joomla se le suele dejar fuera de la conversación headless, y eso está desactualizado. Joomla 4 incorporó una API de servicios web en el núcleo

• artículos, categorías, usuarios, con autenticación por token - y Joomla 5 siguió construyendo sobre ella. Es una API REST mantenida como parte de la plataforma y no una extensión que alguien tenga que mantener viva, y eso es lo que convierte esto en una arquitectura real en vez de una idea ingeniosa.

Lo que merece conservarse

Dos cosas, y son la razón de que este emparejamiento sea interesante en lugar de arbitrario.

El control de acceso. La ACL de Joomla es granular en el núcleo: grupos, niveles de acceso, permisos por acción hasta elementos individuales. Si tiene una jerarquía editorial real - colaboradores, revisores, departamentos que solo pueden tocar su propia sección -, ese modelo ya está construido y reproducirlo en otro sitio sale caro.

El montaje multilingüe. Nativo, con asociaciones entre elementos traducidos, y sin plugin. Quien haya ensamblado lo mismo con piezas en otra plataforma sabe lo que eso vale.

Los dos sobreviven al movimiento del front. Ese es el sentido de hacerlo así.

Qué cambia y qué hay que diseñar

El renderizado se mueve, así que el modelo de renderizado es lo primero que hay que entender. Qué rutas son estáticas, cuáles revalidan al publicar, cuáles tienen que ser dinámicas porque dependen de quién pregunta.

Dos cosas necesitan diseño explícito y no suposición.

Permisos de visualización. La ACL sigue decidiendo quién puede editar. Quién puede ver un elemento pasa a tener que respetarlo también el front, de modo que esa lógica existe en dos sitios y tienen que coincidir. Decida dónde se hace la comprobación y déjelo por escrito.

Enrutado de idiomas. Las asociaciones llegan por la API y el front las mapea sobre sus rutas. Derivar el hreflang de esas asociaciones en lugar de una lista en un archivo de configuración es lo que evita que el sitio anuncie traducciones que no existen, que es la forma más habitual en que esto se tuerce.

Qué cuesta

La edición de plantilla. Posiciones de módulos, el gestor de menús, colocar cosas sin un desarrollador. Parte vuelve por la forma en que se construya el front, y es una conversación que hay que tener con los editores antes del proyecto y no después.

La vista previa. Es lo que decide si los editores siguen confiando en el sistema. Si un borrador no se puede ver tal como va a aparecer, el proyecto se da por fallido por razones que no tienen nada que ver con el renderizado. Es el modo de fallo específico de todo proyecto headless, no una peculiaridad de Joomla.

Las extensiones que renderizan. Todo lo que funcionaba emitiendo HTML dentro de una plantilla deja de aplicar. Cada una se convierte en una decisión: reimplementar contra la API, sustituir, o dejar caer a propósito.

Cuándo dejar la plantilla en paz

Si el sitio son artículos y páginas y la plantilla hace su trabajo, las ganancias baratas están en otro lado. Imágenes, tipografías, los scripts que se han ido acumulando. Eso suele ser toda la página lenta, y cuesta una semana en vez de un proyecto.

Headless se gana su sitio cuando el front tiene que ser más que una plantilla: un área de aplicación tras un login, un sistema de diseño compartido con un producto, o un comportamiento de renderizado que la plantilla no puede expresar. Hasta entonces, un sitio Joomla con plantilla mantenida y ACL funcionando es un sitio en buen estado, y no dan premios por sustituirlo.

La mayoría de los sitios que se hacen esta pregunta están en WordPress y no en Joomla, y allí el intercambio es peor, porque el control de acceso y el multilingüe no vienen ya construidos. Esa comparación está aquí.