Nuxt 3 Serverless vs Node Container: Trade-off Skala dan Biaya

Pemilihan arsitektur deployment untuk aplikasi Nuxt 3 menentukan performa throughput, kemudahan pemeliharaan, dan biaya infrastruktur jangka panjang. Melalui Nitro engine, Nuxt 3 memungkinkan kompilasi ke puluhan deployment target hanya dengan mengubah satu konfigurasi preset. Fleksibilitas ini mengharuskan perancangan arsitektur memilih antara dua paradigma utama: Serverless/Edge runtime (Vercel, Cloudflare Pages, AWS Lambda) atau Node.js container mandiri (Docker pada VPS, AWS ECS, atau Kubernetes).

Keputusan ini bukan sekadar preferensi operasional, melainkan trade-off langsung antara latency cold start, pola pooling database relasional, batas kompatibilitas runtime V8, serta model penagihan resource.

Arsitektur Nitro Engine dan Perbedaan Target Runtime

Nitro mengabstraksi lapisan HTTP server menggunakan H3. Kode Nuxt 3 dikompilasi ke output bundle spesifik sesuai target runtime melalui konfigurasi nuxt.config.ts.

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    // Contoh preset serverless/edge:
    // preset: 'cloudflare-pages' // V8 isolate, non-Node
    // preset: 'vercel-edge'
    // preset: 'aws-lambda'

    // Preset container/standalone:
    preset: 'node-server' // Standalone HTTP server berbasis Node.js standard
  }
})

Preset node-server menghasilkan file entry point (.output/server/index.mjs) yang menjalankan proses Node.js persisten menggunakan modul HTTP standar. Sebaliknya, preset serverless atau edge mengemas handler ke dalam fungsi yang dijalankan saat ada event request masuk, sering kali di atas V8 Isolate tanpa proses latar belakang yang persisten.

Trade-off Teknis: Runtime, Cold Start, dan Database

1. Cold Start Latency

Pada arsitektur Node Container, proses inisialisasi aplikasi (bootstrapping framework, parsing konfigurasi, pembentukan koneksi) terjadi satu kali saat container pertama kali dijalankan. Request berikutnya dilayani dengan latency in-memory instan (0ms cold start overhead).

Pada arsitektur Serverless, scaling berbasis event menciptakan instance baru saat traffic melonjak atau setelah periode idle. Durasi cold start dipengaruhi oleh ukuran bundle output Nitro dan execution environment:

• V8 Isolates (Edge): Cold start minimal (< 15-50ms) karena tidak memuat full Node.js OS environment, tetapi memiliki limitasi ukuran memory dan dependensi.
• AWS Lambda / Cloud Run (Node Serverless): Cold start berkisar antara 200ms hingga 1.500ms bergantung pada besaran dependencies dan VPC configuration.

2. Konektivitas Database dan Connection Pooling

Perbedaan mendasar antara proses persisten dan stateless terletak pada manajemen pool koneksi TCP ke database relasional (PostgreSQL, MySQL).

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

// Pada Node Container, pool ini hidup sepanjang container berjalan.
// Pada Serverless, setiap invocation instance dapat membuat instance pool baru.
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 10 // Berbahaya pada auto-scaling serverless tanpa proxy
})

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

Pada Node Container, instance mengelola koneksi TCP persisten menggunakan pool internal secara efisien. Batas pool dapat dikontrol secara deterministik.

Pada Serverless, auto-scaling hingga ratusan fungsi konkuren menciptakan lonjakan koneksi langsung ke database. Kondisi ini memicu error remaining connection slots are reserved for non-replication superuser connections atau kehabisan RAM pada server basis data. Solusi serverless mewajibkan layer perantara seperti PgBouncer, AWS RDS Proxy, Prisma Accelerate, atau beralih ke database berbasis HTTP REST/WebSocket.

3. Limitasi API Native Node di Edge Runtime

Penyebaran Nuxt 3 ke Edge runtime (Cloudflare Workers/Pages, Fastly) berjalan di atas runtime V8 minimalis, bukan Node.js utuh. Konsekuensinya:

• Modul native C++ (bcrypt, sharp untuk pengolahan gambar internal) tidak dapat berjalan. Wajib menggunakan alternatif WebAssembly atau Web Cryptography API.
• Akses sistem berkas lokal (fs) dilarang atau hanya bertindak sebagai mock virtual.
• Dependensi eksternal dari ekosistem npm yang mengasumsikan ketersediaan global Buffer atau process dapat menyebabkan crash runtime jika unenv polyfill Nitro tidak mencakupnya secara penuh.

Analisis Biaya: Pay-per-Request vs Fixed Instance

Model ekonomi kedua pendekatan ini ditentukan oleh pola kurva traffic sistem.

Model Pay-per-Request (Serverless)

Biaya dihitung dari metrik: (Jumlah Invocation * Tarif) + (Durasi Eksekusi dlm ms * Memory Dialokasikan * Tarif) + Bandwidth Egress.

• Keunggulan: Biaya mendekati nol ketika traffic kosong (zero cost at idle). Sesuai untuk aplikasi internal, MVP tahap awal, atau layanan musiman.
• Kelemahan: Biaya meningkat linear secara tajam saat traffic konstan dan padat. Fitur SSR (Server-Side Rendering) Nuxt 3 yang merender DOM di setiap request memperpanjang durasi eksekusi CPU, meningkatkan tagihan per invocation.

Model Fixed Instance (Node Container)

Biaya didasarkan pada alokasi resource komputasi yang dipesan (misalnya, 2 vCPU, 4GB RAM pada VPS/Cloud VM seharga $20 - $40 per bulan).

• Keunggulan: Biaya komputasi terprediksi meski traffic melonjak hingga batas saturasi instance. Biaya per request menurun drastis pada volume traffic tinggi.
• Kelemahan: Biaya tetap berjalan saat instance dalam keadaan idle. Membutuhkan konfigurasi auto-scaling group (HPA di Kubernetes) untuk menangani lonjakan di luar kapasitas dasar.

Observabilitas, Maintainability, dan Vendor Lock-in

Maintainability dan Standardisasi

Deployment container mandiri menggunakan Dockerfile menyediakan paritas lingkungan 100% antara mesin pengembang lokal dan server produksi:

# Dockerfile untuk Nuxt 3 (Preset: node-server)
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/.output .output

EXPOSE 3000
CMD ["node", ".output/server/index.mjs"]

File bundle tunggal ini dapat dipindahkan ke infrastruktur apa pun tanpa modifikasi kode aplikasi.

Kompleksitas Observabilitas

Tracing dan debugging pada container menggunakan tooling open-source standar (OpenTelemetry, Prometheus, Winston/Pino) via persistent socket atau file log streaming. Pada serverless, observabilitas terfragmentasi ke layanan log cloud berbayar (CloudWatch, Vercel Analytics, Datadog Serverless Agent) yang membutuhkan integrasi khusus dan sering kali menambah latency cold start.

Vendor Lock-in

Edge runtime kerap mengikat arsitektur pada fitur proprietary vendor: Cloudflare KV/D1, Vercel Edge Config, atau AWS AppSync. Migrasi dari ekosistem ini membutuhkan perombakan layer penyimpanan data dan middleware aplikasi.

Matriks Keputusan Arsitektur

Panduan Pemilihan

Pilih Nuxt 3 Serverless/Edge jika:

1. Profil traffic fluktuatif ekstrem dengan periode sepi yang panjang.
2. Aplikasi dominan rendering statis/ISR dengan pemanggilan API eksternal via HTTP.
3. Tim tidak memiliki bandwidth untuk mengelola patching OS, Docker orchestration, dan cluster server.

Pilih Nuxt 3 Node Container jika:

1. Aplikasi melakukan koneksi langsung ke cluster database PostgreSQL/MySQL internal dengan volume transaksi tinggi.
2. Kebutuhan responsivitas latency SSR bersifat kritikal tanpa toleransi cold start.
3. Aplikasi memanfaatkan dependensi native C++, pengolahan file media server-side, atau WebSocket dua arah.
4. Traffic bulanan telah stabil pada volume tinggi sehingga model fixed instance jauh lebih hemat secara kalkulasi unit cost.