// app/api/fast-proxy/route.ts
import { NextResponse } from 'next/server';
// Specificăm explicit runtime-ul Edge pentru cold start minim
export const runtime = 'edge';
export async function GET(request: Request) {
const startTime = Date.now();
// Facem doar un proxy rapid către un microserviciu extern
const response = await fetch('https://api.exemplu.ro/data', {
headers: { 'Authorization': request.headers.get('Authorization') ?? '' },
next: { revalidate: 60 }
});
const data = await response.json();
return NextResponse.json({
data,
latencyMs: Date.now() - startTime
});
}Am văzut zeci de proiecte unde primul reflex a fost să pună export const runtime = 'edge' peste tot, din dorința de a obține viteze record. După câteva ore de debugging, încep să curgă erorile de module native lipsă, conexiuni TCP blocate și build-uri eșuate. Dacă vrei să înțelegi exact ce câștigi și unde te blochezi înainte să dai deploy, hai să vedem diferențele practice.
Cold starts și arhitectura de sub capotă
Runtime-ul standard de Node.js rulează într-un container serverless clasic (cum ar fi AWS Lambda). Când funcția este rece, inițializarea mediului durează: se încarcă runtime-ul, se parsează dependințele și se execută codul global. La un proiect cu vreo 15k utilizatori zilnici unde aveam Prisma și câteva SDK-uri mai grele, măsuram frecvent cold start-uri de 600-1100ms pe Node runtime.
Edge runtime funcționează complet diferit. Folosește V8 isolates — aceeași tehnologie care izolează tab-urile în Chrome sau stă la baza Cloudflare Workers. Cold start-ul scade de la o secundă la 15-40ms, pentru că nu există un sistem de operare complet de inițializat. Răspunsul e instant, iar dacă ai utilizatori distribuiți global, cererea este procesată în cel mai apropiat punct de prezență (PoP).
Ce NU merge pe Edge (și ce trade-off-uri accepți)
Merge incredibil de rapid pentru verificat token-uri și proxy-uri, dar e foarte nasol dacă ai un backend monolitic tradițional. Edge runtime nu este Node.js complet. Are la dispoziție doar un subset de Web APIs standard (Fetch, Request, Response, Web Crypto).
- Fără module Node native: Nu ai acces la
fs,child_process,net,tls. Orice dependință dinnode_modulescare depinde de aceste module va crăpa la build sau runtime. - Conexiunile tradiționale la baze de date: Nu poți deschide un pool clasic de conexiuni TCP către PostgreSQL sau MySQL. Dacă nu folosești un driver peste HTTP/WebSockets (cum ar fi Neon serverless driver, PlanetScale sau Prisma cu Accelerate), nu vei putea interoga baza direct.
- Dimensiunea bundle-ului: Limita este mult mai strictă pe Edge (adesea 1MB - 4MB de cod compilat). O librărie grea de generare PDF-uri (precum Puppeteer sau chiar
@react-pdf/renderer) nu va intra niciodată pe Edge.
Când are sens să faci comutarea?
Edge runtime strălucește în middleware — de fapt, în Next.js middleware-ul rulează exclusiv pe Edge. Acolo verifici sesiuni, citești cookie-uri, injectezi headere sau redirecționezi pe bază de geolocație.
De asemenea, rutele de API care acționează ca un API Gateway (BFF - Backend for Frontend) și doar agregă date din alte microservicii prin fetch sunt candidate perfecte. În schimb, dacă faci procesare de imagini cu Sharp, generare de rapoarte sau tranzacții complexe de DB, lasă ruta pe Node runtime fără regrete.
Voi cum ați împărțit rutele în producție? Ați încercat să treceți baze de date întregi pe serverless drivers pentru Edge sau preferați să țineți API-urile pe Node?