Edge Runtime trên Vercel: Khi nào nên dùng, khi nào nên tránh

Edge Runtime là một trong những buzzwords lớn nhất của frontend infrastructure. Vercel, Cloudflare, Deno Deploy đều push edge computing. Nhưng sau 2 năm thực chiến, mình thấy edge không phải lúc nào cũng là lựa chọn đúng.

Edge Runtime là gì?

Edge Runtime chạy code tại CDN edge locations (200+ locations worldwide), thay vì 1-2 server regions. Nó dùng V8 isolates (không phải Node.js), nên:

• Cold start: ~0ms (vs Node.js serverless: 200-500ms)
• Latency: Gần user hơn = nhanh hơn
• Cost: Rẻ hơn serverless functions

Nhưng đổi lại, bạn mất rất nhiều thứ.

Giới hạn của Edge Runtime

Edge KHÔNG phải Node.js. Những APIs sau không available:

• fs module — không đọc/ghi file
• node:crypto đầy đủ — chỉ có Web Crypto API
• Native Node.js modules (C++ addons)
• Execution time limit: 30 giây (Vercel), thường 10-25ms cho edge
• Memory limit: 128MB
• No persistent connections (WebSocket server, database connection pools)

Khi nào nên dùng Edge

1. Middleware (authentication, redirects, A/B testing)

// middleware.ts — Perfect use case cho Edge
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export const config = {
  matcher: ["/dashboard/:path*", "/api/:path*"],
};

export function middleware(request: NextRequest) {
  const token = request.cookies.get("session")?.value;
  
  if (!token) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  // Verify JWT (Web Crypto API available)
  // Lightweight check, không query DB
  
  // A/B testing
  const bucket = request.cookies.get("ab-bucket")?.value 
    ?? (Math.random() > 0.5 ? "A" : "B");
  
  const response = NextResponse.next();
  response.cookies.set("ab-bucket", bucket);
  response.headers.set("x-ab-bucket", bucket);
  
  return response;
}

Middleware là the perfect use case: chạy trước mọi request, cần nhanh, logic đơn giản.

2. Geolocation-based responses

Edge functions biết user ở đâu qua request headers. Redirect về CDN gần nhất hoặc serve content theo region.

3. API routes đơn giản (không cần DB)

Feature flags, config endpoints, simple transformations.

Khi nào KHÔNG nên dùng Edge

1. Database queries

Đây là sai lầm phổ biến nhất. Edge function ở Singapore, DB ở US-East = latency cao hơn so với Node.js function cùng region với DB:

// ❌ Edge + remote DB = chậm hơn Node.js
export const runtime = "edge";

export async function GET() {
  // Edge location: Singapore
  // DB: US-East-1
  // Mỗi query: +200ms round trip
  const posts = await db.post.findMany(); // SLOW
  return Response.json(posts);
}

// ✅ Node.js runtime, cùng region với DB
export const runtime = "nodejs";

export async function GET() {
  // Function: US-East-1
  // DB: US-East-1
  // Mỗi query: ~5ms
  const posts = await db.post.findMany(); // FAST
  return Response.json(posts);
}

2. Heavy computation

Image processing, PDF generation, AI inference — những thứ cần CPU time và memory vượt quá edge limits.

3. Prisma ORM

Prisma cần connection pooling và native engine. Trên edge phải dùng Prisma Accelerate hoặc Data Proxy — thêm một hop, thêm complexity, thêm cost.

Decision framework

Hỏi 3 câu:

1. Logic có cần Node.js APIs không? → Có: dùng Node.js
2. Có query database không? → Có: dùng Node.js (cùng region với DB)
3. Latency từ edge có thực sự quan trọng cho endpoint này? → Không: dùng Node.js

Chỉ khi cả 3 câu trả lời "không/có" theo đúng thứ tự, edge mới là lựa chọn đúng. Đừng dùng edge chỉ vì nó "cool" — đúng tool cho đúng việc.