Case Study // Product
Meine eigene Seite: Next.js mit einem geschriebenen Cache-Vertrag
Die Seite, die du gerade liest. Next.js mit Payload im Rücken, einem durchgeschriebenen Cache-Vertrag und einer 404, die auch ohne Datenbank funktioniert.
- Next.js 16
- Payload 4
- TypeScript
- Tailwind 4
- Docker
01Ausgangslage
Ich wollte eine Seite, die meine Arbeit zeigt, ohne dass ich sie jedes Mal in HTML tippe. Also ein CMS, das mir nicht im Weg steht, und ein Frontend, das schnell bleibt, auch wenn niemand mehr hinschaut.
02Wie es gebaut ist
Inhalte liegen im CMS, gerendert wird über eine gecachte Datenschicht. Jeder öffentliche Read läuft durch eine eigene Cache-Funktion mit Tags, ein Publish stößt die betroffenen Routen an und purgt genau die betroffenen Edge-Objekte.
Die Cache-Regeln habe ich aufgeschrieben, statt sie zu erraten: wie lange eine Seite fresh bleibt, wie lange sie bei einem Origin-Ausfall noch ausgeliefert wird, welche Pfade nie gecacht werden. Nach jeder Änderung messe ich den Status am echten Host nach.
Die 404-Entscheidung fällt im Proxy, bevor der erste Byte streamt. Next hätte den Status sonst auf 200 festgenagelt, sobald die Shell streamt – das war messbar und ist heute ein Test.
Vor jedem Merge laufen Lint, Typecheck in zwei TypeScript-Versionen, Tests und ein Build; danach ein Smoke-Test gegen den Standalone-Server. Das steht nicht nur in meinem Kopf, sondern in einer Datei im Repo.
03Was ich gelernt habe
Der teuerste Fehler war ein stummer: ein 404, der am Edge dreißig Tage gecacht wurde und damit einen Ausfall überlebte. Seitdem sind alle Fehlerantworten auf no-store, und die Regel steht im Regelwerk, damit sie nicht wieder verschwindet.
04Ergebnis
118 Integrationstests grün, 14 Blöcke, ein Edge-Cache, der nach einem Publish messbar neu befüllt wird.