Edge vs Node per route LLM e database: limiti e split

“Edge” (Vercel Edge, Cloudflare Workers, alcune route Nitro configurate come edge) non è Node completo: non puoi assumere fs, child_process, molti moduli nativi C++ o socket TCP arbitrari. I driver database classici (Postgres pg, mysql2, better-sqlite3) richiedono TCP o addon nativi → di solito solo in Node, non edge.

Le chiamate HTTP outbound verso API LLM (fetch verso OpenAI/Anthropic) funzionano spesso da edge, ma restano limiti di CPU, wall time e dimensione bundle. Consulta sempre le limitazioni aggiornate (es. Vercel Edge limits, Cloudflare Workers limits)—cambiano nel tempo.

Edge: cosa funziona bene

• JWT leggero (solo decode/verify con libreria compatibile Web Crypto).
• Rewrite, A/B, geolocation header, caching fetch.
• Proxy verso una API Node che fa I/O pesante.
• Chiamate a vendor via fetch con payload moderati.

Node: cosa richiede quasi sempre

• ORM/driver SQL con pool TCP, better-sqlite3, Prisma engine, BullMQ, ffmpeg, sharp pesante, file system locale.
• Streaming lunghi o trasformazioni CPU oltre il budget edge.
• Accesso a segreti tramite meccanismi che edge non espone uguali (dipende dal provider).

Pattern split consigliato

Flusso tipico per un prodotto con auth + LLM + DB:

Client → Edge route (auth JWT, rate limit leggero)
       → fetch interno verso /api/node/… (region fisso)
       → Node: query DB + chiamata LLM + logging

L’edge riduce latenza per validazione e routing; il lavoro stateful resta in Node dove i runtime kits sono maturi.

Cold start e timeout

Edge spesso ha cold start più basso per handler minuscoli; Node (serverless) può pagare avvio container + caricamento Prisma. Per la prima richiesta dopo idle, misura p95 separatamente per /edge vs /node—non mescolare metriche.

Checklist pre-deploy

• Questa route importa moduli con node: o path nativi? → Node.
• Devo aprire più di N subrequest sequenziali pesanti? Valuta tutto Node o batch.
• Timeout edge < durata LLM p95? → Node o pattern async (queue + webhook).
• Devo usare WebSocket server verso DB? → Node o servizio gestito.

Messaggio di errore tipico (Next.js / Vercel Edge)

Se importi un modulo Node-only (es. fs, better-sqlite3, pg) in una route Edge, la build o il runtime possono fallire con messaggi nel formato (testo esatto varia per versione Next):

Error: A Node.js API is used (fs) which is not supported in the Edge Runtime.

Oppure, in fase di bundling, trace del tipo “node:fs” / “Module not found: Can't resolve 'fs'” verso una dipendenza transitiva. La doc Next.js raggruppa questi casi sotto Node.js Modules in Edge Runtime.

Fix: sposta l’import in una route handler Node (o server route Nitro con preset Node) e tieni sull’edge solo fetch / crypto / logica leggera.

Vercel Edge: limiti che influenzano LLM e DB

Se deploy su Vercel Edge Functions, il runtime espone API Web standard (fetch,crypto, streams) ma non Node completo—coerente con quanto dice anche la doc Next.js “Node.js Modules in Edge Runtime”. Per limiti numerici (CPU, durata, streaming) usa sempre la pagina aggiornata Edge runtime / limitations: nel 2025 Vercel ha pubblicato changelog su duration più lunga per risposte streaming (ordine di centinaia di secondi per il flusso) con vincoli sul tempo massimo prima della prima risposta—rileggi il testo corrente prima di dimensionare timeout LLM.

Messaggio pratico del provider: dove servono driver nativi o carico CPU sostenuto, la roadmap aziendale spinge spesso verso Node/Fluid compute; l’edge resta ottimo per routing leggero.

Nitro / Nuxt

In Nitro la route è edge solo se deployment e preset lo permettono. Il preset node-server predefinito nel vostro progetto è Node: niente edge implicito. Se in futuro esponi route su edge runtimes, annota esplicitamente quali entrypoint restano server only (runtimeConfig, routeRules).

Sintesi

fetch-only, stateless, bassa CPU → candidato edge. DB driver, LLM lento, file system, nativi → Node. Il ibrido (edge→node interno) è il default sensato per molti SaaS multi-tenant.