Next.js è la mia scelta predefinita per i prodotti web, e non perché sia di moda. Una sola codebase TypeScript copre ciò che un tempo richiedeva tre progetti: il sito marketing che deve farsi trovare, l’applicazione dietro il login e il sottile livello API che li collega. Questo sito è un piccolo esempio: route localizzate, metadati generati, sitemap, immagini Open Graph e una route llms.txt, tutto nello stesso progetto App Router.
Parto dal server. Pagine e layout sono Server Components per impostazione predefinita: recuperano i dati vicino al database, inviano HTML invece di un bundle JavaScript e mantengono i segreti sul server. Uso «use client» solo nelle foglie dell’albero che hanno bisogno di stato, effetti o API del browser: un form, un menu a discesa, una mappa. Se tutto l’albero comincia con «use client», di solito arrivano un bundle pesante e un’intera categoria di bug.
La scelta della modalità di rendering è una decisione di prodotto, non tecnica. Generazione statica per le pagine che cambiano al deploy. ISR o revalidazione basata sui tag per cataloghi, annunci e blog che cambiano durante la giornata: revalidateTag dopo una scrittura, non un timer che nessuno capisce. Rendering dinamico con streaming Suspense per dashboard e contenuti personali: la struttura compare subito e i dati più lenti arrivano in seguito. Per ogni route annotto perché sia statica o dinamica; una riga che risparmia una settimana di «perché il prezzo è vecchio?».
Per le mutazioni uso Server Actions per i form associati alla pagina e Route Handlers quando un servizio esterno deve chiamare l’applicazione: webhook di un provider di pagamento o di Telegram, client mobile, processo cron. In ogni caso Zod convalida l’input sul server, l’autenticazione si verifica lì e il client non decide mai su denaro o autorizzazioni. Nei prodotti più grandi Next.js resta frontend e BFF, mentre il dominio centrale vive in un servizio NestJS o Node.js con un proprio database.
Prestazioni e SEO fanno parte della definizione di completato. Uso next/image con dimensioni reali, next/font per evitare spostamenti del layout, generateMetadata e dati strutturati su ogni pagina pubblica, importazioni dinamiche per i widget pesanti e verifico i Core Web Vitals su un telefono di fascia media, non su un MacBook. Il deploy è su Vercel se il team vuole zero operazioni, oppure con una build standalone in Docker su AWS o un VPS quando contano costi, residenza dei dati o processi di lunga durata.
Mi rifiuto di mettere «use client» nel layout radice, recuperare gli stessi dati in cinque componenti senza una strategia di cache, nascondere la logica di business nel middleware o fare un aggiornamento major di venerdì senza leggere i codemod. Se la tua app Next.js è lenta o fragile, mandami il repository e le due pagine più lente. Ti dirò cosa sposterei sul server, cosa metterei in cache e cosa eliminerei.
Dai al prossimo prodotto qualcuno che resti.
Pronto a iniziare? Scrivimi: posso cominciare subito e restare. Collaborazioni a lungo termine, non passaggi di consegne dopo due settimane. Parliamo del progetto, dei requisiti e del modo migliore per procedere.