Next.js: App Router, SSR og statisk eksport i produksjon

Next.js er rammeverket jeg bruker når React alene ikke er nok. Det gir deg server-side rendering, filsystem-basert routing og React Server Components — ting som gjør at du kan bygge alt fra statiske porteføljesider til komplekse fullstack-applikasjoner med samme verktøy. Jeg bruker det i to veldig forskjellige prosjekter, og det er nettopp den fleksibiliteten som gjør det verdifullt.

Hvorfor Next.js

React er et UI-bibliotek. Det gir deg komponenter og state management, men sier ingenting om routing, datahenting på serveren, eller hvordan du deployer. Next.js fyller alle disse hullene.

Filsystem-basert routing. Du lager en fil i app/-mappen, og den blir en rute. Ingen manuell konfigurasjon, ingen router-setup. For større prosjekter med mange sider sparer dette overraskende mye tid. Nested layouts i App Router gjør det enkelt å dele UI-elementer mellom sider uten å duplisere kode.

Server-side rendering og React Server Components. Komponenter kan kjøre på serveren, hente data direkte fra databasen eller et API, og sende ferdig rendret HTML til klienten. Brukeren ser innhold umiddelbart i stedet for en blank side med en spinner. Søkemotorer får faktisk innhold å indeksere.

Statisk eksport. Ikke alt trenger en server. For sider som ikke endres ofte — som en portefølje eller en blogg — kan Next.js generere statiske HTML-filer som du kan hoste hvor som helst. Ingen serverkostnader, lynrask lasting.

Slik bruker jeg det i praksis

Jeg har to Next.js-prosjekter som illustrerer bredden i rammeverket.

Nextbook er en læringsplattform med dynamisk innhold. Den bruker App Router med server components for å hente kursdata fra Supabase, rendrer sider på serveren slik at studenter får rask lasting og innholdet er søkbart. Her utnytter jeg det meste av hva Next.js tilbyr — middleware for autentisering, API-ruter for webhooks, og streaming for progressive lasting av tungt innhold.

Porteføljesiden min (ryanomar.com) bruker Next.js med statisk eksport. Bloggen du leser nå er MDX-filer som kompileres til statisk HTML ved byggtid og deployes til Firebase Hosting. Ingen server kjører — bare statiske filer bak et CDN. Resultatet er en side som laster på under et sekund og koster tilnærmet ingenting å drifte.

Server component som henter data

I Nextbook henter server components kursdata direkte uten at klienten trenger å gjøre en ekstra request:

import { createServerClient } from '@/lib/supabase/server';

async function CoursePage({ params }: { params: { slug: string } }) {
  const supabase = createServerClient();
  const { data: course } = await supabase
    .from('courses')
    .select('id, title, description, modules(id, title, order)')
    .eq('slug', params.slug)
    .single();

  if (!course) return notFound();

  return (
    <article>
      <h1>{course.title}</h1>
      <p>{course.description}</p>
      <nav>
        {course.modules
          .sort((a, b) => a.order - b.order)
          .map(mod => (
            <a key={mod.id} href={`/course/${params.slug}/${mod.id}`}>
              {mod.title}
            </a>
          ))}
      </nav>
    </article>
  );
}

export default CoursePage;

Denne komponenten kjører utelukkende på serveren. Supabase-kallet skjer direkte, uten at API-nøkler eksponeres til klienten. HTML-en som sendes til nettleseren inneholder allerede alt innholdet — ingen loading states, ingen vannfallsrequester.

Statisk generering med generateStaticParams

For porteføljesiden genererer jeg alle bloggsider ved byggtid. generateStaticParams forteller Next.js hvilke sider som finnes:

import { getAllPosts } from '@/lib/blog/posts';

export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map(post => ({ slug: post.slug }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPostBySlug(params.slug);
  if (!post) return notFound();

  return (
    <article>
      <h1>{post.title}</h1>
      <time dateTime={post.date}>{post.date}</time>
      <div>{post.content}</div>
    </article>
  );
}

Ved next build genereres en statisk HTML-fil for hvert blogginnlegg. Resultatet er en mappe med ferdige filer som Firebase Hosting serverer direkte. Ingen runtime, ingen cold starts, ingen serverkostnader.

Når du IKKE bør bruke Next.js

Next.js er kraftig, men det er ikke alltid riktig valg.

Enkle SPA-er. Hvis du bygger en intern dashboard-app som ikke trenger SEO eller server-rendering, er Vite med React enklere. Next.js tilfører kompleksitet du ikke trenger — server components, middleware, build-konfigurasjon — for apper der en enkel klient-side bundle gjør jobben.

Statiske sider uten React. Hvis du bygger en ren innholdsside uten interaktivitet, er Astro eller Hugo raskere og enklere. Du trenger ikke et React-rammeverk for å vise Markdown-filer.

Når du trenger full kontroll over serveren. Next.js abstraherer mye av serverlogikken bort. Hvis du trenger custom WebSocket-håndtering, streaming av store filer, eller spesialisert server-konfigurasjon, kan det være enklere å bruke Express eller Fastify direkte.

Oppsummering

Next.js gir meg muligheten til å bruke samme rammeverk for fundamentalt forskjellige prosjekter. Nextbook er en fullstack-app med SSR og autentisering. Porteføljesiden min er en statisk blogg. Begge er bygget med Next.js, og begge utnytter de delene av rammeverket som gir mening for akkurat det prosjektet. Det er styrken — du velger det du trenger og ignorerer resten.