Arsitektur Edge vs Node.js Runtime di Next.js: Trade-off Latensi, Koneksi Database, dan Biaya

Pemilihan runtime pada Next.js App Router menentukan lingkungan eksekusi kode, ketersediaan Node.js API, serta pola komunikasi jaringan ke infrastruktur backend. Secara default, Next.js mengeksekusi route handler dan Server Components menggunakan Node.js Runtime standar. Namun, pengembang dapat mengubahnya menjadi Edge Runtime berbasis V8 isolates via konfigurasi export const runtime = 'edge'.

Mengasumsikan Edge Runtime selalu menghasilkan aplikasi yang lebih cepat adalah kekeliruan arsitektur. Keuntungan latensi dari eksekusi serverless di lokasi terdekat dengan pengguna (Point of Presence/PoP) sering kali tereliminasi ketika route tersebut harus melakukan query ke database relasional terpusat.

Perbandingan Teknis: Karakteristik Eksekusi dan Lingkungan Runtime

Node.js Runtime dan Edge Runtime beroperasi di atas model isolasi komputasi yang fundamental berbeda:

• Node.js Runtime: Menjalankan instance di dalam container atau microVM terisolasi. Mendukung ekosistem Node.js penuh, termasuk modul native C/C++, binding OS, akses filesystem (fs), dan socket TCP langsung melalui modul net.
• Edge Runtime: Berjalan di atas V8 isolates ringan (seperti Cloudflare workerd). Runtime ini mengimplementasikan subset standar Web API (Fetch, Request, Response, Streams, Web Crypto). Edge tidak memiliki akses native ke OS, modul native C++, maupun implementasi lengkap Node.js core modules.

Cold Start dan Latensi TTFB

Edge Runtime memiliki keunggulan mutlak pada cold start. Inisialisasi V8 isolate umumnya berlangsung di bawah 5-15 ms karena tidak memerlukan alokasi container atau booting sistem operasi. Sebaliknya, Node.js runtime pada infrastruktur serverless konvensional memerlukan waktu cold start berkisar antara 150 ms hingga lebih dari 1 detik tergantung ukuran bundle aplikasi dan layer dependency.

Time to First Byte (TTFB) untuk respons murni komputasi (tanpa data retrieval eksternal) pada Edge Runtime jauh lebih rendah karena request ditangani oleh CDN node terdekat dari pengguna. Namun, skenario berubah drastis saat request memerlukan I/O database.

Bottleneck Koneksi Database: Stateful TCP vs Stateless HTTP

Database relasional konvensional (PostgreSQL, MySQL) menggunakan protokol berbasis stateful TCP connection. Arsitektur ini menuntut handshake TCP, TLS negotiation, dan proses autentikasi pada setiap pembukaan koneksi baru.

Limitasi Socket TCP pada Edge

Isolates pada Edge Runtime dirancang bersifat ephemeral dan terdistribusi di ratusan edge location. Sifat ini memicu dua masalah utama:

1. Connection Exhaustion: Edge isolates tidak dapat mempertahankan persistent connection pool di seluruh request yang tersebar di berbagai PoP. Jika ribuan edge function aktif secara bersamaan dan masing-masing membuka direct connection ke database, batas max_connections database engine akan terlampaui dalam hitungan detik.
2. Ketiadaan Modul net/tls: Driver database standar (seperti pg atau driver native Prisma) bergantung pada modul internal Node.js. Di Edge Runtime tanpa polyfill socket, library ini akan gagal saat kompilasi atau runtime.

Strategi Mitigasi: HTTP Proxy & Connection Pooler

Untuk menjalankan query database dari Edge Runtime, diperlukan layer perantara:

• HTTP/WebSocket Database Driver: Menggunakan database dengan native HTTP interface (seperti Neon serverless driver atau PlanetScale) yang membungkus query SQL ke dalam request HTTP stateless.
• Dedicated Proxy Layer: Menggunakan Cloudflare Hyperdrive atau Prisma Accelerate untuk menangani pooling koneksi TCP di edge network sebelum diteruskan ke origin database.

Contoh implementasi query database pada Edge Runtime menggunakan HTTP-based driver:

// app/api/edge-query/route.ts
import { neon } from '@neondatabase/serverless';

export const runtime = 'edge';

export async function GET() {
  // neon() menggunakan HTTP fetch, kompatibel dengan Edge Runtime
  const sql = neon(process.env.DATABASE_HTTP_URL!);
  
  const result = await sql`SELECT id, name FROM products LIMIT 10;`;
  
  return Response.json(result);
}

Contoh implementasi standar pada Node.js Runtime menggunakan TCP Connection Pool:

// app/api/node-query/route.ts
import { Pool } from 'pg';

export const runtime = 'nodejs';

// Persistent pool aman digunakan dalam scope runtime Node.js
const pool = new Pool({
  connectionString: process.env.DATABASE_DIRECT_URL,
  max: 10,
  idleTimeoutMillis: 30000,
});

export async function GET() {
  const client = await pool.connect();
  try {
    const result = await client.query('SELECT id, name FROM products LIMIT 10;');
    return Response.json(result.rows);
  } finally {
    client.release();
  }
}

Analisis Biaya Operasional dan Hidden Egress Cost

Penilaian arsitektur tidak hanya menyangkut performa, tetapi juga struktur biaya infrastruktur.

Per-Request Compute vs Regional Instances

Edge computing umumnya ditagih per invocation count ditambah durasi CPU. Jika workload didominasi oleh operasi I/O-bound (menunggu respons database yang lambat), waktu tunggu tersebut tetap dapat menambah metrik tagihan dependensi edge provider.

The Cross-Region Egress Trap

Hidden cost terbesar pada arsitektur Edge adalah Data Transfer Out (Egress) dan latensi waterfall:

Skenario: Pengguna berada di Tokyo (NRT). Origin database PostgreSQL berada di region AWS Virginia (us-east-1). Route dikonfigurasi menggunakan Edge Runtime.

Alur jaringan yang terjadi:

1. User di Tokyo mengirim request ke Edge PoP Tokyo (latensi jaringan: ~10 ms).
2. Edge Function di Tokyo mengeksekusi query database ke us-east-1 (latensi round-trip lintas benua: ~160-180 ms per round-trip).
3. Jika handler memiliki 3 sequential query (N+1 waterfall), latensi total murni untuk transfer data saja mencapai >500 ms.
4. Data hasil query ditransfer dari region database ke Edge PoP, memicu tagihan network egress antar-region/cloud provider, sebelum dikirim kembali ke pengguna.

Jika route tersebut dijalankan di Node.js runtime yang ditempatkan di region yang sama dengan database (misal: AWS us-east-1), latensi antar server dan database adalah <2 ms. Total waktu eksekusi Node.js terpusat sering kali jauh lebih rendah daripada Edge Runtime yang mengalami network round-trip penalty lintas benua.

Maintainability, Tooling, dan Fragmentasi Ekosistem

Mencampurkan kedua runtime dalam satu project Next.js menimbulkan kompleksitas pengembangan:

• Debugging Lokal: Simulasi Edge Runtime di localhost (menggunakan Miniflare atau runtime emulator bawaan Next.js) tidak selalu merefleksikan environment produksi secara identik. Perilaku garbage collection, crypto subtle API, dan memory limits sering kali memunculkan bug yang hanya terdeteksi pasca deployment.
• Fragmentasi Shared Modules: Utility functions atau file pembantu yang mengimpor pustaka pihak ketiga (misal: JSON Web Token generator tertentu, hashing library berbasis C++, logging framework) dapat merusak build jika diimpor secara tidak sengaja oleh file dengan konfigurasi runtime = 'edge'.
• Automated Testing: Test runner seperti Vitest atau Jest secara default berjalan di environment Node.js. Menulis unit test yang memverifikasi kepatuhan kode terhadap batasan Edge Runtime membutuhkan setup runner tambahan berbasis isolated environments.

Matriks Keputusan: Kapan Memilih Edge vs Node.js

Gunakan Edge Runtime untuk tugas-tugas stateless I/O ringan dan operasi komputasi yang terlokalisasi di pinggir jaringan. Pertahankan Node.js Runtime untuk domain inti aplikasi yang sarat integrasi database, transaksi ACID, dan ekosistem library enterprise.