Produktionsreife und Deployment

Produktionsreife und Deployment

0:00 Jetzt bringen wir die Anwendung nach draußen. Dieses Modul hat einen roten Faden, der sich durch alle Kapitel zieht: Vieles, was auf der eigenen Maschine funktioniert, funktioniert dort noch lange nicht — und zwar aus Gründen, die man vorher nicht sieht. Wir ordnen zuerst die gewachsene Struktur, messen dann, was tatsächlich im Browser landet, richten Messbarkeit ein und gehen am Ende zwei Wege nach draußen.

0:22 Der erste ist die native Plattform, der zweite ein Container, den ein Betriebsteam betreiben kann. Das ist mir wichtig: Dies ist ausdrücklich kein Kurs für eine einzige Plattform.

Projekt- und Komponentenarchitektur

0:33 Bevor wir ausliefern, räumen wir auf. Nach zwölf Modulen ist aus dem leeren Projekt eine gewachsene Anwendung geworden, und gewachsene Anwendungen haben Stellen, an denen niemand mehr findet, was er sucht. Ich möchte dafür keine Idealstruktur vorgeben, sondern eine einzige Leitfrage — die hat sich in der Praxis als brauchbarer erwiesen als jedes Schema.

0:54 Die Leitfrage lautet: Findet eine neue Entwicklerin ohne Rückfrage, wo ein neues Feature hingehört? Das ist bewusst nicht ästhetisch formuliert. Eine Struktur ist nicht dann gut, wenn sie einem Muster entspricht, sondern wenn sie eine zuverlässige Antwort auf diese Frage gibt. Wir gehen die vier Bereiche durch, die sich im Laufe des Seminars ergeben haben — Routen, Zugriffs-Layer, geteilte Komponenten, fachliche Module — und prüfen, ob die Zuordnung eindeutig ist.

1:21 Wo sie es nicht ist, sortieren wir um. Der Satz unter der Tabelle ist die eigentliche Botschaft: Fachlich Zusammengehöriges bleibt beieinander, auch wenn es Dateitypen mischt. Das widerspricht der Gewohnheit vieler Teams, die nach Typ sortieren — alle Komponenten hierhin, alle Tests dorthin. Wir haben in Modul eins gesehen, dass der App Router das gar nicht verlangt.

1:42 Die zweite Zeile ist die wichtigste des ganzen Projekts, und sie steht jetzt zu Recht als eigener Bereich da: der Zugriffs-Layer, serverseitig festgenagelt, mit den Rechteprüfungen darin. Der erste Punkt ist meine Begründung dafür, dass dieses Kapitel hier steht und nicht in Modul eins: Am Anfang ist jede Struktur plausibel, weil noch nichts weh tut.

2:02 Man kann sich stundenlang über Ordnernamen unterhalten, ohne dass die Diskussion Substanz hätte. Nach zwölf Modulen sehen Sie dagegen, wo Sie tatsächlich gesucht haben und wo Sie zweimal hinschauen mussten. Das ist eine belastbare Grundlage. Und der dritte Punkt ist die Rechnung: Eine Umsortierung jetzt ist billig, in einem Jahr ist sie eine Migration mit Konflikten in jedem offenen Zweig.

Bundle-Analyse und Performance

2:24 Jetzt messen wir, was tatsächlich im Browser landet. Das ist der Moment, in dem sich zeigt, ob die Entscheidungen aus Modul vier getragen haben — und in dem fast jedes Projekt zwei sehr ähnliche Funde macht. Ich verrate Ihnen die beiden gleich, damit Sie gezielt danach suchen können. Die Bundle-Analyse zeigt Ihnen, welche Module wie viel Platz beanspruchen — als Karte, in der große Flächen große Pakete sind. Zwei Funde macht fast jedes Projekt.

2:50 Der eine ist eine Client-Grenze, die zu weit oben gesetzt wurde und deshalb halbe Seiten in den Browser zieht. Der andere ist eine schwere Bibliothek, die nur eine einzige Komponente braucht — oft eine Datumsformatierung oder ein Diagramm. Beides ist gut behebbar, und beides finden Sie nur, wenn Sie hinsehen. Der rote Faden dieser fünf Schritte ist: nicht raten, sondern nachsehen.

3:14 Schritt zwei ist der wichtigste und der, den man überspringt — man sieht ein großes Paket und denkt sofort über einen Austausch nach. Fragen Sie zuerst, welche Grenze es überhaupt hereinzieht. Sehr oft ist die Bibliothek gar nicht das Problem, sondern ihr Ort. Und Schritt fünf ist die Disziplin, die den Unterschied macht: erneut messen. Ich habe schon Optimierungen gesehen, die das Bundle vergrößert haben, weil niemand nachgeprüft hat.

3:40 Hier schließt sich der Kreis zu Modul vier. Alles, was eine Client-Datei importiert, wandert ins Bundle — und eine Direktive an der Seite zieht damit die halbe Route mit. Das war dort eine abstrakte Warnung, hier ist es eine Zahl. Sehen Sie sich Ihren Belegungsplan an: Wenn die Grenze am Filter sitzt, sind es vielleicht zehn Kilobyte.

3:59 Wenn sie an der Seite sitzt, können es dreihundert sein. Der dritte Punkt nennt den zweiten Hebel: Selten geöffnete große Komponenten wie ein Belegungskalender müssen nicht beim ersten Aufruf mitgeladen werden. Der zweite Punkt ist ein häufiger Fehlschlag beim Optimieren: Nachladen an der falschen Stelle erzeugt sichtbares Nachrucken.

4:19 Sie haben Kilobyte gespart und dafür ein Layout, das springt — was der Nutzer stärker wahrnimmt als eine halbe Sekunde Ladezeit. Der dritte Punkt ist eine Messregel, die man kennen muss: Was im Entwicklungsmodus gemessen wird, sagt nichts über die Produktion. Dort sind Module unkomprimiert, Werkzeuge aktiv und Optimierungen abgeschaltet. Messen Sie immer am gebauten Stand.

Bilder und Schriften optimieren

4:42 Jetzt zwei Bausteine, die Next.js mitbringt und die man einfach benutzen sollte. Der eine spart Bandbreite, der andere ebenfalls — und hat zusätzlich eine Eigenschaft, die in Deutschland regelmäßig übersehen wird und rechtlich relevant ist. Ich sage gleich, welche, denn sie hat schon Abmahnungen ausgelöst. Die Bild-Komponente liefert passende Größen und moderne Formate aus und reserviert den Platz im Layout, damit beim Laden nichts springt.

5:08 Die Schrift- Einbindung von Next.js lädt Schriften aus Ihrem eigenen Auftritt aus, statt sie von einem fremden Host zu holen. Beides klingt nach Optimierung, und beim zweiten ist das nur die halbe Wahrheit. Es ist auch eine Datenschutzentscheidung — und zwar eine, die schon Gerichte beschäftigt hat. Der Ablauf ist unscheinbar: Eine Schrift von einem fremden Auslieferungsnetz wird beim Seitenaufruf geladen.

5:31 Dabei überträgt der Browser die IP-Adresse der Besucherin dorthin — bevor irgendjemand einer Verarbeitung zugestimmt hat, ja bevor die Seite überhaupt fertig ist. In Deutschland gab es dazu Urteile, und es gab eine Welle von Abmahnungen. Der Punkt ist: Sie brauchen das nicht. Die Selbstauslieferung löst das Problem vollständig, ist obendrein schneller, und Next.js macht sie zum Standardweg.

5:54 Es gibt hier schlicht keinen Grund für die schlechtere Variante. Drei Bausteine, und der Satz unter der Tabelle ist mir wichtig: Alle drei sind Standard, keine Zusatzpakete. Sie müssen nichts installieren und nichts auswählen. Der dritte, für fremde Skripte, ist der am wenigsten bekannte und lohnt einen Blick — er sorgt dafür, dass ein eingebundenes Analysewerkzeug nicht das Rendern der Seite aufhält.

6:17 Meine Einschätzung: Wenn ein Framework solche Bausteine mitbringt und sie benutzt werden können, ohne etwas dazuzulernen, dann gibt es keinen guten Grund, sie nicht zu verwenden. Der zweite Punkt ist der häufigste Anwendungsfehler: Ohne Angabe von Breite und Höhe springt das Layout trotz der Bild-Komponente. Der Baustein kann den Platz nur reservieren, wenn er weiß, wie viel.

6:39 Der erste Punkt ist einer für den Betrieb und passt zum letzten Kapitel dieses Moduls: Beim Selbsthosten auf bestimmten Linux-Systemen kann die Bildoptimierung zusätzliche Einstellungen brauchen, sonst wächst der Speicherverbrauch. Das ist so ein Detail, das lokal nie auftritt und im Container Rätsel aufgibt.

Metadaten und Suchmaschinen

6:56 Ein kurzes Kapitel über die Frage, wie Ihre Seiten außerhalb Ihrer Anwendung aussehen — in Suchergebnissen, in geteilten Links, in Vorschauen. Next.js macht das angenehm einfach, und es gibt eine Verbindung zum Caching-Modell, die man kennen muss, weil sie sonst überrascht. Eine Funktion erzeugt Titel und Beschreibung aus den Daten der Route — für jeden Liegeplatz also seinen eigenen Titel, nicht einen allgemeinen.

7:21 Dateikonventionen liefern zusätzlich Sitemap, Robots-Datei und Vorschaubilder. Und hier der Punkt, der überrascht: Mit dem Caching-Modell aus Modul sechs gelten in dieser Funktion dieselben Regeln wie in der Seite. Ein ungecachter Zugriff blockiert also auch von hier aus. Das ist konsequent, aber man denkt nicht daran, weil Metadaten sich nicht wie Rendern anfühlen.

7:43 Sieben Zeilen für einen echten Gewinn: Jede Seite bekommt ihren eigenen Titel und ihre eigene Beschreibung, aus den Daten erzeugt. Worauf es ankommt, steht in der Fußnote — der Datenzugriff hier zählt wie einer in der Seite. Wenn Sie also die Hafendaten hier ungecacht holen und dieselben Daten in der Seite noch einmal, haben Sie zwei blockierende Zugriffe statt keinem.

8:04 Die Merkfunktion aus Modul fünf löst das übrigens elegant: Beide Aufrufe teilen sich ein Ergebnis. Der erste Punkt ist der häufigste und wirkt sich unmittelbar aus: Jede Seite braucht eine eigene Beschreibung. Sonst tragen alle Modulseiten denselben Text — und das ist ausgerechnet bei der größten Seitengruppe der Fall. Der zweite Punkt klingt selbstverständlich und wird trotzdem vergessen: Der geschützte Bereich gehört nicht in die Sitemap.

8:30 Und der dritte ist eine Regel, die ich für wichtig halte: Strukturierte Daten dürfen nur behaupten, was auf der Seite auch steht. Falsche Angaben kosten die Berechtigung für die erweiterten Darstellungen.

Logging, Instrumentation und OpenTelemetry

8:42 Jetzt zu einem Thema, das man am liebsten verschiebt, bis man es braucht — und dann ist es zu spät. Es geht um Sicht auf die laufende Anwendung. Ich möchte Ihnen das nicht als Pflichtübung verkaufen, sondern mit einer einfachen Beobachtung: Ohne diese Sicht ist Fehlersuche in Produktion Raten. Mit ihr ist sie eine Frage von Minuten.

9:02 Es gibt eine Datei, die beim Serverstart läuft — der Ort für Fehlermeldedienste und für Tracing. Über einen offenen Standard lassen sich dabei Zeitspannen exportieren, sodass sichtbar wird, welche Abfrage eine langsame Seite verursacht. Stellen Sie sich das vor wie einen Fahrtenschreiber: Ohne ihn wissen Sie, dass die Fahrt lange dauerte.

9:21 Mit ihm wissen Sie, dass zwanzig Minuten davon an einer bestimmten Kreuzung standen. Erst das eine ermöglicht eine gezielte Verbesserung. Der erste Punkt ist die Erfahrung, die jeder einmal macht: Im Vorfall selbst fehlt die Zeit, Messpunkte nachzurüsten. Die Anwendung ist langsam, das Telefon klingelt, und Sie beginnen, Protokollausgaben einzubauen und neu auszurollen. Das kostet Stunden, die Sie nicht haben.

9:46 Der dritte Punkt ist der, an den man gar nicht denkt: Ohne Fehlermeldedienst erreichen Fehler aus Produktion niemanden. Sie stehen in einem Protokoll, das keiner liest. Und der vierte Punkt ist die Rechnung — das alles ist eine Datei und eine Abhängigkeit. Fünf Zeilen, und die Bedingung darin ist der interessante Teil. Sie unterscheidet nach Laufzeitumgebung, denn nicht jeder Teil Ihrer Anwendung läuft in derselben.

10:11 Ohne diese Unterscheidung importieren Sie Werkzeuge an einem Ort, an dem sie nicht laufen können — und bekommen einen Fehler beim Start, der zunächst unverständlich ist. Worauf es ankommt: Diese Datei ist der einzige Ort, an dem Code beim Serverstart läuft. Wenn Sie irgendetwas einmalig initialisieren müssen, ist das die Stelle.

10:31 Der erste Punkt ist einer, den man in einem Portal mit Kundendaten ernst nehmen muss: Traces mit personenbezogenen Daten sind selbst ein Datenschutzproblem. Wenn Sie den Namen des Gastes oder die Buchungsnummer in jede Zeitspanne schreiben, haben Sie personenbezogene Daten bei Ihrem Auswertungsanbieter — und der ist womöglich nicht Teil Ihrer Datenschutzerklärung.

10:51 Der zweite Punkt ist eine Kostenfrage, die real ist: Zu viele Messpunkte erzeugen Rechnungen ohne Erkenntnisgewinn. Weniger und gezielter ist hier tatsächlich besser.

Deployment auf Vercel

11:00 Jetzt der erste der beiden Wege nach draußen: die native Plattform. Ich gehe ihn mit Ihnen einmal durch, und zwar mit einem bestimmten Ziel. Sie sollen nämlich sehen, was dabei automatisch passiert — denn genau das ist die Aufgabenliste für das letzte Kapitel, in dem wir selbst hosten. Vercel, die native Plattform des Herstellers, nimmt Ihnen viel ab: Vorschau- Auslieferungen für jeden Zweig, die statische Hülle am Auslieferungsnetz, verwaltete Caches, die Regeneration im Hintergrund.

11:29 Sie verbinden das Repository, setzen die Umgebungsvariablen, richten die Domäne ein — fertig. Das ist beeindruckend komfortabel, und ich sage das ohne Ironie. Die Frage, die Sie sich stellen sollten, ist eine andere: Was genau übernimmt die Plattform, und was müssten Sie selbst bauen, wenn Sie woanders betreiben? Genau darum geht es in dieser Tabelle: Links steht, was automatisch passiert, rechts, was das im Selbstbau bedeutet.

11:55 Diese rechte Spalte ist die Aufgabenliste für das nächste Kapitel — und sie ist überschaubar, aber sie ist nicht leer. Der Skew-Schutz in der letzten Zeile ist der Punkt, den kaum jemand auf dem Schirm hat: Während eines Rollouts laufen zwei Versionen gleichzeitig, und ein Browser mit alten Dateien kann auf einen Server mit neuen treffen.

12:14 Die Plattform löst das. Sie selbst müssen es lösen. Der erste Punkt ist ein Fehler, den ich häufiger sehe, als mir lieb ist: eine Vorschau-Auslieferung, die mit Produktionsdaten läuft. Das ist bequem, weil man echte Daten sieht — und es bedeutet, dass jeder Zweig, jeder Testcode und jeder halbfertige Umbau auf echten Kundendaten arbeitet.

12:34 Der dritte Punkt ist mein eigentliches Anliegen für dieses Modul: Wer nur diesen einen Weg kennt, kann die Plattform später nicht verlassen. Nicht weil es technisch unmöglich wäre, sondern weil niemand weiß, was dann alles fehlt.

Selbsthosten mit Node.js und Docker

12:47 Und damit zum zweiten Weg. Das ist mir der wichtigere von beiden, denn er macht aus diesem Seminar ausdrücklich keinen Plattform-Kurs. Am Ende soll das Portal in einem Container laufen, den ein Betriebsteam betreiben kann. Es gibt dabei genau fünf Dinge, die Sie selbst klären müssen — und alle fünf treten erst mit der zweiten Instanz auf.

13:07 Next.js kann ein schlankes Artefakt erzeugen, das nur die tatsächlich benötigten Teile enthält — daraus wird ein kleines Container-Abbild. So weit ist das unspektakulär. Selbst zu klären sind fünf Dinge: der Cache-Speicher, der Verschlüsselungsschlüssel für Aktionen, die Bildoptimierung, der Verbindungspool zur Datenbank und die Weitergabe des Datenstroms.

13:28 Jedes davon ist für sich überschaubar. Zusammen sind sie der Unterschied zwischen einem Container, der startet, und einem, der trägt. Der rote Faden ist eine Reihenfolge vom Bauen zum Betreiben. Schritt zwei ist der, den ich hervorheben möchte, weil er am häufigsten vergessen wird: die Pufferung des vorgeschalteten Servers abschalten.

13:48 Ohne das sammelt der Reverse-Proxy die gestreamte Antwort und liefert sie am Ende gebündelt aus — Ihr gesamtes Streaming aus Modul fünf ist damit wirkungslos. Die Seite funktioniert, sie ist nur nicht schneller. Und niemand sucht danach, weil ja alles läuft. Schritt fünf verbindet zurück zu Modul neun: Migrationen laufen vor dem Start der neuen Version.

14:09 Diese Tabelle ist die Zusammenfassung des Kapitels, und die rechte Spalte beschreibt jeweils das Symptom. Lesen Sie sie einmal von oben nach unten: Jede dieser Fehlfunktionen sieht nach etwas völlig anderem aus als nach ihrer Ursache. Ein unterschiedlicher Stand je Instanz sieht aus wie ein Cache- Fehler. Eine nicht gefundene Aktion sieht aus wie ein Bug im Code.

14:30 Und der Satz unter der Tabelle ist der wichtigste: Alle fünf treten erst mit der zweiten Instanz auf. Lokal läuft alles einwandfrei — genau deshalb sind sie so tückisch. Der erste Punkt ist eine Klarstellung, die viele erwarten: Das Caching-Modell aus Modul sechs funktioniert auch selbst gehostet. Es ist keine Plattformfunktion, und Sie geben nichts auf.

14:52 Der zweite Punkt greift den Tag- Aufruf aus Modul sechs noch einmal auf — er wirkt ohne koordinierenden Handler nur auf der eigenen Instanz. Und der dritte ist ein Betriebsdetail mit Datenverlustpotenzial: Beim Herunterfahren braucht der Server Zeit für laufende Nacharbeiten. Wer ihn hart beendet, verliert sie. In dieser Aufgabe machen Sie das, was am Ende jedes echten Projekts steht: aus einer funktionierenden Anwendung eine betreibbare machen.

15:18 Der Erfolg ist an drei Dingen festgemacht, und das mittlere ist das, was am häufigsten fehlschlägt — Streaming kommt an. Prüfen Sie das wirklich, nicht nur theoretisch. Die Notiz nimmt Ihnen Aufwand ab: Der Cache-Handler darf für die Übung ein einfacher gemeinsamer Speicher sein. Es geht um das Prinzip, nicht um eine produktionsreife Implementierung.

Modul 13 zusammengefasst

15:39 Vier Sätze zum Mitnehmen. Struktur wird daran gemessen, ob man Dinge findet. Die Client-Grenze ist der wirksamste Hebel für die Bundle-Größe. Selbstausgelieferte Schriften sind schneller und datenschutzfreundlicher — beides zugleich. Und Selbsthosten heißt, fünf Aufgaben zu übernehmen, die die Plattform sonst erledigt. Damit ist die Anwendung fertig. Im letzten Modul geht es um die Art, wie solche Anwendungen heute entstehen: mit KI-Coding- Agenten.

16:07 Und Sie werden sehen, dass alle vier typischen Fehler dieser Agenten Themen aus den Modulen davor sind.