In Next.js 16 heißt middleware.ts jetzt proxy.ts. Das klingt nach einem
Eintrag im Changelog, den man überliest — tatsächlich korrigiert die
Umbenennung ein Missverständnis, das viele Projekte teuer bezahlt haben.
Der Name war die Einladung
„Middleware” klang nach dem Ort für Anmeldung und Sitzungsverwaltung — nach der Schicht, durch die jede Anfrage muss, bevor irgendetwas passiert. Genau dorthin gehört sie ausdrücklich nicht. Proxy beschreibt, was wirklich passiert: Anfragen umlenken und anreichern.
Er läuft öfter, als du denkst
Der Proxy greift bei jeder Anfrage — auch bei jedem Prefetch. Eine Sitzungsprüfung gegen die Datenbank an dieser Stelle vervielfacht die Last also unbemerkt, und zwar genau dann, wenn Nutzer nur mit der Maus über Links fahren. Der Cookie-Blick ohne Datenbank bleibt erlaubt, ist aber nur eine optimistische Weiche: Ein Cookie kann veraltet sein, gesperrt sein, gefälscht sein.
Die Prüfung gehört an die Daten
Deshalb die Faustregel: Der Proxy ist eine Weiche, keine Wache. Nichtangemeldete auf die Anmeldung lenken, Kopfzeilen setzen, einen A-B-Test umschreiben — ja. Rechte je Datensatz entscheiden — nein. Verbindlich wird die Prüfung erst im Datenzugriffs-Layer, weil sie dort Seite, Server Action und Route Handler gleichzeitig abdeckt. Ein Endpunkt hat schließlich seine eigene URL: Niemand muss dafür die Oberfläche geöffnet haben.
Praktische Folge für den Umstieg: Ältere Beispiele im Netz heißen weiterhin
middleware, und Coding-Agenten schlagen sie aus ihrem Trainingsstand
bereitwillig vor.
Mehr dazu im Seminar
Wann eine eigene API überhaupt sinnvoll ist, wie Route Handlers ihre eigene Berechtigungsprüfung bekommen und was Next.js als Backend for Frontend leistet, steht im Modul Route Handlers und Proxy des Seminars Next.js 16 Full-Stack-Entwicklung mit React und TypeScript — inklusive Video und Kapitelübersicht.
Zum Seminar Next.js 16 Full-Stack-Entwicklung mit React und TypeScript