Edge SSR vs Regional Node di Nuxt 3: Trade-off Latensi dan Pool DB

Perbandingan Fundamental: V8 Isolates vs Stateful Node.js

Nuxt 3 menggunakan engine server Nitro yang memungkinkan build output diarahkan ke berbagai runtime melalui nitro.preset. Pilihan utama arsitektur SSR umumnya terbagi menjadi dua paradigma: Edge SSR (berjalan di atas V8 isolates seperti Cloudflare Workers, Fastly Compute, atau Vercel Edge) dan Regional Node.js SSR (berjalan di atas container Docker, VM, atau server tradisional berbasis runtime Node.js penuh).

Perbedaan arsitektur mendasar terletak pada lifecycle proses dan alokasi resource. V8 isolate di edge memiliki boot time dalam hitungan milidetik karena tidak memerlukan inisialisasi kernel OS penuh, memori dialokasikan per request, dan proses bersifat ephemeril. Node.js regional bersifat stateful, berjalan sebagai proses persistent (daemon), memegang alokasi memori sendiri, dan mendukung ekosistem lengkap API POSIX/Node.js native.

Dinamika Latensi: Ilusi Low TTFB vs Overhead Round-Trip Database

Edge SSR menawarkan Time to First Byte (TTFB) dokumen HTML yang sangat rendah ketika request dihentikan langsung di Point of Presence (PoP) CDN terdekat dari pengguna. Namun, metrik TTFB edge menjadi kontraproduktif jika halaman memerlukan server-side data fetching ke database relasional regional.

Kondisi ini menciptakan distributed waterfall latency:

• Skenario Edge SSR: Klien di Jakarta mengakses PoP edge Jakarta (latensi: ~5ms). Nuxt SSR di edge mengeksekusi useAsyncData untuk memanggil PostgreSQL di AWS region ap-southeast-1 (Singapore). Latensi jaringan Jakarta-Singapore PP adalah ~18-25ms. Jika SSR menjalankan 3 query sekuensial, overhead jaringan murni ke database mencapai minimal 60ms di luar eksekusi SQL. Jika DB berada di us-east-1 (latensi PP ~220ms), rendering SSR terhambat ratusan milidetik. Keuntungan edge TTFB hilang sepenuhnya.
• Skenario Regional Node.js (Co-located): Klien di Jakarta mengakses server Node.js di Singapore (latensi: ~25ms). Server Node.js terhubung ke PostgreSQL dalam Local Area Network / VPC yang sama via private peering. Latensi per query adalah <1ms. Tiga query sekuensial selesai dalam hitungan sub-milidetik. Total response time sering kali lebih cepat daripada edge yang terpisah secara geografis dari database.

Manajemen Database Connection: Persistent Pool vs Stateless Proxy

Perbedaan arsitektur runtime ini berdampak langsung pada cara aplikasi menangani koneksi basis data.

1. Regional Node.js: Persistent TCP Pool

Pada runtime Node.js konvensional, instance aplikasi mempertahankan connection pool TCP jangka panjang (misalnya via driver pg, mysql2, atau Prisma engine). Handshake TLS dan autentikasi DB hanya dieksekusi sekali saat pool diinisialisasi. Request yang masuk menggunakan kembali koneksi yang sudah terbuka (reused sockets).

2. Edge SSR: Ketiadaan Persistent Sockets

V8 Isolates di edge tidak mempertahankan persistent TCP socket melintasi request yang diisolasi. Jika 500 edge isolates aktif secara serentak untuk merender halaman Nuxt, 500 koneksi TCP baru akan dibuat langsung ke database. Kondisi ini memicu connection exhaustion pada database engine dalam sekejap (melebihi max_connections).

Untuk menggunakan database relasional di Edge SSR, arsitektur wajib menggunakan middleware koneksi:

• TCP Connection Pooler Eksternal: PgBouncer dengan mode transaction pooling ditempatkan di depan database.
• Database HTTP/WebSocket Drivers: Driver stateless yang mengirimkan query via HTTP, seperti driver Serverless Neon, Supabase Pooler, atau PlanetScale HTTP API.
• Edge Proxy Gateways: Cloudflare Hyperdrive atau Prisma Accelerate yang memelihara pool koneksi regional atas nama worker edge.

Limitasi Runtime Nitro & Kompatibilitas Node API

Nitro mengabstraksi target deployment, tetapi tidak dapat menghilangkan batasan runtime target. Node.js menyediakan API native lengkap, sedangkan runtime Edge hanya menyediakan subset standar Web API (Fetch, Crypto, Streams) dan emulasi parsial modul Node.js.

Dampak langsung pada aplikasi Nuxt 3:

• Native C++ Addons (seperti bcrypt, sharp, atau driver DB berbasis binary C) gagal berjalan di Edge. Wajib menggantinya dengan alternatif WebAssembly (WASM) atau pure JavaScript (misalnya bcryptjs).
• Akses filesystem lokal (fs) dilarang pada edge isolates. Operasi baca-tulis file lokal untuk caching tidak dapat digunakan.
• Batasan ukuran bundle: Cloudflare Workers memberlakukan limit ukuran file skrip terkompresi (1 MB pada free, 10 MB pada standard plan). Bundle Nuxt dengan banyak dependency heavy backend dapat melampaui batas ini.

Implementasi Konfigurasi Nitro

Pengaturan target runtime diatur pada properti nitro.preset di dalam file nuxt.config.ts.

Konfigurasi 1: Regional Node.js SSR (Standalone Server)

Gunakan preset ini untuk container Docker, VM, atau server tradisional.

// nuxt.config.ts
export default defineNuxtConfig({
  compatibilityDate: '2024-04-03',
  nitro: {
    preset: 'node-server'
  }
})

Contoh pemanggilan database di server route menggunakan persistent pool (Node.js):

// server/utils/db.ts
import { Pool } from 'pg'

// Pool hidup selama proses Node.js aktif
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 20,
  idleTimeoutMillis: 30000
})

export const query = (text: string, params?: any[]) => pool.query(text, params)

Konfigurasi 2: Edge SSR (Cloudflare Pages / Workers)

Gunakan preset ini untuk kompilasi V8 isolate edge runtime.

// nuxt.config.ts
export default defineNuxtConfig({
  compatibilityDate: '2024-04-03',
  nitro: {
    preset: 'cloudflare-pages',
    // Polyfill modul Node.js jika dependency pihak ketiga membutuhkannya
    node: false
  }
})

Koneksi database di edge wajib memanfaatkan stateless client atau proxy connection:

// server/utils/db.ts
import { Pool, neonConfig } from '@neondatabase/serverless'

// Menggunakan HTTP / WebSockets untuk menghindari koneksi TCP raw
export const getEdgeClient = () => {
  return new Pool({ connectionString: process.env.DATABASE_URL })
}

Analisis Biaya Operasional (FinOps)

Perbedaan model penagihan mempengaruhi struktur biaya aplikasi:

• Edge SSR (Pay-per-request / CPU-time): Menguntungkan untuk traffic rendah hingga menengah dengan pola bursty. Namun, jika SSR membutuhkan waktu komputasi panjang (karena menunggu network I/O dari DB regional yang jauh), wall-clock time dapat meningkatkan konsumsi resource V8 isolate. Pada traffic stabil dengan volume sangat tinggi (puluhan juta request/hari), biaya per-request edge bisa melampaui harga compute instance regional.
• Regional Node.js (Flat-rate Compute): Biaya server flat dan predictable (contoh: 2 unit VM atau ECS tasks di balik Application Load Balancer). Cocok untuk beban kerja stabil tinggi. Risiko: pemborosan resource saat traffic idle jika tidak menggunakan auto-scaling yang tepat.

Matriks Keputusan: Kapan Memilih Edge vs Regional

Rekomendasi Arsitektur

Pertahankan Regional Node.js SSR jika sistem Anda menggunakan basis data relasional konvensional yang terpusat di satu region, memanfaatkan ORM berat, atau membutuhkan dependensi Node.js native. Arsitektur ini meminimalkan latensi data fetching dan menyederhanakan koneksi database via pool lokal.

Migrasi ke Edge SSR hanya jika aplikasi bersifat global, dokumen HTML dapat dicache di edge (menggunakan Nitro route rules swr atau cache), atau backend data layer telah dimigrasikan ke distributed database / HTTP database proxy yang dirancang untuk arsitektur serverless.