Der App Router kam für mich zu früh

Im Oktober erschien Next.js 13 mit dem App Router — einem neuen Routing-Modell mit Serverkomponenten, verschachtelten Layouts und einer anderen Art, Daten zu laden. Ich habe sofort angefangen, mein Dashboard umzubauen.

Zwei Wochen später habe ich den Umbau in einem Zweig geparkt und bin beim alten Modell geblieben. Das war die richtige Entscheidung, und der Weg dorthin war lehrreich.

Was daran verlockend war

Die Grundidee ist gut, und ich halte sie bis heute für richtig: Komponenten laufen standardmäßig auf dem Server. Sie holen ihre Daten selbst, direkt, ohne einen Umweg über eine eigene Schnittstelle.

// Serverkomponente: läuft nur auf dem Server
export default async function ServerListe() {
  const server = await db.guild.findMany({ where: { aktiv: true } });
  return <Liste eintraege={server} />;
}

Für ein Dashboard ist das genau das richtige Modell. Ich hatte vorher für fast jede Ansicht eine eigene API-Route, die Daten holte, und eine Komponente, die sie abrief — zwei Stellen für eine Sache, mit Ladezuständen, Fehlerbehandlung und Typen an beiden Enden.

Woran es im Herbst 2022 gescheitert ist

Die Bibliotheken waren nicht so weit. Meine Anmeldung, meine Komponentensammlung und mehrere kleinere Pakete gingen davon aus, dass alles im Browser läuft. Jede zweite Datei brauchte eine Kennzeichnung als Clientkomponente — und wenn die an der falschen Stelle steht, zieht sie den halben Baum mit auf die Clientseite und man hat nichts gewonnen.

Die Fehlermeldungen waren unbrauchbar. Der Klassiker der ersten Wochen war eine Meldung über eine nicht serialisierbare Eigenschaft, die einen zu einer Komponente führte, die mit dem eigentlichen Problem nichts zu tun hatte. Ich habe an manchen Tagen mehr Zeit mit dem Verstehen von Fehlern verbracht als mit der Umstellung.

Das Zwischenspeicherverhalten war überraschend. In der neuen Welt wird aggressiv zwischengespeichert, an mehreren Ebenen gleichzeitig. Für ein Dashboard, in dem jemand eine Einstellung ändert und sofort das Ergebnis sehen will, ist das ein echtes Problem — und die Regeln dafür haben sich in den Folgeversionen mehrfach geändert.

Es war noch keine Empfehlung. Die Dokumentation selbst bezeichnete den App Router zu diesem Zeitpunkt als noch nicht für die produktive Nutzung fertig. Ich hatte das gelesen und in der Begeisterung überlesen.

Der Moment des Zurückruderns

Ausschlaggebend war ein Nachmittag, an dem ich einen Fehler in der Anmeldung untersucht habe. Nach drei Stunden stand fest: Es lag nicht an meinem Code, sondern an einem bekannten offenen Problem in einer Bibliothek, das auf eine Anpassung wartete.

Da habe ich mir eine Frage gestellt, die ich mir seitdem öfter stelle: Wie viel meiner Zeit fließt gerade in mein Projekt, und wie viel in das Ökosystem drumherum?

Die Antwort war deutlich. Ich habe den Zweig stehen gelassen, bin zurück, und habe die Umstellung anderthalb Jahre später gemacht — als die Bibliotheken nachgezogen hatten, die Fehlermeldungen besser waren und Anleitungen für die typischen Fälle existierten. Sie hat dann ein Wochenende gedauert.

Tipp

Der Punkt ist nicht „warte immer ab". Frühe Umstiege können sich lohnen, wenn man ein Problem hat, das die neue Technik löst. Der Punkt ist, ehrlich zu sein, welches Problem man löst. Bei mir war die Antwort: keines. Mein Dashboard funktionierte. Ich wollte die neue Sache benutzen, weil sie neu war — und das ist ein legitimer Grund für ein Nebenprojekt, aber kein guter für ein System, das andere benutzen.

Was ich mir daraus gebaut habe

Ich habe mir angewöhnt, vor einem größeren Umbau drei Fragen zu beantworten und die Antworten aufzuschreiben:

Welches konkrete Problem löst das? Nicht „es ist moderner", sondern ein Problem, das ich benennen kann.
Was passiert, wenn ich es ein Jahr später mache? Wird es teurer, gleich teuer oder billiger? Bei neuen Frameworkfassungen wird es meistens billiger, weil andere die Kinderkrankheiten finden.
Wie komme ich zurück, wenn es nicht klappt? Bei mir: ein Zweig, den ich nicht zusammenführe, und die Regel, dass die alte Fassung bis zum Ende lauffähig bleibt.

Diese drei Fragen haben mich seitdem vor mindestens zwei größeren Fehlentscheidungen bewahrt — und sie haben mich in anderen Fällen bestärkt, es doch zu tun. Sie sind kein Bremsmechanismus, sondern eine Zwangspause zum Nachdenken.

Was ich beim zweiten Anlauf anders gemacht habe

Anderthalb Jahre später habe ich die Umstellung dann tatsächlich gemacht, und sie hat ein Wochenende gedauert statt zwei Wochen. Der Unterschied lag nicht nur an der gereiften Technik.

Ich habe mit dem einfachsten Bereich angefangen, nicht mit dem wichtigsten. Statische Seiten zuerst — dort gibt es keine Anmeldung, keine Formulare, keinen Zustand. Damit lernt man das Modell, ohne dass etwas kaputtgehen kann.

Ich habe beide Modelle parallel laufen lassen. Das Framework kann das, und es nimmt der Umstellung jeden Zeitdruck.

Ich habe zuerst geprüft, ob meine Abhängigkeiten mitspielen. Eine halbe Stunde Recherche pro Paket, bevor eine Zeile geändert wurde. Beim ersten Versuch hatte ich das nicht gemacht und bin genau darüber gestolpert.

Ich hatte ein Abbruchkriterium. Vorher aufgeschrieben: Wenn ich nach zwei Tagen mehr Zeit mit Bibliotheksproblemen verbringe als mit meinem Code, breche ich ab. Es kam nicht dazu — aber die Existenz dieses Kriteriums hat den Unterschied zwischen ausprobieren und verrennen gemacht.

Was ich über neue Technik gelernt habe

Es gibt einen Zeitpunkt, zu dem eine neue Technik den größten Nutzen bringt, und der liegt weder ganz vorne noch ganz hinten.

Zu früh heißt: Man ist Testperson. Man findet Fehler, die noch niemand gefunden hat, und man löst Probleme, die in sechs Monaten von selbst weg sind. Für ein Nebenprojekt kann das reizvoll sein, für ein System mit Nutzern ist es teuer.

Zu spät heißt: Man steht vor einem Sprung über mehrere Versionen, mit überlagerten Änderungen und ohne Hilfe, weil alle anderen längst umgestiegen sind.

Der gute Zeitpunkt liegt dort, wo die ersten Anleitungen für die typischen Probleme existieren und die Bibliotheken nachgezogen haben. Erkennbar ist er daran, dass man Fragen stellen kann und Antworten findet, die nicht aus Vermutungen bestehen.

Was ich mitnehme

Der interessanteste Nebeneffekt war, dass ich die neue Technik durch den abgebrochenen Versuch trotzdem gelernt habe. Als ich anderthalb Jahre später ernsthaft umgestellt habe, war nichts davon neu. Ich wusste, wo die Grenzen zwischen Server und Client verlaufen, und wo man Ladezustände braucht.

Ein abgebrochener Umbau ist keine verlorene Zeit, wenn man den Abbruch als Entscheidung behandelt und nicht als Scheitern.