import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
// Activăm Edge Runtime doar pentru această rută
export const runtime = 'edge';
export async function GET(request: NextRequest) {
// Edge are acces nativ rapid la geo-data
const country = request.geo?.country || 'RO';
// Folosim doar fetch-ul standard din browser API
const res = await fetch('https://api.exchangerate.host/latest?base=EUR');
const data = await res.json();
return NextResponse.json({
country,
rates: data.rates,
info: "Rulat instant pe Edge, fără cold start"
});
}Dacă folosești Next.js, sigur ai fost tentat să pui runtime: 'edge' peste tot ca să scapi de cold start-uri. Am făcut asta pe un proiect cu 15.000 de utilizatori activi și am învățat pe pielea mea unde se rupe filmul. În postarea asta îți arăt exact ce merge, ce crapă la compilare și când e mai bine să rămâi pe Node.
De ce ne-am aruncat pe Edge (și ce am câștigat)
În teorie, Edge sună ca un vis. Codul tău rulează pe V8 isolate-uri, direct în locațiile Cloudflare sau AWS de lângă utilizator. Zero cold start sesizabil — am coborât de la 1.2 secunde pe un serverless Node clasic la sub 50ms pe Edge.
Pentru rute simple de marketing, geo-redirecționări sau API-uri de proxy care doar pasează un JSON mai departe, e genial. Am redus latența globală cu aproape 40% pentru utilizatorii din afara Europei. Pagina se încărca instant indiferent dacă userul era din București sau din Singapore.
Unde s-a rupt filmul: limitările de care te lovești rapid
Fericirea a durat până când am vrut să ne conectăm direct la baza de date PostgreSQL.
Surpriză: Edge runtime nu are suport pentru TCP socket-uri native din Node.js. Dacă folosești un ORM clasic ca Prisma, nu îl poți pune pe Edge fără un proxy de conexiuni (cum e Prisma Data Proxy sau Neon Serverless driver).
Apoi, am vrut să generăm niște PDF-uri și să facem hashing la parole cu bcrypt. Ghici ce? Modulele scrise în C++ sau cele care depind de API-urile native de Node (cum ar fi fs sau crypto) vor arunca erori urâte la build. Te trezești că jumătate din pachetele tale din node_modules sunt pur și simplu incompatibile. Edge rulează într-un mediu sandbox extrem de limitat, similar cu un Service Worker din browser.
Cold start-ul: mit versus realitate
Da, Edge pornește instant (sub 5-10ms faza de boot a VM-ului). Dar dacă API-ul tău de pe Edge trebuie să facă un handshake SSL lung cu o bază de date aflată la 5000 km distanță, ai anulat tot câștigul.
Am pățit-o: rutele pe Edge erau rapide teoretic, dar practic așteptau după query-uri din cauza distanței fizice până la baza de date. Pe Node clasic, chiar dacă aveam cold start de o secundă la prima accesare, conexiunile la DB erau menținute calde în pool, iar următoarele request-uri zburau.
Cum le combinăm în producție
Regula mea de aur acum e simplă. Folosesc Edge runtime DOAR pentru:
- Middleware (redirecționări, geo-blocking, verificări rapide de JWT-uri).
- API-uri extrem de simple, care consumă alte API-uri externe prin HTTPS
fetch.
Pentru tot ce înseamnă logica grea de business, procesare de imagini, PDF-uri, conexiuni complexe la DB sau integrări cu SDK-uri enterprise (care de obicei sunt scrise strict pentru Node), las default-ul de Node.js.
Voi ce folosiți pentru API-urile din Next.js? V-ați lovit de limitările de pe Edge sau ați găsit workaround-uri curate pentru conexiunile la baze de date?