Architektur 101: Frameworks, Monorepos und wie moderne Apps zusammenpassen

Überblick

Du hast Kurs 1 mit dem Shippen einer echten Seite abgeschlossen und Kurs 2 damit, deinen Agent in ein Power-Tool zu verwandeln. Jetzt steigst du von einer einzelnen statischen Seite zu einer echten Anwendung mit Nutzern, Daten und Payments auf. Vor all dem brauchst du die Karte. Diese Lektion ist diese Karte: was ein Framework tatsächlich für dich tut, die drei Schichten, aus denen jede App gebaut ist, warum ernsthafte Teams eine schnelle Marketing-Seite von der schwereren App trennen und wann ein Monorepo ein Geschenk ist gegenüber einer Steuer. Mach das klar, und jede spätere Entscheidung in diesem Kurs fühlt sich nicht mehr willkürlich an.

Was du lernst

Du lernst den Unterschied zwischen Frontend, Backend und Datenbank in klarer Sprache, wie die wichtigsten 2026er Frameworks im Vergleich stehen und wann jedes passt, warum Firmen wie Clerk und Convex eine separate Marketing-Seite von ihrer App betreiben und die ehrliche Regel, wann sich ein Monorepo auszahlt. Am Ende kannst du die Architektur jedes SaaS auf einer Serviette skizzieren und erklären, warum sie so geformt ist.

Voraussetzungen

Kurs 1, besonders die Lektionen zum Projekt-Setup und Deploy, denn Architekturentscheidungen bauen auf einer funktionierenden Bauen-und-Shippen-Schleife auf. Du solltest dich beim Ausführen von Terminal-Befehlen wohlfühlen und mindestens eine Seite deployed haben. Wenn die Wörter "Framework" oder "TypeScript" noch unscharf sind, überflieg zuerst die Grundlagen-Seiten dazu, was ein Framework ist und was TypeScript ist, und komm dann zurück.

Das Problem

Die meisten Einsteiger kleben eine App zusammen, indem sie kopieren, was ein Tutorial getan hat, ohne ein Modell davon, wie die Teile zusammenhängen. Dann stossen sie an eine Wand: die Marketing-Seite ist langsam, weil sie mit der ganzen App gebündelt ist, Auth und Daten sind in die UI verstrickt, und niemand kann sagen, wo eine bestimmte Verantwortung lebt. Das Ergebnis ist eine App, die schwer zu ändern und unmöglich zu durchdenken ist. Nichts davon ist ein Problem der Coding-Kompetenz. Es ist ein fehlendes mentales Modell. Diese Lektion installiert das Modell, damit dein Agent auf festem Boden baut statt auf einem Haufen kopierter Snippets.

Die drei Schichten: Frontend, Backend, Datenbank

Jede Web-App, egal wie schick, sind drei Schichten, die sich die Arbeit zureichen. Das Frontend ist das, was im Browser läuft: das HTML, CSS und JavaScript, das den Bildschirm zeichnet und auf Klicks reagiert. Das Backend ist der Code, der auf einem Server läuft, fern vom Nutzer, wo du Logik und Secrets ablegst, die der Browser nicht sehen soll. Die Datenbank ist, wo Daten dauerhaft leben, sodass sie einen Seiten-Refresh überleben und zwischen Nutzern geteilt werden. Ein Request fliesst einen Weg und zurück: der Browser bittet das Backend um etwas, das Backend liest oder schreibt die Datenbank und schickt eine Antwort, die der Browser rendert. Die meiste Verwirrung darüber, "wohin gehört dieser Code", löst sich in dem Moment auf, in dem du benennen kannst, welcher dieser drei Schichten ein Stück Arbeit gehört.

• Frontend: läuft im Browser, zeichnet die UI, hält nie Secrets, jeder kann es lesen.
• Backend: läuft auf einem Server, hält Geschäftslogik und API-Keys, redet mit der Datenbank.
• Datenbank: speichert Daten dauerhaft und teilt sie über Nutzer und Sessions hinweg.
• Goldene Regel: ein Secret (API-Key, Passwort) gehört ins Backend, nie in Frontend-Code, denn der Browser liefert seinen Code an jeden Besucher aus.

Was ein Framework dir gibt

Ein Framework gibt dir Struktur, Routing und Konventionen, sodass du keine App aus rohen Dateien zusammenbaust. Es entscheidet, wie URLs auf Seiten abgebildet werden, wie Seiten Daten holen, wie die App gebündelt und ausgeliefert wird, und hundert kleine Dinge, die du sonst neu erfinden würdest. Die 2026er Optionen neigen jeweils in eine andere Richtung, und die richtige Wahl hängt davon ab, wie viel deines Produkts Content versus App ist.

• Astro: gebaut für schnelle, content-lastige Seiten - Blogs, Docs, Marketing-Seiten. Liefert standardmässig fast kein JavaScript aus, sodass Seiten schnell laden und gut ranken. Greif dazu, wenn der Grossteil deines Produkts Content ist.
• Next.js: das Schwergewicht-React-Framework für reichhaltige, interaktive Apps. Riesiges Ökosystem, Server-Rendering und die Voreinstellung, die viele Teams für eine vollwertige Produkt-App wählen.
• TanStack Start: ein neueres Full-Stack-React-Framework, gebaut auf TanStack Router, mit ausgezeichneter Typsicherheit und einem leichteren, transparenteren Gefühl. Genau diese Plattform läuft auf TanStack Start.
• Vue (mit Nuxt): die wichtigste Alternative zu React. Gleicher Job, andere Syntax und Philosophie. Wähl es, wenn du oder dein Team schon in Vue denken.

Du musst nicht alle vier meistern. Wähl ein App-Framework und ein Content-Framework und bleib dabei. Eine häufige, vernünftige Kombination ist Astro für die Marketing-Seite und ein React-Framework (Next.js oder TanStack Start) für die App. Die genauen Namen zählen weniger als das Verstehen der Achse: content-schnell versus app-reich.

Der Marketing-Seite-versus-App-Split

Hier ist das Muster, das Einsteiger verwirrt, bis es jemand benennt: ernsthafte Produkte betreiben ihre öffentliche Marketing-Seite und ihre eingeloggte App als zwei separate Dinge, oft auf zwei Subdomains. Schau dir Clerk und Convex selbst an - die Homepage auf der nackten Domain ist eine schnelle Marketing-Seite, und das Dashboard lebt unter einer separaten Adresse. Es ist nicht dieselbe Codebasis, die beide bedient. Der Grund ist, dass die beiden Oberflächen entgegengesetzte Bedürfnisse haben. Öffentliche Marketing-Seiten müssen blitzschnell und voll indexierbar von Google und KI-Crawlern sein, denn so wirst du gefunden. Die eingeloggte App darf schwerer und reich interaktiv sein, denn dann ist der Nutzer schon angekommen und eingeloggt, und SEO zählt nicht mehr. Sie zusammenzubündeln erzwingt einen schlechten Kompromiss: entweder zieht deine Marketing-Seite die ganze App mit und lädt langsam, oder deine App wird von Marketing-Seiten-Constraints ausgebremst. Sie zu trennen lässt jede für ihren echten Job optimieren.

• Marketing-Seite: nackte Domain (yoursite.com), schnell, SEO- und GEO-optimiert, oft Astro. Ihr Job ist, gefunden zu werden und Besucher zu konvertieren.
• App: eine Subdomain (app.yoursite.com), schwerer, interaktiv, hinter Auth. Ihr Job ist, das Produkt zu liefern. SEO zählt hier nicht.
• Auth und Dashboards (Clerk) und deine Datenbank (Convex) leben auf der App-Seite, nie in die Marketing-Seiten gebündelt.
• Dieser Split ist der Grund, warum deine Homepage 100 auf Lighthouse erreichen kann, während deine App eine reiche, zustandsbehaftete React-Erfahrung ist.

Was ein Monorepo ist und wann es hilft

Ein Monorepo ist ein einzelnes Git-Repository, das mehrere verwandte Projekte hält - sagen wir deine Marketing-Seite, deine App und ein geteiltes Paket an Komponenten - statt eines Repos pro Projekt. Der Reiz ist echt: du teilst Code (Typen, UI-Komponenten, Utilities) über Oberflächen hinweg, ohne Pakete zu veröffentlichen, und ein Pull Request kann alles ändern, was zusammen geändert werden muss. Die Kosten sind ebenfalls echt: Monorepos fügen Tooling-Overhead hinzu (Workspace-Manager, komplexere Builds, langsamere CI, wenn du nachlässig bist), den ein Solo-Einsteiger am ersten Tag nicht braucht. Die ehrliche Regel: greif zu einem Monorepo, wenn du wirklich bedeutsamen Code über zwei oder mehr Oberflächen teilst und die Duplizierung dir wehtut. Bis dahin sind separate Repos einfacher und völlig in Ordnung. Übernimm kein Monorepo, weil eine grosse Firma es tut - die haben Hunderte Engineers und du hast einen Agent und einen Laptop.

• Monorepo: ein Repo, viele Projekte, geteilter Code, koordinierte Änderungen.
• Lohnt sich, wenn: Marketing-Seite und App Typen oder Komponenten teilen und du sie oft zusammen änderst.
• Überspring es, wenn: du eine einzelne App hast oder zwei Oberflächen, die kaum Code teilen. Der Overhead ist nicht gratis.
• Du kannst immer mit separaten Repos starten und später in ein Monorepo zusammenführen, wenn der Schmerz echt ist.

Typische Fehler

Die wiederkehrenden Fehler in dieser Phase: Marketing-Seite und App in ein Projekt bündeln und sich dann wundern, warum die Homepage langsam ist und SEO leidet; einen geheimen API-Key in Frontend-Code legen, wo jeder Besucher ihn lesen kann; am ersten Tag ein Monorepo übernehmen, weil es professionell aussieht, und in Build-Konfiguration ertrinken; und ein Framework nach Hype wählen statt danach, ob dein Produkt content-lastig oder app-lastig ist. Jeder davon kommt daher, das mentale Modell zu überspringen. Benenne die Schicht, benenne die Oberfläche, und die richtige Struktur folgt.

Business-ROI

Architektur, die am Anfang gut entschieden wird, ist nahezu gratis; schlecht entschieden besteuert sie jede künftige Änderung. Ein sauberer Marketing-versus-App-Split heisst, deine Homepage bleibt schnell und wird gefunden, was die Spitze deines ganzen Funnels ist - langsame Marketing-Seiten kosten dich für immer still Kunden und Suchranking. Zu wissen, welche Schicht welche Verantwortung besitzt, heisst, dass du (und dein Agent) Features shippst, ohne Verstrickungen zu schaffen, die später teure Umschreibungen brauchen. Die Gründer, die sich am schnellsten bewegen, sind nicht die, die das trendigste Framework gewählt haben; es sind die, deren Architektur ihnen erlaubt, eine Sache zu ändern, ohne drei andere zu brechen.

Checkliste

Bevor du weitergehst, stell sicher, dass du diese ohne Zurückblättern beantworten kannst. Diese Karte liegt unter jeder anderen Lektion im Kurs.

• Kannst du Frontend, Backend und Datenbank erklären und welche davon Secrets hält?
• Kannst du sagen, wann du Astro versus Next.js oder TanStack Start wählst?
• Kannst du erklären, warum Teams die Marketing-Seite von der App trennen?
• Kannst du die ehrliche Regel nennen, wann sich ein Monorepo lohnt?

Ressourcen

Halt die offiziellen Docs für deine gewählten Frameworks als Lesezeichen - Astro, Next.js, TanStack Start und Nuxt haben alle ausgezeichnete Getting-Started-Guides. Die Grundlagen-Seiten dazu, was ein Framework ist und was TypeScript ist, untermauern diese Lektion, falls ein Konzept unscharf blieb. Die nächsten drei Lektionen füllen die drei Schichten eine nach der anderen: Auth, dann Daten, dann die Secrets, die sie verbinden.

Deine Aufgabe

Skizziere dein eigenes Produkt (oder ein Produkt, das du bewunderst) als Diagramm mit drei Boxen - Frontend, Backend, Datenbank - und einem Pfeil, der einen Request durch sie hindurch fliessen zeigt. Markiere dann, welche Teile die Marketing-Seite und welche die App sind. Fünf Minuten mit einem Stift machen den Rest dieses Kurses konkret, denn du hast jetzt eine echte Form, an die du jedes neue Teil hängst.

Nächste Lektion

Mit klarer Architektur fügt die nächste Lektion den ersten echten Baustein hinzu: Authentifizierung mit Clerk, inklusive was OAuth tatsächlich ist, warum du Auth nie selbst bauen darfst und ein vollständiger Google-OAuth-Durchgang von einer Development-Instanz zur Produktion.