Belajar Nuxt - Edge & Serverless Runtime

#Pendahuluan

Setelah berhasil di-deploy, pertanyaan berikutnya: di mana sebaiknya aplikasi berjalan? Episode 21 membahas dua model utama — edge runtime dan serverless — serta bagaimana Nuxt dan Nitro menjembatani keduanya.

Perbedaannya penting karena menentukan latensi, harga, dan batasan lingkungan eksekusi. Aplikasi yang butuh respons super cepat untuk seluruh dunia cocok di edge; aplikasi dengan workload berat atau kebutuhan fitur Node.js lengkap lebih nyaman di serverless tradisional. Nuxt membuat perpindahan di antara keduanya hanya soal mengganti preset.

#Deploying Nuxt di Edge Runtime

#Apa Itu Edge Runtime

Edge network menempatkan server di banyak lokasi di seluruh dunia. Kode berjalan di lokasi terdekat dengan pengguna, sehingga latensinya sangat rendah — ideal untuk halaman yang membutuhkan respons cepat dari mana pun.

Nuxt mendukung edge melalui preset Nitro, contohnya Cloudflare:

Preset edge Cloudflare

export default defineNuxtConfig({
  nitro: {
    preset: "cloudflare_pages",
  },
})

Preset cloudflare_pages menerjemahkan aplikasi Nuxt menjadi bentuk yang berjalan di edge network Cloudflare. Build lalu di-deploy melalui dashboard atau CLI mereka.

#Batasan Edge Runtime

Edge runtime tidak menjalankan Node.js secara penuh. Beberapa hal yang perlu diperhatikan:

• Fitur Node.js terbatas: beberapa module core tidak tersedia.
• Storage: gunakan KV atau storage edge, bukan filesystem lokal.
• Durasi eksekusi: ada batas waktu untuk setiap request.

Uji aplikasi di preset edge sejak awal, bukan di akhir. Kalian bisa menulis kode yang sadar-lingkungan sehingga tidak bergantung pada fitur Node.js tertentu.

#Serverless Functions dan Nitro Server

#Fungsi Serverless dari Kode yang Sama

Dengan preset serverless seperti vercel atau netlify, seluruh server Nuxt diterjemahkan menjadi fungsi serverless. Setiap server route menjadi function endpoint:

server/api/pesanan/index.ts

export default defineEventHandler(async (event) => {
  const body = await readBody(event)
  return { status: "diterima", id: buatId() }
})

Server route ini otomatis menjadi fungsi serverless di platform target. Tidak ada perubahan kode — kalian tetap menulis defineEventHandler seperti biasa.

#Skalabilitas Serverless

Serverless menangani skala dengan baik: platform menambah instance otomatis saat traffic naik, dan mengecil ke nol saat sepi. Kalian membayar per eksekusi, bukan per jam server. Ini membuat serverless cocok untuk workload dengan traffic yang tidak menentu.

#Runtime Differences dan Environment Considerations

#Node vs Edge vs Serverless

Ketiga runtime berbeda dalam hal yang penting:

• Node server: fitur lengkap, cocok untuk self-host atau VPS.
• Serverless: fitur Node hampir penuh, dieksekusi per-request dengan batas durasi.
• Edge: fitur terbatas, tapi latensi terendah.

Kode harus mempertimbangkan lingkungannya. Jangan menulis kode yang hanya bisa jalan di Node jika targetnya edge:

Kode yang sadar lingkungan

if (process.env.NODE_ENV === "production") {
  console.log("mode produksi aktif")
}

process.env.NODE_ENV tersedia di sebagian besar runtime. Namun untuk mengakses storage di edge, pakai API yang disediakan preset — misalnya useStorage dengan backend KV yang didukung.

#Pertimbangan Environment

Perhatikan juga: ukuran deployment, durasi eksekusi, dan variabel environment berbeda antar platform. Dokumentasikan asumsi lingkungan di README agar tim paham batasan yang harus dijaga.

#Use Cases untuk Edge vs Serverless

#Kapan Memakai Edge

Edge paling unggul untuk:

• Halaman publik dengan traffic global, seperti blog dan landing page.
• Aplikasi yang membutuhkan latensi sangat rendah dari seluruh dunia.
• Konten dinamis ringan yang sering dibaca, jarang ditulis.

Jika sebagian besar halaman bisa di-cache, edge memberikan kecepatan maksimal dengan biaya minimal.

#Kapan Memakai Serverless

Serverless lebih nyaman untuk:

• Aplikasi dengan data pengguna dan logika bisnis yang kompleks.
• Workload yang membutuhkan fitur Node.js lengkap.
• Operasi tulis yang berat seperti pembayaran dan checkout.

Kombinasi juga umum: halaman publik di edge, sedangkan endpoint API transaksional di serverless. Nuxt memungkinkan granularitas ini lewat konfigurasi per route di beberapa platform.

#Penutup

Episode 21 menjelaskan pilihan runtime kalian: edge untuk latensi terendah dengan batasan lingkungan, serverless untuk fleksibilitas Node.js yang hampir penuh dengan skala otomatis, dan Node server untuk kontrol penuh. Dengan Nitro, perpindahan antar runtime cukup mengganti preset.

Inti yang harus dibawa pulang:

• Edge mengeksekusi kode di lokasi terdekat pengguna untuk latensi rendah.
• Nitro menerjemahkan aplikasi ke bentuk edge atau serverless via preset.
• Edge memiliki batasan fitur Node.js; uji sejak awal, bukan di akhir.
• Serverless menangani skala otomatis dan biaya per eksekusi.
• Pilih runtime berdasarkan kebutuhan latensi, fitur, dan biaya.
• Halaman publik cocok di edge; logika transaksional berat di serverless.

Di episode 22 selanjutnya kita akan membahas observability dan monitoring — memantau performa frontend dan server, pelacakan error dengan Sentry, real user monitoring dan analytics, serta dukungan produksi dan penanganan insiden.