// app/api/geo-check/route.ts
import { NextResponse } from 'next/server';
// Specificăm explicit runtime-ul Edge pentru această rută
export const runtime = 'edge';
export async function GET(request: Request) {
// Web API standard disponibil nativ pe Edge
const country = request.headers.get('x-vercel-ip-country') || 'RO';
return NextResponse.json({
message: 'Raspuns ultra-rapid din Edge',
country,
timestamp: Date.now()
});
}Am văzut mulți colegi pe forum care pun export const runtime = 'edge' peste tot prin proiect, crezând că e un buton magic de viteză. Am făcut și eu greșeala asta acum un an pe o aplicație de baze de date pentru un client cu peste 15k request-uri pe minut. Am rezolvat cold start-ul, dar am dat de alte bătăi de cap pe care nu le scrie în documentația oficială pe prima pagină.
Haideți să vă povestesc scurt ce am învățat, unde merită cu adevărat și unde mai bine rămâneți pe Node.js-ul clasic.
De ce atrage Edge runtime? (Latență și cold start)
Principalul motiv pentru care vrem Edge este cold start-ul. În Node.js serverless (pe Vercel, AWS Lambda etc.), când o funcție nu a mai fost apelată de ceva timp, platforma trebuie să ridice un container întreg. Asta înseamnă de la 300ms până la 1.5 secunde de latență inutilă pentru primul user ghinionist.
Edge runtime nu folosește containere Node, ci V8 Isolates (similare cu ce are Cloudflare Workers). Nu există proces Node de pornit. Cold start-ul scade drastic: de la 450ms cât aveam eu pe o rută mai grea de Node, la sub 15ms pe Edge. Pentru un API de geofencing sau un Middleware de autentificare, diferența e masivă.
Unde se rupe filmul (Trade-offs de care m-am lovit)
Oamenii uită adesea un detaliu critic: Edge runtime NU este Node.js. Este un mediu de rulare redus care implementează doar Web APIs (cum ar fi fetch, Request, Response).
Iată de ce m-am lovit în primele 48 de ore:
- Fără module native de Node: Uită de
fs,child_process,crypto(cel vechi din Node, deși există Web Crypto API) saupath. - Prisma și ORM-urile clasice tușește urât: Dacă încerci să folosești Prisma direct într-o rută de Edge cu un driver clasic de Postgres (care folosește TCP sockets), o să-ți crăpe la build. Trebuie să folosești opțiuni HTTP/Data Proxy sau drivere speciale precum
@neondatabase/serverless. - Limita de mărime a pachetului: Pe Vercel (planul Pro), limita pentru un Edge Function este destul de strânsă. Dacă tragi în fișier librării grele de manipulare de imagini sau PDF-uri, pachetul depășește limita și build-ul e respins.
Când schimbi la Edge și când rămâi pe Node?
După ce am spart câteva versiuni în staging, mi-am făcut o regulă simplă pe care o urmez în toate proiectele Next.js (App Router):
Rămâi pe Node runtime dacă:
- Folosești un ORM clasic legat la o bază de date relațională fără un HTTP proxy.
- Generezi PDF-uri, procesezi imagini sau folosești pachete npm vechi care depind de API-uri interne Node.js.
- Ai webhook-uri de Stripe sau procesări de plăți complexe unde ai nevoie de cryptografie specifică Node.
Treci pe Edge runtime dacă:
- Ai nevoie de logică în
middleware.ts(redirect-uri bazate pe geolocație, A/B testing). - Ai un API Endpoint simplu care doar face un proxy / wrapper peste un alt API extern sau citește din Redis (Upstash) via HTTP.
- Faci verificare de JWT-uri la intrare unde viteza este critică.
Morala e simplă: Edge nu e un upgrade gratuit pentru toată aplicația, ci o unealtă specializată. Dacă n-ai probleme reale de cold start pe o rută, las-o pe Node.
Voi ce experiențe ați avut cu ORM-urile pe Edge? Ați trecut la drivere serverless sau ați rămas pe Node runtime?