Angular & for TYPO3

Warum Angular mit TYPO3 funktioniert, aber die meisten Setups scheitern

Die Idee klingt überzeugend: TYPO3 liefert Content als JSON, Angular rendert das Frontend als Single Page Application. Redakteure arbeiten im gewohnten TYPO3-Backend, Entwickler bauen ein modernes Frontend ohne TypoScript-Zwänge. In der Praxis scheitern viele Angular-TYPO3-Projekte an der Architektur-Grenze zwischen CMS und SPA. Die offizielle TYPO3 Headless Extension (EXT:headless) löst das Content-Delivery-Problem. Aber Routing, Preview, SEO und Caching brauchen durchdachte Lösungen, die über ein ng serve hinausgehen.

Angular als Frontend für TYPO3 eignet sich für Unternehmen, die Multi-Channel-Content brauchen: eine Website, eine App, ein Intranet-Portal und Digital Signage aus einer Content-Quelle. Der Aufwand rechnet sich ab dem zweiten Kanal. Für reine Websites ohne App-Ambition ist ein klassisches TYPO3-Fluid-Setup fast immer effizienter.

Typical use cases

Multi-Channel-Plattformen mit App und Web. Ein Automobilzulieferer pflegt Produktdaten, Serviceinformationen und News in TYPO3. Die Website läuft als Angular-SPA, die Service-App für Techniker nutzt dieselbe JSON-API. Änderungen in TYPO3 erscheinen auf beiden Kanälen gleichzeitig. Der Content wird einmal gepflegt, zweimal ausgeliefert.

Intranet-Portale mit komplexer Interaktion. HR-Dashboards, Wissensmanagement-Plattformen und interne Tools profitieren von Angulars komponentenbasiertem Ansatz. TYPO3 liefert strukturierten Content (Policies, Handbücher, Organigramme), Angular rendert interaktive Views mit Filtern, Suche und Echtzeit-Updates. Die Authentifizierung läuft über das bestehende LDAP/SSO, TYPO3 prüft Berechtigungen per fe_group.

Konfiguratoren und interaktive Produktseiten. Hersteller von konfigurierbaren Produkten nutzen Angular für die 3D-Ansicht oder den Konfigurator. Die Produktstammdaten kommen aus TYPO3, die Konfigurationslogik lebt im Angular-Frontend. Bei einem Kunden mit 1.200 konfigurierbaren Varianten reduzierte dieser Ansatz die Ladezeit der Konfiguratorseite von 4,2 auf 1,1 Sekunden.

Technical architecture

Die TYPO3 Headless Extension transformiert die Standard-Ausgabe von HTML in JSON. Jedes Content-Element, jede Navigation, jede Breadcrumb-Ebene wird als JSON-Objekt ausgeliefert. Angular konsumiert diese API über HttpClient-Services.

Die Architektur besteht aus drei Schichten. TYPO3 als Backend liefert Content über die Headless-API unter /api/. Angular als Frontend-Applikation wird als eigener Build-Prozess (ng build --prod) kompiliert und typischerweise über ein CDN oder einen separaten Webserver ausgeliefert. Dazwischen steht ein Node.js-basierter SSR-Server (Angular Universal), der Server-Side Rendering für SEO und soziale Netzwerke übernimmt.

Das Routing ist zweigeteilt: Angular Router übernimmt die Client-seitige Navigation, TYPO3 definiert die URL-Struktur über Site Configuration. Beide müssen synchron bleiben. In der Praxis bedeutet das: Wenn ein Redakteur in TYPO3 eine neue Seite anlegt, muss Angular diese URL kennen. Die Lösung ist ein dynamisches Routing im Angular-Frontend, das die Seitenstruktur bei jedem Build aus der TYPO3-API abfragt.

TypeScript-Services werden aus den TYPO3 Content-Typen generiert. Für jedes Content Element existiert ein Angular Component mit Typing. Diese Typen lassen sich per Script aus der TYPO3-API generieren, was den Gleichlauf zwischen Backend und Frontend sicherstellt.

Common problems and solutions

SEO-Defizite durch Client-Side-Only-Rendering. Google rendert JavaScript, aber nicht zuverlässig und nicht sofort. Ohne Server-Side Rendering (Angular Universal oder Angular SSR seit v17) werden Seiten spät oder gar nicht indexiert. Die Lösung: Angular Universal als SSR-Layer einsetzen. Der initiale HTML-Response muss vollständig gerendert sein, bevor der Client-seitige Hydration-Prozess übernimmt.

Content-Preview im TYPO3-Backend funktioniert nicht. Redakteure klicken auf “Vorschau” und sehen JSON statt eine gerenderte Seite. Die Lösung: einen Preview-Proxy konfigurieren, der die JSON-Antwort an eine dedizierte Angular-Preview-Instanz weiterleitet. EXT:headless bietet dafür einen Preview-Modus, der Draft-Content über einen Token-Parameter ausliefert.

CORS-Probleme zwischen TYPO3-API und Angular-Frontend. Wenn TYPO3 und Angular auf unterschiedlichen Domains laufen, blockiert der Browser die API-Requests. Die Extension EXT:cors oder ein serverseitiger Reverse-Proxy löst dieses Problem. Empfohlen: Beide unter derselben Domain betreiben (TYPO3 unter /api/, Angular unter /).

Migration and version compatibility

EXT:headless ist offiziell kompatibel mit TYPO3 v11, v12 und v13. Die Extension wird aktiv gepflegt und folgt dem TYPO3-Release-Zyklus. Angular selbst hat einen eigenen Release-Rhythmus: alle 6 Monate eine neue Major-Version. Seit Angular v17 ist SSR nativ integriert (kein separates Angular Universal Paket mehr nötig).

Für bestehende Angular-TYPO3-Projekte auf TYPO3 v10 oder älter empfiehlt sich eine stufenweise Migration: erst TYPO3 auf v12 oder v13 aktualisieren, dann Angular auf die aktuelle LTS-Version (v18). Die API-Schnittstelle von EXT:headless hat sich zwischen v2 und v4 an mehreren Stellen geändert, insbesondere bei der Behandlung von Sprach-Overlays und Workspace-Previews.

Der Aufwand für ein Angular-TYPO3-Projekt liegt typischerweise 30-50% über dem eines reinen Fluid-Projekts. Diesen Mehraufwand holt man durch den zweiten Kanal (App, Intranet) wieder ein. Gosign berät vor dem Projektstart, ob Headless der richtige Ansatz ist oder ob ein klassisches Setup mit gezielten JavaScript-Inseln den gleichen Zweck erfüllt.