Har bygget Next.js 16‑frontenden med SSR-, SSG- og CSR‑strategier og et server‑shell prefetch‑and‑hydrate‑mønster, der eliminerede N+1‑fetches.
Full stack‑udvikler
Situation. Det autentificerede dashboard skulle føles hurtigt og forblive oprigtigt interaktivt, og de to mål trækker mod hinanden, hvis man er naiv omkring det. Hent alt på klienten, og førsteindlæsningen sløver, og værre endnu får man N+1‑mønsteret, hvor hver komponent vågner og fyrer sin egen request af, 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 client‑side‑interaktiviteten, hvor den betød noget.
Handling. Next.js 16‑frontenden bruger den rette tilstand pr. flade i stedet for ét fladt valg. Marketing- og offentlige sider genereres statisk — de ændrer sig ikke pr. bruger, så der er ingen grund til at rendere dem ved hver request. Autentificerede sider server‑renderes, med et server‑shell prefetch‑and‑hydrate‑mønster — createPrefetchedServerPage — der henter sidens data på serveren og overlader dem til klienten allerede udfyldt, så komponenterne kommer op med deres data i stedet for hver at gå af sted for at spørge efter dem. De oprigtigt interaktive dele forbliver client‑renderede. Og en cache‑invalideringsstrategi er dokumenteret pr. forespørgsel, så data forbliver friske, uden at appen re‑fetcher ting, den allerede har.
Resultat. Sider indlæses hurtigt og forbliver fuldt interaktive, og N+1‑stormen på dashboardet forsvandt bare, fordi server‑shellen bringer det, siden har brug for, tilbage i én omgang. Frontenden endte med den oplevede hastighed af server‑rendering og responsiviteten fra en client‑app i stedet for at skulle vælge en af dem.