TYPO3 Headless Mode vs Next.js + Supabase: Ein echter Vergleich
TYPO3 Headless vs. Next.js + Supabase: Ein echte Vergleich
Ich habe die letzten zwei Jahre damit verbracht, Enterprise-TYPO3-Installationen zu Headless-Architekturen zu migrieren. Und wisst ihr, welche Frage die ganze Zeit auftaucht? Sollten wir TYPO3 behalten und mit EXT:headless Headless gehen oder es für Next.js mit etwas wie Supabase aufgeben? Das ist ganz schön knifflig, oder? Wie die meisten Architekturentscheidungen, kommt die Antwort auf „das hängt davon ab" hinaus. Aber lass uns genau aufschlüsseln, wovon das abhängt.
Das ist für mich nicht akademisch. Ich habe Produktionsseiten mit beiden Ansätzen gestartet, bin bei diesen lästigen Edge Cases ins Schwitzen gekommen und habe Teams mit jedem Stack entweder triumphieren oder kämpfen gesehen – manchmal spektakulär. Lass mich erzählen, was ich dabei gelernt habe.
Die beiden Ansätze verstehen
Erste Dinge zuerst: Was vergleichen wir hier überhaupt? Das sind zwei völlig verschiedene Dinge.
TYPO3 + EXT:headless (Entkoppelt)
Damit bleibt TYPO3 dein CMS und kümmert sich um alle Backend-Aufgaben der Inhaltsverwaltung. Der Trick ist, dass du die alte Fluid/TypoScript-Rendering durch eine JSON-API ersetzt. Dein glänzendes neues Frontend? Das könnte React, Vue oder was auch immer sein, das diese API konsumiert. TYPO3 verwaltet weiterhin all die guten Dinge wie Modelle, Berechtigungen und Workflows.
Die EXT:headless-Erweiterung? Das ist das VIP-Backstage-Ticket, das in TYPOs Rendering-Prozess kommt und JSON statt HTML ausgibt. Es ist nicht einfach eine Add-on-API – es ist die echte Sache, die direkt mit TYPOs Content-Eingeweiden funktioniert.
Next.js + Supabase (Vollständig Headless)
Andererseits verwaltet Next.js dein Frontend und die serverseitige Logik. Supabase (eine wilde Kombination aus PostgreSQL, Auth, Dateispeicher und Echtzeit-Features) kümmert sich um dein Backend. Kein TYPO3 hier, Leute. Du wirfst das alte CMS weg und wählst pure Flexibilität und ein modernes JS-natives Setup.
Wie EXT:headless eigentlich funktioniert
Wenn du ext:headless zu TYPO3 hinzufügst, registriert es einen neuen Seitentyp, der alles verändert. Keine Inhalte mehr durch Fluid-Templates; stattdessen gibt es JSON aus.
Hier ein Vorgeschmack auf das, was du bekommst:
{
"id": 42,
"type": "textmedia",
"content": {
"header": "Welcome to our site",
"headerLayout": 2,
"bodytext": "<p>Some rich text content here</p>",
"media": [
{
"publicUrl": "/fileadmin/images/hero.webp",
"properties": {
"width": 1920,
"height": 1080,
"alt": "Hero image"
}
}
]
},
"appearance": {
"layout": "default",
"frameClass": "default",
"spaceAfter": "medium"
}
}
Das Frontend verbindet diese Punkte dann zu React/Vue-Komponenten. Wenn du mit einem komponentenbasierten CMS herumgebastelt hast, wird sich das wie dein liebster alter Pullover anfühlen.
EXT:headless einrichten
Eine typische Einrichtung beginnt so:
composer require friendsoftypo3/headless
Und in deinem TypoScript:
plugin.tx_headless {
settings {
debug = 0
}
}
page = PAGE
page {
typeNum = 0
10 = USER
10.userFunc = FriendsOfTYPO3\Headless\ContentObject\JsonContentObject->render
}
Hier der Knackpunkt: Für jedes benutzerdefinierte Content-Element in TYPO3 benötigst du JSON-Serialisierer. Für eine Website mit, sagen wir, einer Handvoll benutzerdefinierter Elemente? Du schaust auf ein paar Tage Arbeit. Ein massives Enterprise-Setup mit dutzenden Elementen? Mach dich bereit – das könnte Wochen dauern.
Das macht TYPO3 Headless gut
- Das Editoren-Erlebnis bleibt intakt. TYPOs vertrautes Backend bedeutet kein Umschulung für Content-Editoren.
- Erhaltung bestehender Inhalte. Deine Einrichtungen verschwinden nicht. All deine Inhalte, Übersetzungen und Medien? Sie bleiben.
- Mehrsprachige Unterstützung rockt. TYPO3 hat einige der besten Sprachbehandlungen, die ich je gesehen habe.
- Enterprise-ready Features. Alles von Workspaces bis geplante Veröffentlichung ist einsatzbereit.
Der Haken bei EXT:headless
- TYPO3 geht nirgendwo hin. Du wirst PHP-versierte Leute brauchen, die TYPO3 verstehen, und die gibt es nicht überall.
- Komplexes Hosting. Du jonglierst PHP (TYPO3) und Node.js (dein Frontend). Doppelter Spaß, doppelte Komplexität.
- Begrenzte API-Schnittstelle. Es ist JSON, nicht GraphQL. Anpassung bedeutet, sich wieder in TYPO3-Erweiterungsentwicklung zu vertiefen.
- Vorschau-Kopfschmerz. Integration einer Echtzeit-Vorschau mit TYPO3 und Next.js? Nichts für schwache Nerven.
Next.js + Supabase: Der vollständig Headless Stack
Das Layout
Mit diesem Setup kümmert sich Next.js um deine Anwendungsschicht, und Supabase kümmert sich um alle Datenbank- und Backend-Aufgaben.
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ Next.js │────▶│ Supabase │────▶│ PostgreSQL │
│ (App Router)│ │ (BaaS) │ │ (Database) │
└─────────────┘ └──────────────┘ └─────────────┘
Content-Verwaltung ohne TYPO3
Hier wird es knifflig. Wie verwalten Editoren Inhalte?
- Benutzerdefiniertes Admin-Panel. Es ist mehr Arbeit als man denkt.
- Supabase Studio. Großartig für Entwickler, Editoren könnten es hassen.
- Fügen Sie ein CMS hinzu. Verwalten Sie nun drei Dienste.
- Verwenden Sie Payload mit seiner eigenen Datenbank. Ziemlich elegant, wenn du mich fragst.
Nur damit du es siehst, hier eine grundlegende Content-Abruf-Implementierung mit Supabase:
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.SUPABASE_SERVICE_ROLE_KEY!
)
export async function getPage(slug: string) {
const { data, error } = await supabase
.from('pages')
.select(`
id,
title,
slug,
meta_description,
content_blocks (
id,
type,
content,
sort_order
)
`)
.eq('slug', slug)
.eq('status', 'published')
.single()
if (error) throw error
return data
}
Wo Next.js + Supabase glänzt
- Himmelhohe Leistung. Statische Generierung, ISR, Edge-Rendering – dein Spielplatz für Geschwindigkeit.
- Entwickler-Überfluss. JavaScript/TypeScript-Leute sind überall.
- Supabase's Row Level Security. Ernsthaft cool für wenn du stramme Kontrolle willst.
- Echtzeit-Features. Integriere Live-Updates wie im Schlaf.
- Einfache Bereitstellung. Verwende Vercel für Next.js und Supabase Cloud für Backend oder hoste selbst, wenn nötig.
Die Probleme hier
- DIY CMS. Wenn du nicht ein anderes Headless CMS hinzufügst, rollst du grundsätzlich dein eigenes.
- Editorial Black Hole. Keine integrierten Workflows. Entwurfszustände, geplante Veröffentlichung? Du musst sie selbst machen.
- Sprachenverwaltung. Mehrsprachiger Content-Support? Du wirst Schweiß vergießen, das In-House zu bauen.
- Medien-Management-Probleme. Supabase-Speicher ist nicht für digitale Assets ausgelegt. Behalte das im Hinterkopf.
Kopf-an-Kopf Vergleich
Schau dir an, wie sie sich stapeln:
| Feature | TYPO3 + EXT:headless | Next.js + Supabase |
|---|---|---|
| Editing UX | Excellent | Custom oder hinzugefügtes CMS |
| Mehrsprachig | Native | DIY-Implementierung |
| Workflows | Built-in | Custom Build erforderlich |
| Leistung | Gut | Excellent |
| API | Limited | Vollständige Kontrolle |
| Echtzeit | Abwesend | Unterstützt |
| Auth | Legacy | Modern und flexibel |
| Komplexität | Hoch | Mittel |
| Talentpool | Knapp | Reichlich |
| Content-Migration | Unnötig | Vollständige Migration |
| Features | Eingebaut | Bauen oder kaufen |
| Einrichtungszeit | 2-4 Wochen | 4-8 Wochen |
| Kosten (Hosting) | €150-500 | €45-200 |
Performance-Benchmarks
Schau dir einige Zahlen von einer Website an, die ich getestet habe – Corporate-Website, 200 Seiten, multilinguale Unterstützung:
| Metrik | TYPO3 Headless + Next.js | Next.js + Supabase (SSG) |
|---|---|---|
| TTFB (ungecacht) | 280ms | 45ms |
| TTFB (CDN-gecacht) | 35ms | 32ms |
| LCP | 1.8s | 1.2s |
| CLS | 0.02 | 0.01 |
| Lighthouse Score | 92 | 98 |
| Build-Zeit (vollständig) | 4m 20s | 1m 45s |
| API-Antwort (p95) | 180ms | 22ms |
Fazit? Während ungecachtes TTFB mit Supabase besser ist, macht CDN-Caching das Feld ziemlich flach. Beide rasen schnell genug für den Endbenutzer, wenn richtig eingerichtet.
Entwicklererfahrung und Teamüberlegungen
Sich in TYPO3 vertiefen
Du brauchst immer noch TYPO3-Profis für Headless-Projekte. Denk an PHP-Serialisierer, Test-Upgrades und Umgang mit Kompatibilitätsproblemen. Im Jahr 2025 könnten diese Experten dir €80-120/Stunde kosten. Und einige Entwickler sind nicht begeistert von Headless-Setups – es nimmt die Freude an Fluid-Templating weg.
Der Next.js + Supabase Club
JavaScript-Entwickler sind reichlich vorhanden, aber denk daran, dass das Entwerfen von Content-Management-Systemen nicht jedem leicht fällt. Supabase's Entwickler-Erlebnis ist ziemlich elegant: Auto-generierte TypeScript-Typen, Echtzeit-Abos und solide Auth-Helfer. Aber all die Datenmodellierung und architektonischen Entscheidungen? Die liegen alle bei dir.
Erkundet ihr diese Route? Unser Team hat Expertise in Next.js-Entwicklung verfeinert, um dir üble Überraschungen zu ersparen.
Migrationsstrategien
Von traditionellem TYPO3 zu TYPO3 Headless
Risiko niedriger, Inhalte bleiben intakt. Hauptsächlich ein Frontend-Rewrite.
- EXT:headless ausrollen
- Content-Elemente zu JSON zuordnen
- Das Next.js/Nuxt-Frontend bauen
- Vorschau-Integration sortieren
- Go live!
Zeitrahmen: 8-16 Wochen für eine gut dimensionierte Corporate-Website.
Von TYPO3 zu Next.js + Supabase
Halte dich fest, das ist ein vollständiger Neubau.
- Prüfe aktuelle Content-Setups
- Skizziere dein PostgreSQL-Schema
- Schreibe Migrations-Skripte
- Verschiebe Medien und Dateireferenzen
- Baue Editorial-Tools oder integriere ein anderes CMS
- Baue erneut für das Frontend
- Beschäftige dich mit URL-Weiterleitungen
- Propagiere mehrsprachige Inhalte
Zeitrahmen: 16-32 Wochen. Komplexe Headless-Entwicklung? Hole Profis rein, um das Leben einfacher zu machen.
Kostenanalyse
Lass uns einen Mittelstand-Corporate-Setup zusammenzählen: 200 Seiten, 3 Sprachen, 5 Editoren, 50K monatliche Besucher.
TYPO3 Headless — Kosten Jahr 1
| Posten | Kosten |
|---|---|
| TYPO3 Hosting (Managed) | €3.600/Jahr |
| Next.js Hosting (Vercel Pro) | €240/Jahr |
| Frontend-Entwicklung | €25.000-45.000 |
| EXT:headless Integration | €8.000-15.000 |
| Total Jahr 1 | €36.840-63.840 |
| Laufend jährlich | €5.000-8.000 |
Next.js + Supabase — Kosten Jahr 1
| Posten | Kosten |
|---|---|
| Supabase Pro | €300/Jahr |
| Vercel Pro | €240/Jahr |
| Fügen Sie CMS hinzu (wenn nötig) | €0-3.600/Jahr |
| Content-Migration | €10.000-20.000 |
| Frontend + Backend-Entwicklung | €40.000-70.000 |
| Editorial-Tools | €10.000-25.000 |
| Total Jahr 1 | €60.540-119.140 |
| Laufend jährlich | €2.000-6.000 |
Vollständig Headless zu gehen kostet große Anfangsinvestitionen, senkt aber monatliche Kosten, weil du TYPO3-Hosting aufgibst. Unterschätze nur nicht die zusätzliche CMS-Konstruktion obendrauf.
Wann welchen wählen
TYPO3 + EXT:headless
- Halte bei Legacy-Inhalten und etablierten Workflows fest.
- Behalte vertraute Editorial-Einstellungen und reichhaltige Features.
- Profitiere von ausgefeilter nativer Mehrsprachen-Unterstützung.
- Behalte TYPO3-Entwickler.
Next.js + Supabase
- Wenn du von vorne beginnst.
- Die Anwendung benötigt reichhaltige interaktive Features.
- Dein Dev-Team ist bereits JavaScript-fokussiert.
- Top-Tier-Leistung ist ein Schlüsselfokus.
- Angenehm damit, ein Headless CMS hinzuzufügen.
Erwäge einen dritten Winkel
Vielleicht ist dir das Mischen in den Sinn gekommen? Next.js, ein Headless CMS, plus Supabase für App-Daten kann das beste verbinden. Es bietet ausgewogene Editorial-Tools ohne TYPO3-Gepäck. Wenn du auch Optionen wie Astro-Entwicklung für leichtgewichtige Content-schwere Websites in Betracht ziehst, das ist einen Blick wert.
Möchtest du über deine spezifischen Anforderungen chatten? Wir sind hier, um zu helfen, was für dein einzigartiges Szenario sinnvoll ist – kontaktiere uns, und wir versprechen eine ehrliche Bewertung, selbst wenn es „bleibe bei dem, was du kennst" ist.
FAQ
Ist TYPO3 EXT:headless 2025 produktionsbereit? Ja, absolut. EXT:headless ist seit Version 3.x stabil und wird aktiv unterstützt. Version 4.x deckt TYPO3 v12 und v13 mit solider Content-Serialisierung, Menu-Generierung und Form-Handling ab. Eine Menge großer Enterprise-Seiten führen es in Production-Setups aus, einschließlich Sektoren wie Regierung und Banking in Deutschland und Österreich.
Kann ich Next.js für ein TYPO3 Headless-Frontend verwenden? Sicher, es ist eine klassische Kombination. Du wirst Next.js App Router mit Server-Komponenten nutzen, um Infos von TYPOs JSON-API zu sammeln. Vorschau-Integration ist das kniffligste Bit: Richte Draft-Mode ein und leite TYPO3 an, es über Vorschau-URLs zu rufen. Zum Glück hat die Community hilfreiche Dokumentation, die dich durch die Next.js-Paarung führt.
Wie vergleicht sich Supabase mit TYPOs Datenbank-Setup? Oh, das sind Äpfel und Birnen. TYPO3 läuft auf Doctrine DBAL mit einem strengeren von TCA verwalteten Schema. Supabase gibt diese süße PostgreSQL-Freiheit mit Row Level Security. Supabase bietet flexible und mächtige Abfragefähigkeit, aber TYPO3 ist sorgfältig strukturiert, um Fehler zu verhindern, die Editoren versehentlich machen könnten. Es geht um Kontrolle versus Sicherheit.
SEO-Bedenken bei Headless TYPO3? Meta-Tags und strukturierte Daten?
EXT:headless serialisiert Seiteneigenschaften wie Meta-Tags und Open Graph-Daten. Dein Frontend muss sie als HTML-Tags rendern. Verwende Next.js's Metadata API in Layouts. Solange dein TYPO3-Setup solide ist, sollten SEO-Daten folgen. Integriere Erweiterungen wie EXT:yoast_seo und es spielt schön mit Headless-Konfigurationen.
Ist Supabase auf Enterprise-Level Content-Delivery gewachsen? Es ist es bestimmt. Supabase Cloud, läuft auf AWS, bietet 99,9% Uptime auf Pro-Plänen und erhöht auf 99,95% auf Team-Plänen (überprüfe 2025 Tarife). Für CDN-Caching (Vercel's Edge Network, Cloudflare), stellt Supabase hauptsächlich Write- und Echtzeit-Feature-Zuverlässigkeit sicher. Für kritische Enterprise-Nutzung, selbst-hoste Supabase für maximale Kontrolle.
Wie gehen wir Image-Processing ohne TYPO3 an? TYPO3 verarbeitet Bilder nativ – Zuschnitt, Resize, Format-Flip. Ohne es, richte deinen Image-Workflow ein. 2025er Top-Kandidaten sind: Next.js Image Optimization (eingebaut, Vercel-unterstützend), Cloudinary (kostenlos starten, ernsthafte Nutzung erfordert bezahlte Pläne), oder imgix (Start bei €100+/Monat). Supabase Storage hält Originale, aber keine Transformationen.
Können wir schrittweise von TYPO3 Headless zu vollständig Headless migrieren? Absolut, denk daran wie an einen glatten Plan. Beginne mit Headless TYPO3, isoliere dein Frontend. Verschiebe Content schrittweise von TYPO3 zu Supabase oder deinem gewählten CMS – beginne mit einfacheren Typen. Während der Phase operiert dein Next.js-Frontend mit Daten aus beiden Quellen.
Wie ist die Lernkurve für ein TYPO3-Team, das zu Next.js + Supabase wechselt? Ein realistisches Hochfahren ist etwa drei bis sechs Monate. Allerdings ist die Herausforderung nicht JavaScript oder TypeScript – es ist die Paradigma-Verschiebung. TYPO3-Entwickler sind es gewohnt, dass das Framework Content-Strukturen, Caching und Routen lenkt. Im Next.js + Supabase-Modell sind diese Anrufe deine. Es ist befreiend aber überwältigend zuerst. Pair Programming mit erfahrenen Next.js-Leuten macht diese Sprung viel reibungsloser.