// app/api/fast-ping/route.ts
import { NextResponse } from 'next/server';
// Forțăm execuția pe V8 isolates (Edge)
export const runtime = 'edge';
export async function GET(request: Request) {
// Web Crypto e disponibil nativ în Edge
const uuid = crypto.randomUUID();
return NextResponse.json({
status: 'ok',
id: uuid,
region: request.headers.get('x-vercel-id') ?? 'local',
});
}Mulți pun export const runtime = 'edge' orbește în speranța că site-ul va deveni instant mai rapid, iar după cinci minute se lovesc de erori ciudate legate de module lipsă. Dacă vrei să știi exact când merită să muți un route handler pe Edge și unde riști să-ți complici viața degeaba, ai nimerit unde trebuie.
Iluzia cold start-ului de 0ms
Pe serverless clasic (Node.js pe AWS Lambda prin Vercel), un cold start tipic stă undeva între 250ms și 800ms dacă pachetul funcției e măricel. Dacă ai importat Prisma, trei librării de validare și ceva crypto vechi, clientul simte o secundă întreagă de pauză la primul request.
Pe Edge (V8 isolates), runtime-ul pornește aproape instantaneu, de regulă sub 15-30ms. La un magazin online cu vreo 14.000 de vizitatori unici pe zi, am mutat verificarea de sesiune și redirecționările de geolocație direct în Middleware pe Edge. Rezultatul a fost vizibil imediat: TTFB-ul mediu pentru paginile dinamice a scăzut de la 420ms la 110ms.
Sună idilic, dar aici se oprește de multe ori entuziasmul.
Unde se rupe filmul pe Edge
Edge nu e Node.js. E un subset minimal de API-uri web (Fetch, Web Crypto, Streams) rulat direct în worker-e V8 distribuite global. Asta aduce două mari dureri de cap:
- Ecosistemul npm: Adio orice pachet care depinde nativ de
fs,child_process,netsaubuffervechi. Dacă vrei să generezi PDF-uri, să manipulezi imagini cusharpsau să folosești librării vechi de plată, Edge îți va arunca erori la build fără milă. - Baza de date și conexiunile TCP: Aici se păcălește lumea cel mai des. Edge nu ține conexiuni TCP persistente deschise către o bază de date clasică (un Postgres găzduit pe un VPS, de exemplu). Dacă tragi un query dintr-un Edge route direct într-un Postgres fără connection pooling HTTP (cum are Neon, PlanetScale sau Supabase cu pgBouncer), ori epuizezi pool-ul de conexiuni în câteva secunde, ori latența adăugată de handshake-ul SSL anulează complet orice milisecundă câștigată la cold start.
Când schimbi de la Node la Edge?
Nu există o regulă universală, dar am învățat pe propria piele unde funcționează fiecare fără bătăi de cap:
- Merită Edge: Middleware (A/B testing, auth tokens decodate simplu, geo-routing), endpoint-uri de Webhooks cu volum mare care doar pun mesaje într-un queue (de exemplu Upstash QStash), sau payload-uri mici care consumă un API extern prin
fetch. - Rămâi pe Node: Operațiuni CRUD complexe, raportare, generare de fișiere, ORM-uri grele folosite fără proxy serverless, interacțiuni directe cu AWS SDK pe operațiuni complexe.
Node runtime rămâne opțiunea sigură dacă ai nevoie de flexibilitate și compatibilitate completă. Edge e excelent, dar strict ca un bisturiu pentru latență, nu ca setare globală aplicată din lene pe tot proiectul.
Voi cum ați rezolvat accesul la baza de date pe Edge — ați migrat pe drivere HTTP/WebSockets sau ați preferat să lăsați rutele respective pe Node?