Wofür TYPO3, wofür Astro? Und wo das Formular zum Stolperdraht wird

Im ersten Teil dieser Reihe ging es um den Speed-Mythos, mit dem Ergebnis, dass Geschwindigkeit die Wahl zwischen einem CMS wie TYPO3 und einem statischen Generator wie Astro nicht entscheidet. Wenn also nicht das Tempo, was dann? Die ehrliche Antwort ist ein nüchternes „kommt auf den Job an". Beide Werkzeuge sind gut, nur nicht für dasselbe. Dieser Beitrag liefert das Entscheidungsraster und benennt die eine Stelle, an der viele statische Projekte ins Straucheln geraten.

Fünf Fragen, die die Wahl entscheiden

Bevor man über Werkzeuge redet, klärt man das Projekt. Fünf Fragen genügen meist:

• Wer pflegt die Inhalte? Ein Redakteur ohne technischen Hintergrund, oder ein Entwickler mit Zugriff auf Git?
• Wie dynamisch ist die Seite? Ändert sich Inhalt mehrmals täglich, oder steht er über Monate?
• Werden Nutzerdaten erfasst? Formulare, Anmeldungen, geschützte Bereiche?
• Wie groß ist die Struktur? Ein paar Seiten, oder ein Seitenbaum mit Hunderten Einträgen, Sprachen und Rechten?
• Wer betreibt das Ganze über die Jahre? Und wie lange soll es tragen?

Die Antworten zeigen die Richtung deutlicher als jede Framework-Diskussion.

Wofür TYPO3 die passendere Wahl ist

TYPO3 spielt seine Stärke dort aus, wo eine Redaktion die Seite betreibt und nicht ein Entwicklerteam. Rollen, Rechte und Freigabe-Abläufe sind eingebaut, Mehrsprachigkeit ebenso. Für einen großen Seitenbaum, der von mehreren Personen ohne technisches Wissen gepflegt wird, ist das kein Komfort, sondern die Grundvoraussetzung.

Der zweite Bereich ist alles, was Daten erfasst: Formulare, Anmeldungen, geschützte Mitgliederbereiche, ein Altersnachweis vor bestimmten Inhalten. Ein CMS bringt hier die serverseitige Verarbeitung von Haus aus mit. Dazu kommen die unspektakulären, aber entscheidenden Anforderungen: ein langer Wartungshorizont mit planbaren Sicherheits-Updates, ein nicht-technischer Betreiber, der die Seite selbst pflegen können muss, und der gemeinsame Betrieb mehrerer Auftritte auf einer Plattform.

Wofür Astro die passendere Wahl ist

Astro ist kein schwächeres Werkzeug, sondern eines für einen anderen Job. Seine natürliche Heimat sind Auftritte, deren Inhalt aus einer Quelle im Code entsteht und nicht klickend im Browser gepflegt wird: eine Marketing- oder Kampagnen-Landingpage, ein technischer Blog, eine Dokumentation, ein Changelog, ein One-Pager. Überall dort, wo der Inhalt als Markdown im Git-Repository liegt und ein Entwickler ihn ändert, ist ein Redaktions-Backend überflüssig.

Dazu kommen Fälle, in denen die geringe Angriffsfläche und der günstige Betrieb im Vordergrund stehen. Eine rein statisch ausgelieferte Seite hat keine Datenbank und keine Anwendungslogik, die angegriffen werden könnte, und sie lässt sich sehr preiswert hosten. Wo niemand redaktionell editiert und Resilienz zählt, ist das ein echtes Argument.

Der Stolperdraht: das Formular

Genau ein Punkt bringt statische Projekte immer wieder ins Straucheln, und er wird gern übersehen: Ein statisches Frontend endet beim Absenden. Es kann ein Formular anzeigen, aber es kann die Eingaben nicht selbst entgegennehmen, denn dafür braucht es Server-Logik, und die hat ein statischer Generator nicht. Was dann folgt, ist ein Spektrum mit sehr unterschiedlichen Folgen für den Datenschutz:

• Ein Formular-Dienst eines Drittanbieters. Schnell eingebaut, aber die Daten laufen über einen fremden Server, häufig außerhalb der EU. Für eine Kanzlei, eine Praxis oder jeden, der mit sensiblen Anfragen arbeitet, ist das eine datenschutzrechtliche Reibungsstelle.
• Eine eigene Serverless-Funktion in der EU. Sauberer, aber es ist zusätzliche Infrastruktur, die gebaut, betrieben und gewartet werden will, neben der eigentlich statischen Seite.
• Ein eigener kleiner Endpunkt. Datenschutzrechtlich am saubersten und vollständig in eigener Hand, aber damit ist die Seite genau genommen nicht mehr rein statisch.

In einem CMS stellt sich diese Frage nicht neu, denn die Formularverarbeitung ist serverseitig und ohne Drittanbieter bereits Teil des Systems. Das ist kein Astro-Nachteil an sich, sondern eine Konsequenz aus der Bauart, die man vor der Entscheidung kennen sollte.

Die Grauzone, ehrlich benannt

Nicht jeder Fall ist eindeutig. Ein einzelnes Kontaktformular auf einer sonst statischen Seite ist über einen sauberen eigenen Endpunkt gut lösbar und kein Grund gegen Astro. Umgekehrt gibt es Auftritte, die redaktionell gepflegt werden und trotzdem die Auslieferung eines statischen Frontends wünschen. Dafür existiert der Weg, ein CMS als reines Redaktionswerkzeug im Hintergrund zu betreiben und Astro nur die Darstellung übernehmen zu lassen. Dieser Doppelaufbau ist legitim, aber er verdoppelt auch die Teile, die man pflegt. Er lohnt sich nur, wenn beide Bedürfnisse zwingend zusammenkommen, nicht aus Neugier auf die Kombination.

Zwei Faustregeln

Auf das Wesentliche reduziert bleiben zwei Sätze:

• Wird die Seite redaktionell betrieben oder sammelt sie Nutzerdaten, führt der Weg zu einem CMS wie TYPO3.
• Publiziert sie Inhalte statisch und editiert niemand klickend im Browser, ist ein statischer Generator wie Astro die schlankere Wahl.

Alles dazwischen ist eine Abwägung entlang der fünf Fragen vom Anfang. Die Wahl ist dann begründet, nicht zufällig. Wer bei der eigenen Situation unsicher ist, ordnet sie am besten an einem konkreten Projekt ein, statt an einem Trend. Genau diese Einordnung nehmen wir im Erstgespräch nüchtern mit Ihnen vor.

Teil 2 von 3 der Reihe „TYPO3 und Astro". Teil 1: Ist Astro schneller als TYPO3?