Perché costruiamo tutto su Next.js e sull'edge

Abbiamo provato tanti stack. Dopo aver costruito oltre 40 siti e applicazioni in produzione, abbiamo convergiuto su Next.js distribuito all’edge come default. Ecco il ragionamento, trade-off inclusi.

Perché Next.js

Next.js Le dà la capacità di scegliere la strategia di rendering giusta per ogni route, generazione statica, rendering server o rendering client, senza cambiare framework.

Per un sito marketing, la maggior parte delle pagine è statica. Il blog è generato in modo statico. L’endpoint del form contatti è server-rendered. La demo interattiva è client-rendered. Un solo framework gestisce tutto.

L’App Router (introdotto in v13, maturo dalla v15) porta i React Server Components, il che significa che può fare fetch dei dati lato server e spedire zero JavaScript al client per componenti che non richiedono interattività. Una pagina content-heavy che prima spediva 200 KB di JS adesso ne spedisce 15 KB.

Perché l’edge

I server tradizionali girano in una sola regione. Un utente a Singapore che colpisce un server in us-east-1 sta aggiungendo 200-300 ms di latenza di rete a ogni richiesta, prima ancora che il server processi qualcosa.

I runtime edge, Vercel Edge Functions, Cloudflare Workers, eseguono il Suo codice in 30+ locazioni globali. Il server è sempre vicino all’utente. TTFB costantemente sotto i 50 ms in tutto il mondo.

Il trade-off: i runtime edge sono vincolati. Niente accesso al filesystem, API Node.js limitate, limiti di memoria più piccoli. Questo impone disciplina architetturale: funzioni stateless, dati recuperati da API o da database edge-cached.

Lo stack completo

• Framework: Next.js (App Router)
• Styling: Tailwind CSS v4
• Database: Postgres su Neon (serverless, edge-compatible) o Supabase
• Auth: Clerk o next-auth a seconda della complessità
• Email: Resend
• Pagamenti: Stripe
• CMS: file MDX nella repo per siti content-heavy; Sanity per contenuti editabili dal cliente
• Deployment: Vercel

Cosa non usiamo

Non usiamo client-side rendering per pagine che non lo richiedono. Non usiamo API REST dove una server action o un data fetch RSC è più semplice. Non aggiungiamo un framework di backend quando i route handler di Next.js bastano.

La complessità si compone. Ogni servizio in più è un’altra cosa che può fallire, un altro layer d’autenticazione, un’altra pipeline di deployment. Lo stack giusto è il più semplice che gestisca i requisiti.

Costruisca per i requisiti che ha. Aggiunga complessità solo quando ha superato la soluzione più semplice.