Angular & TYPO3

Por qué Angular funciona con TYPO3, pero la mayoría de configuraciones fracasan

La idea suena convincente: TYPO3 entrega contenido como JSON, Angular renderiza el frontend como Single Page Application. Los redactores trabajan en el backend familiar de TYPO3, los desarrolladores construyen un frontend moderno sin las restricciones de TypoScript. En la práctica, muchos proyectos Angular-TYPO3 fracasan en la frontera arquitectónica entre CMS y SPA. La extensión oficial TYPO3 Headless (EXT:headless) resuelve el problema de entrega de contenido. Pero routing, preview, SEO y caché necesitan soluciones bien pensadas que van más allá de un ng serve.

Angular como frontend para TYPO3 es adecuado para empresas que necesitan contenido multicanal: un sitio web, una app, un portal de intranet y digital signage desde una única fuente de contenido. El esfuerzo se rentabiliza a partir del segundo canal. Para sitios web puros sin ambición de app, un setup clásico TYPO3-Fluid es casi siempre más eficiente.

Escenarios de uso habituales

Plataformas multicanal con app y web. Un proveedor de automoción mantiene datos de productos, información de servicio y noticias en TYPO3. El sitio web funciona como SPA Angular, la app de servicio para técnicos usa la misma API JSON. Los cambios en TYPO3 aparecen en ambos canales simultáneamente. El contenido se mantiene una vez, se entrega dos veces.

Portales de intranet con interacción compleja. Dashboards de RRHH, plataformas de gestión del conocimiento y herramientas internas se benefician del enfoque basado en componentes de Angular. TYPO3 entrega contenido estructurado (políticas, manuales, organigramas), Angular renderiza vistas interactivas con filtros, búsqueda y actualizaciones en tiempo real. La autenticación se ejecuta a través del LDAP/SSO existente, TYPO3 verifica permisos mediante fe_group.

Configuradores y páginas de producto interactivas. Fabricantes de productos configurables usan Angular para la vista 3D o el configurador. Los datos maestros del producto provienen de TYPO3, la lógica de configuración vive en el frontend Angular. En un cliente con 1.200 variantes configurables, este enfoque redujo el tiempo de carga de la página del configurador de 4,2 a 1,1 segundos.

Arquitectura técnica

La extensión TYPO3 Headless transforma la salida estándar de HTML a JSON. Cada elemento de contenido, cada navegación, cada nivel de breadcrumb se entrega como objeto JSON. Angular consume esta API mediante servicios HttpClient.

La arquitectura consta de tres capas. TYPO3 como backend entrega contenido a través de la API Headless bajo /api/. Angular como aplicación frontend se compila como proceso de build separado (ng build --prod) y normalmente se entrega a través de un CDN o servidor web independiente. Entre ambos se encuentra un servidor SSR basado en Node.js (Angular Universal) que se encarga del Server-Side Rendering para SEO y redes sociales.

El routing es dual: Angular Router gestiona la navegación del lado del cliente, TYPO3 define la estructura de URLs mediante Site Configuration. Ambos deben permanecer sincronizados. En la práctica esto significa: cuando un redactor crea una nueva página en TYPO3, Angular debe conocer esa URL. La solución es un routing dinámico en el frontend Angular que consulta la estructura de páginas desde la API TYPO3 en cada build.

Los servicios TypeScript se generan a partir de los tipos de contenido de TYPO3. Para cada Content Element existe un componente Angular con tipado. Estos tipos se pueden generar mediante script desde la API TYPO3, lo que garantiza la sincronización entre backend y frontend.

Problemas frecuentes y soluciones

Deficiencias SEO por renderizado solo del lado del cliente. Google renderiza JavaScript, pero no de forma fiable ni inmediata. Sin Server-Side Rendering (Angular Universal o Angular SSR desde v17) las páginas se indexan tarde o nunca. La solución: implementar Angular Universal como capa SSR. La respuesta HTML inicial debe estar completamente renderizada antes de que el proceso de hidratación del lado del cliente tome el control.

La preview de contenido en el backend TYPO3 no funciona. Los redactores hacen clic en “Vista previa” y ven JSON en lugar de una página renderizada. La solución: configurar un proxy de preview que reenvíe la respuesta JSON a una instancia de preview Angular dedicada. EXT:headless ofrece un modo de preview que entrega contenido borrador a través de un parámetro token.

Problemas CORS entre la API TYPO3 y el frontend Angular. Cuando TYPO3 y Angular funcionan en dominios diferentes, el navegador bloquea las peticiones API. La extensión EXT:cors o un reverse proxy del lado del servidor resuelve este problema. Recomendado: operar ambos bajo el mismo dominio (TYPO3 bajo /api/, Angular bajo /).

Migración y compatibilidad de versiones

EXT:headless es oficialmente compatible con TYPO3 v11, v12 y v13. La extensión se mantiene activamente y sigue el ciclo de releases de TYPO3. Angular tiene su propio ritmo de releases: cada 6 meses una nueva versión major. Desde Angular v17, SSR está integrado nativamente (ya no se necesita un paquete separado Angular Universal).

Para proyectos Angular-TYPO3 existentes en TYPO3 v10 o anterior, se recomienda una migración por fases: primero actualizar TYPO3 a v12 o v13, luego Angular a la versión LTS actual (v18). La interfaz API de EXT:headless ha cambiado entre v2 y v4 en varios puntos, especialmente en el tratamiento de los language overlays y workspace previews.

El esfuerzo de un proyecto Angular-TYPO3 es típicamente un 30-50% superior al de un proyecto Fluid puro. Este esfuerzo adicional se recupera con el segundo canal (app, intranet). Gosign asesora antes del inicio del proyecto sobre si Headless es el enfoque adecuado o si un setup clásico con islas JavaScript específicas cumple el mismo propósito.