// app/api/fast-endpoint/route.ts
import { NextResponse } from 'next/server';
// Așa forțezi Next.js să ruleze acest endpoint pe Edge
export const runtime = 'edge';
export async function GET() {
// Folosim doar API-uri standard web (fetch, Request, Response)
const res = await fetch('https://api.github.com/repos/vercel/next.js');
const data = await res.json();
return NextResponse.json({
stars: data.stargazers_count,
message: 'Rulat instant pe Edge Runtime'
});
}Să fim sinceri: când a apărut hype-ul cu Edge runtime în Next.js, toți am vrut să mutăm totul acolo. Sună incredibil să ai cold start de zero milisecunde și latență minimă pentru că codul rulează "aproape de utilizator". Dar în producție, realitatea te lovește rapid în față. Am pățit asta pe un proiect cu vreo 15.000 de useri activi pe zi, când am vrut să fim șmecheri și am trecut toate API-urile pe Edge. Ne-am luat un bloc masiv direct la build-ul de producție.
Hai să vedem ce funcționează de fapt, unde se rupe filmul și cum alegi corect între ele fără să-ți pierzi nopțile prin issue-uri pe GitHub.
Edge Runtime: Viteza luminii, dar în cușcă
Edge runtime nu e Node.js. Rulează pe V8 isolates (similare cu Cloudflare Workers), ceea ce înseamnă că nu ai un sistem de operare întreg în spate. De aici vine și pornirea instantanee. Zero cold start sesizabil.
Dar libertatea asta te costă. Nu ai acces la API-urile native de Node. Uită de fs.readFile, uită de process.env accesat dinamic în anumite contexte sau de librării criptografice mai vechi. Dacă folosești un ORM clasic cum e Prisma (fără driver-ul lor special de Edge sau un proxy de conexiuni), build-ul Next.js o să crape glorios cu erori criptice despre module nerezolvate.
Unde merită folosit Edge-ul:
- În Middleware (unde Next.js oricum te obligă să-l folosești).
- Pentru API-uri extrem de simple, gen webhooks care doar trimit un payload în Slack sau salvează o stare rapidă în Redis folosind fetch.
- Când folosești baze de date native pentru Edge (Turso, Neon, Supabase via HTTP).
Node.js Runtime: Greoi, dar rezolvă treaba
Node e clasic. Ai tot ecosistemul npm la dispoziție. Vrei să generezi PDF-uri, să procesezi imagini cu sharp sau să folosești SDK-uri vechi de AWS? Doar pe Node poți face asta fără bătăi de cap.
Trade-off-ul major este cold start-ul pe serverless (cum e pe Vercel). Dacă API-ul tău nu a mai fost apelat de un sfert de oră, prima rulare pe o funcție serverless Node.js poate dura de la 500ms până la 2-3 secunde, în funcție de cât de mare e bundle-ul de cod. Am reușit să reduc cold start-ul cu 30% pe un endpoint doar prin eliminarea unor importuri inutile și trecerea de la Node standard la un bundle mai curat.
În plus, atenție la latența bazei de date. Dacă ai baza de date în AWS Frankfurt, iar API-ul tău Edge rulează pe un server edge din US pentru un vizitator de acolo, interogarea bazei de date va traversa Atlanticul de două ori. În cazul ăsta, Edge-ul devine mult mai lent decât un server Node clasic plasat fizic chiar lângă baza de date.
Când și cum schimbi runtime-ul?
În Next.js, implicit totul rulează pe Node.js. Dacă vrei să testezi dacă un endpoint rezistă pe Edge, e de ajuns să exporți o constantă de configurare în fișierul de rută.
Sfatul meu după câteva proiecte eșuate și apoi reparate: pornește mereu implicit pe Node.js. Treci pe Edge doar acele rute specifice care sunt apelate extrem de des, au nevoie de latență de sub 50ms și nu depind de librării grele.
Voi cum ați abordat problema asta? Ați reușit să țineți o bază de date SQL clasică conectată direct la Edge fără să aveți probleme de connection pooling?