L'App Router di Next.js è stabile da maggio 2023, e per la prima volta i React Server Components sono arrivati in mano a sviluppatori "normali". A 18 mesi di distanza, dopo averli usati in dieci progetti di taglie e settori diversi, abbiamo idee chiare. Le condividiamo per chi sta valutando ora se adottarli o no.
Lezione 1: il vero vantaggio è il fetching colocato
Sulla carta i Server Components vendono performance, bundle ridotto, streaming. Tutto vero, ma il vero guadagno per chi sviluppa è altrove: il dato è dove serve. Una pagina dashboard non ha più una useEffect che chiama un'API che chiama un controller che chiama un service. Ha un componente che scrive direttamente await prisma.lead.findMany(...).
La curva di apprendimento è bassa, soprattutto per chi viene da PHP o Rails. Per chi viene da React puro, è invece un cambio di abitudine: dimenticare di poter usare useState in un componente è — letteralmente — la prima rottura mentale.
Lezione 2: la divisione client/server è una decisione di design
"Use client" non è un'annotazione tecnica, è una scelta architetturale. Sbagliarla genera bundle gonfi (componenti pesanti che diventano client senza motivo) o esperienze rotte (componenti che dovrebbero essere interattivi ma non lo sono).
La nostra regola: il "use client" si mette il più in basso possibile nell'albero. Una pagina è server. La form è server. Il bottone "submit" che apre un modale di conferma è client — e basta lui.
Lezione 3: il caching è una mente da capire
Il modello di caching di Next 13/14 era confuso. Il modello di Next 15 è migliore — il default è "non cachare" — ma resta una superficie complessa. Le quattro forme di cache (request memoization, data cache, route cache, full route cache) si sovrappongono in modi non sempre intuitivi.
La nostra disciplina: ogni endpoint dichiara esplicitamente la sua cache policy. cache: "no-store" per dati personali, revalidate: 60 per dashboard non critiche, force-cache con tags e revalidateTag per pagine pubbliche aggiornabili da CMS.
Lezione 4: i Server Components non risolvono i problemi del client
Se la tua interfaccia ha bisogno di interazioni complesse — drag and drop, editing visuale, chat in tempo reale, mappe — i Server Components non aiutano direttamente. Ti aiutano a far arrivare lo stato iniziale e a non spedire JavaScript inutile, ma per il resto sei in territorio React tradizionale.
Il pattern che usiamo è "shell server, isole client": il guscio della pagina è server, le aree interattive sono client component piccoli e mirati, lo stato condiviso vive in URL searchParams o in store leggeri (Zustand) confinati al ramo client.
Cosa non rifaremmo
Server Actions per pagine pubbliche con formulari ad alta concorrenza: meglio API routes con rate limiting esplicito. Le Server Actions sono comode ma rendono meno trasparente il limite e l'autenticazione — su contesti pubblici abbiamo avuto sorprese.
Cosa rifaremmo subito
Le dashboard amministrative come prime cittadine dei Server Components. Per quelle, la riduzione di codice e la pulizia mentale ripagano da subito l'investimento di apprendimento. Per le landing page o i blog, lo statuto di "server-by-default" è quasi un non-pensiero: tutto va in server, e il sito è veloce.