Har bygget Next.js 16‑frontenden: SSR, SSG og CSR

Situation. Det autentificerede dashboard skulle føles hurtigt og samtidig være reelt interaktivt, og de to mål trækker i hver sin retning, hvis man griber det naivt an. Henter man alt på klienten, bliver den første indlæsning langsom, og værre endnu får man N+1‑mønsteret, hvor hver komponent vågner og sender sin egen request af sted, så en enkelt side bliver til en kaskade af rundture.

Opgave. Hver del af appen skulle renderes på den måde, der faktisk passede til den, uden at opgive interaktiviteten på klientsiden, hvor den betød noget.

Handling. Next.js 16‑frontenden bruger den rette renderingsform til hver del i stedet for ét fælles valg. Marketingsider og offentlige sider genereres statisk — de ændrer sig ikke fra bruger til bruger, så der er ingen grund til at rendere dem ved hver request. De reelt interaktive dele renderes fortsat på klienten. Og der, hvor N+1‑kaskaden for alvor gør ondt — det autentificerede dashboard og de store oversigtslister — blev løsningen samlet i en factory i stedet for at blive håndkodet hver gang: createPrefetchedServerPage henter sidens data på serveren og giver dem videre til klienten, allerede udfyldt, så komponenterne starter med deres data i stedet for hver især at skulle spørge efter dem. En strategi for cache‑invalidering er dokumenteret for hver forespørgsel, så dataene forbliver friske, uden at appen henter ting igen, som den allerede har.

Resultat. De sider, der er flyttet over på denne factory, indlæses med én rundtur i stedet for en hel storm af dem, og fordi det er en factory og ikke et mønster, folk kopierer i hånden, arver den næste side, der flyttes over, opførslen gratis. Resten af den autentificerede app renderes stadig på klienten og venter på sin tur bag den — en migrering med en fungerende mekanisme og en oplagt næste side, ikke en afsluttet gennemgang.