// app/api/fast-auth-check/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { jwtVerify } from 'jose'; // 'jose' funcționează nativ pe Edge, 'jsonwebtoken' NU
export const runtime = 'edge';
export async function GET(req: NextRequest) {
const token = req.headers.get('authorization')?.split(' ')[1];
if (!token) {
return NextResponse.json({ error: 'Unauthenticated' }, { status: 401 });
}
try {
const secret = new TextEncoder().encode(process.env.JWT_SECRET);
const { payload } = await jwtVerify(token, secret);
return NextResponse.json({ userId: payload.sub, fast: true });
} catch (err) {
return NextResponse.json({ error: 'Invalid token' }, { status: 403 });
}
}Am trecut acum jumătate de an un proiect de e-commerce cu vreo 40k utilizatori lunari pe Edge Runtime în Next.js, crezând că am găsit sfântul potir al latenței. Spoiler: după două săptămâni am mutat 70% din API-uri înapoi pe Node.js. Câștigul de latență nu a justificat durerea de cap pe partea de dezvoltare.
De ce atrage Edge: Latența și Cold Start-ul
Pe Node.js (pe serverless Vercel sau AWS Lambda), cold start-ul îmi lua undeva între 600ms și 1.5 secunde dacă aveam pachete grele importate. Dacă nimerea un user pe o rută neîncălzită, experiența era vizibil agățată.
Trecerea pe Edge a tăiat cold start-ul sub 15-20 milisecunde. V8 Isolates pornesc practic instantaneu pentru că nu mai ridică un container întreg de Node. Perceptual, din browser, API-ul zbura. Dar entuziasmul s-a stins rapid când am început să adăugăm funcționalități noi.
Zidul de care m-am lovit pe Edge
Principala greșeală pe care o fac mulți e că tratează Edge Runtime ca pe un Node.js mai rapid. Nu este. Edge rulează într-un mediu restrâns (V8 Isolates, similar cu Cloudflare Workers), unde lipsesc piese fundamentale din ecosistemul Node.
- Fără module native Node – Am vrut să generez un simplu invoice PDF cu
pdfkit. Crash instant la build. Fărăfs, fărăstream-uri complete, fărăchild_process. - Probleme cu ORM-urile clasice – Prisma și TypeORM au nevoie de conexiuni TCP directe la bază. Pe Edge, un pool tradițional de PostgreSQL pică. A trebuit să trecem pe Prisma Data Proxy (care adaugă propria latență) sau să folosim drivere HTTP/WebSockets gen Neon/PlanetScale.
- Criptografie veche – Pachete mai vechi din npm care foloseau
cryptodin Node au crăpat până le-am înlocuit cu variante bazate pe Web Crypto API.
Când schimbi runtime-ul în practică?
După toate încercările, am ajuns la o regulă simplă în echipă:
- Node.js este Runtime-ul Default. Dacă ruta face query-uri complexe în DB, procesează fișiere, trimite email-uri sau folosește SDK-uri de la terți care depind de Node, rămâne pe Node. Punct.
- Edge doar pentru rute subțiri. Middleware-ul din Next.js rulează oricum pe Edge, deci verificările de Auth (verificare JWT scurtă), redirect-urile după geolocație sau A/B testing-ul sunt perfecte aici.
Trade-off-ul e clar: pe Node ai compatibilitate 100% cu tot ecosistemul npm, dar plătești cu cold start. Pe Edge ai viteza pură de răspuns, dar ești limitat la API-uri standard Web și trebuie să fii foarte atent ce pachete tragi în node_modules.
Voi ce runtime folosiți ca default pe proiectele noi de Next.js și unde ați simțit cel mai tare limita celor de la Vercel?