// app/api/geo-check/route.ts
import { NextRequest, NextResponse } from 'next/server';
// Specificăm runtime-ul explicit per rută
export const runtime = 'edge';
export async function GET(req: NextRequest) {
// Accesăm directoarele geografice injectate la nivel de Edge
const country = req.geo?.country || 'RO';
const city = req.geo?.city || 'Bucuresti';
// Web Crypto API este disponibil nativ pe Edge (fără 'crypto' din Node)
const uuid = crypto.randomUUID();
return NextResponse.json({
id: uuid,
location: `${city}, ${country}`,
timestamp: Date.now()
});
}Am trecut anul trecut o aplicație Next.js cu 15k vizitatori unici pe zi de la Node.js runtime la Edge pe zonele critice, convins că scăpăm definitiv de latență. Rezultatul? Cold start-ul pe middleware și pe rutele de geofencing a scăzut de la 450ms la sub 15ms, dar ne-am lovit violent de zid când am încercat să facem operațiuni clasice pe baza de date.
Nu tot ce zboară pe Edge se potrivește în orice proiect. Dacă nu înțelegi diferența din fundal, riști să pierzi ore bune depanând erori ciudate de module lipsă.
Cold start: V8 Isolates vs instanțe Node.js
Secretul din spatele vitezei Edge runtime este că nu boot-ează un proces Node.js întreg. Vercel (sau Cloudflare Workers) folosește V8 Isolates. Nu există un sistem de operare virtualizat care trebuie să pornească, nu există încărcarea completă a runtime-ului Node.
Pe Node runtime (serverless pe AWS Lambda sub capotă), dacă rutei tale nu i-a venit un request de 5 minute, containerul se oprește. Următorul user așteaptă 300ms - 800ms doar pentru cold start. Pe Edge, isolatul pornește în 5-10ms. Pentru utilizatorii din Asia sau America de Sud, routed direct la cel mai apropiat POP (Point of Presence), TTFB-ul a scăzut la noi de la 280ms la 35ms.
Unde te lovești cu capul de prag
Toate bune și frumoase până când apelezi o librărie veche. Edge runtime nu este Node.js. Este un mediu bazat pe Web APIs (similar cu ce ai în browser: fetch, TransformStream, Web Crypto).
Iată ce NU merge pe Edge:
- Module native de Node.js:
fs,child_process,net,pathnu există. Dacă librăria ta preferată de PDF-uri le folosește, codul crapă la build. - Conexiuni TCP direct pe DB: Driverele clasice de PostgreSQL sau MySQL (
pg,mysql2) au nevoie de TCP sockets. Edge nu suportă asta nativ decât dacă folosești HTTP proxies sau drivere serverless speciale (Neon HTTP driver, Supabase fetch, Turso). - Librării de criptografie vechi:
bcryptclasic folosește binding-uri C++ native. Pe Edge trebuie să treci pebcryptjssau, și mai bine, pejoseși Web Crypto API. - Limita pe bundle size: Pe planul gratuit Vercel ai maxim 1MB pentru o funcție Edge. Un SDK mai gras de AWS sau Stripe îți umple cota imediat.
Am pățit-o pe un modul de checkout: am pus ruta pe Edge, iar în background foloseam un SDK de e-mail care încerca să citească un template din disc cu fs.readFileSync. Build-ul a trecut, dar la runtime crapa instant cu TypeError: fs.readFileSync is not a function.
Când folosești Edge și când rămâi pe Node?
După vreo câteva încercări și rollback-uri, am stabilit o regulă simplă în echipă:
Folosim Edge pentru:
- Middleware (A/B testing, verificare JWT, redirectări în funcție de geolocație).
- Endpoint-uri care fac doar proxy sau
fetchcătre microservicii externe. - Rute simple de read cu cachiere agresivă sau DB-uri serverless pe HTTP (Neon/Upstash).
Rămânem pe Node.js pentru:
- Server Actions complexe și formulare cu upload de fișiere.
- Integrare cu baze de date SQL clasice prin Prisma/Drizzle peste conexiuni lungi TCP.
- Generare de rapoarte, PDF-uri, procesare de imagini (Sharp).
Tranziția nu trebuie să fie totul-sau-nimic. Next.js îți permite să setezi runtime-ul per fișier, iar asta e cea mai mare calitate a framework-ului.
Voi ce folosiți în producție pe Next 14/15? Ați mutat middleware-ul pe Edge sau ați rămas 100% pe Node clasic?