Perché abbiamo scelto Next.js App Router

Dopo mesi di valutazione e una migrazione progressiva, ecco cosa abbiamo imparato dalla transizione a Next.js App Router.

Il Contesto

Quando Next.js 13 ha introdotto l'App Router, la comunità si è divisa. Da un lato, entusiasmo per React Server Components e il nuovo modello di data fetching. Dall'altro, preoccupazioni per la stabilità e la curva di apprendimento.

Noi abbiamo deciso di aspettare. Non per scetticismo, ma per pragmatismo.

La Decisione

Dopo 6 mesi dal rilascio stabile, abbiamo iniziato la valutazione seria. Tre fattori hanno guidato la decisione:

1. Server Components cambiano tutto

// Prima: getServerSideProps + client component
export async function getServerSideProps() {
  const data = await fetchData();
  return { props: { data } };
}

// Dopo: direttamente nel componente
async function Page() {
  const data = await fetchData();
  return <Component data={data} />;
}

La co-locazione di data fetching e rendering non è solo più elegante: riduce drasticamente la superficie di errore.

2. Streaming e Suspense nativi

export default function Page() {
  return (
    <div>
      <Header />
      <Suspense fallback={<LoadingSkeleton />}>
        <AsyncContent />
      </Suspense>
    </div>
  );
}

Il browser inizia a ricevere HTML immediatamente. L'utente vede contenuto mentre i dati caricano. No more waterfalls.

3. Layout condivisi senza compromessi

app/
├── layout.tsx        # Root layout
├── (marketing)/
│   ├── layout.tsx    # Marketing layout
│   └── page.tsx
└── (app)/
    ├── layout.tsx    # App layout
    └── dashboard/
        └── page.tsx

Route groups ci permettono di avere layout completamente diversi senza hack.

I Problemi Reali

Non è stato tutto rose e fiori. Ecco i problemi che abbiamo incontrato:

Caching aggressivo

Il caching di default di Next.js è troppo aggressivo per molti casi d'uso. Abbiamo dovuto essere espliciti:

// Forza il revalidate su ogni request
export const revalidate = 0;

// O usa fetch options
const data = await fetch(url, { cache: 'no-store' });

Bundle analysis più complesso

Con Server Components, il bundle analyzer mostra solo la parte client. Abbiamo dovuto sviluppare strumenti interni per tracciare cosa va dove.

Testing richiede nuovi pattern

I test dei Server Components richiedono approcci diversi. Abbiamo dovuto riscrivere buona parte della test suite.

Risultati dopo 3 mesi

• TTFB: -40% grazie allo streaming
• Bundle size: -35% grazie ai Server Components
• DX: significativamente migliorata (soggettivo ma unanime nel team)

Conclusione

App Router non è perfetto, ma rappresenta la direzione giusta. Se stai iniziando un nuovo progetto, non c'è motivo di usare Pages Router. Se hai un progetto esistente, valuta una migrazione progressiva.

Il futuro di React è server-first, e App Router è il modo migliore per arrivarci oggi.