Belajar Next.js - Serverless & Edge Runtime

#Pendahuluan

Arsitektur deployment modern tidak lagi bergantung pada server tunggal. Kode dijalankan sebagai fungsi yang muncul saat dibutuhkan dan menghilang saat selesai — atau berjalan di titik terdekat dengan pengguna. Dua dunia ini adalah serverless dan edge.

Episode 21 membahas edge functions dan serverless functions, deployment API route di edge runtime, pertimbangan latensi dan perbedaan runtime, serta use case untuk memilih antara keduanya.

#Edge Functions dan Serverless Functions

#Serverless Functions

Serverless functions adalah kode yang dieksekusi sebagai fungsi stateless di runtime Node.js. Platform membagi request ke banyak instance secara otomatis, sehingga skala mengikuti beban tanpa provisioning manual. Karakteristiknya: bisa memakai pustaka Node lengkap, akses database jangka panjang, dan waktu eksekusi lebih lama — cocok untuk logika berat seperti rendering server dan transformasi data.

Serverless juga membawa keuntungan isolasi: satu function yang crash tidak menjatuhkan yang lain, dan deploy hanya mengganti function yang berubah. Model ini meredam masalah yang biasa muncul di server monolitik.

#Edge Functions

Edge functions berjalan di runtime Web Standard yang ringan, di-deploy ke banyak titik di seluruh dunia. Karakteristiknya: memulai dalam hitungan milidetik, latensi sangat rendah karena dekat dengan pengguna, tapi dibatasi API yang tersedia — tidak bisa memakai pustaka Node murni. Cocok untuk logika ringan yang harus merespons secepat mungkin. Contoh implementasi edge di luar Next.js: Cloudflare Workers dan Deno Deploy — konsepnya sama, kode berjalan dekat pengguna dengan runtime ringan, sehingga skill yang kalian pelajari di sini transferable ke platform lain.

#API Route Deployment pada Edge

#Menandai Route untuk Edge

Route handler di App Router bisa ditandai berjalan di edge dengan ekspor runtime = "edge". Contoh endpoint geolokasi:

export const runtime = "edge"
 
export async function GET(request) {
  const country = request.headers.get("x-vercel-ip-country")
  const city = request.headers.get("x-vercel-ip-city")
 
  return Response.json({ country, city })
}

Route di atas membaca header geolokasi yang disuntikkan platform dan merespons dari titik terdekat pengguna. Header x-vercel-ip-country tersedia di edge tanpa memanggil layanan eksternal. Pola yang sama dipakai middleware untuk redirect berdasarkan lokasi:

export function middleware(request) {
  if (request.nextUrl.pathname.startsWith("/lama")) {
    const url = request.nextUrl.clone()
    url.pathname = "/baru"
    return Response.redirect(url)
  }
}
 
export const config = {
  matcher: ["/lama/:path*"],
}

Middleware di atas berjalan di edge untuk setiap request ke /lama, lalu melakukan redirect ke /baru tanpa menunggu origin server. Logika seperti ini memanfaatkan kecepatan edge untuk pengalaman navigasi yang instan.

#Middleware adalah Edge Function

Middleware Next.js adalah bentuk edge function paling umum: berjalan sebelum request mencapai halaman, memungkinkan A/B testing, autentikasi ringan, redirect, dan deteksi bot — semua dalam satu hop jaringan. Middleware dari episode 12 dan 11 memakai kekuatan ini untuk melindungi route dan menangani i18n. Perlu diingat, istilah serverless dan edge sering dipertukarkan, padahal berbeda: serverless adalah model eksekusi berdasarkan permintaan di pusat data, sedangkan edge adalah lokasi eksekusi di jaringan tepi. Sebuah serverless function bisa saja di-deploy di edge, dan edge function tetap dihitung sebagai fungsi stateless.

#Latency Considerations dan Runtime Differences

#Sumber Latensi

Latensi datang dari tiga tempat: waktu jaringan (perjalanan data), waktu eksekusi (proses kode), dan cold start (inisialisasi pertama). Serverless function yang jarang dipanggil mengalami cold start hingga ratusan milidetik, sedangkan edge function memulai sangat cepat. Edge menang di latensi jaringan karena dekat pengguna; serverless menang di kapabilitas karena runtime Node penuh.

Untuk aplikasi yang mengejar performa terbaik, edge paling masuk akal untuk logika yang sering dipanggil dengan payload kecil, sedangkan serverless untuk pekerjaan berat yang jarang dijalankan.

#Perbedaan Kapabilitas

Perbedaan praktisnya:

• Database: edge tidak praktis untuk koneksi database jangka panjang; serverless lebih cocok.
• Pustaka: edge hanya memakai Web Standard; serverless memakai ekosistem Node.
• Ukuran bundle: edge membatasi ukuran kode; serverless lebih longgar.
• Durasi: edge untuk eksekusi singkat; serverless untuk proses panjang.

Waktu eksekusi adalah pembeda praktis lainnya. Edge function dibatasi durasi eksekusi yang sangat singkat, sementara serverless function bisa berjalan lebih lama. Upload file besar, transformasi data berat, atau rendering dengan banyak dependensi sebaiknya tidak berjalan di edge.

Memilih runtime berarti menimbang kebutuhan ini terhadap latensi yang bisa ditoleransi.

#Use Case untuk Edge vs Serverless

#Kapan Memakai Edge

Edge adalah pilihan tepat untuk logika ringan yang sensitif latensi: personalisasi konten berdasarkan lokasi, redirect dan A/B testing, autentikasi di middleware, rate limiting, dan penanganan request di titik terdekat. Contoh nyata: deteksi bot berdasarkan header dan pola request, personalisasi konten per negara, atau redirect saat kampanye berlangsung — semuanya bisa dieksekusi dalam beberapa milidetik tanpa menyentuh origin server. Aturan praktis: jika logika selesai dalam milidetik, tidak menyimpan state, dan tidak butuh database — pindahkan ke edge. Mulai dari satu route, ukur dampaknya, lalu perluas.

#Kapan Memakai Serverless

Serverless dipakai untuk pekerjaan yang butuh kapasitas penuh: rendering halaman dengan banyak data, interaksi database dan ORM, integrasi API pihak ketiga, dan pemrosesan upload. Server component Next.js yang membaca database memakai serverless function di bawahnya. Ketika logika memanggil ORM, menyusun query, dan memformat hasil untuk banyak pengguna, serverless function memberi ruang eksekusi yang nyaman — rendering halaman dengan data dari database adalah beban kerja klasik untuk model ini.

#Strategi Campuran

Aplikasi modern memakai keduanya: middleware dan route ringan di edge, halaman dan API berat di serverless. Komponen yang sama bisa dirender di server, sementara request yang membutuhkan respon seketika diarahkan ke edge. Platform seperti Vercel menentukan runtime terbaik secara otomatis, dan kalian bisa menandai override per route. Sebelum mengadopsi edge untuk route produksi, uji di environment preview: pastikan semua API yang dipakai tersedia di runtime edge, dan ukur perbedaan latensi sebelum serta sesudah. Keputusan berdasarkan data lebih baik daripada asumsi.

#Penutup

Inti yang harus dibawa pulang:

• Serverless function menjalankan Node penuh dengan skala otomatis.
• Edge function berjalan ringan dan dekat pengguna.
• Ekspor runtime edge menandai route handler untuk edge.
• Middleware adalah bentuk edge function yang paling umum.
• Cold start dan jarak jaringan adalah dua sumber latensi utama.
• Pilih runtime berdasarkan kebutuhan kapabilitas versus latensi.

Di episode 22 selanjutnya kita akan membahas observability dan monitoring — memantau performa frontend dan web vitals, logging error dengan Sentry, real user monitoring dan analytics, serta dukungan produksi dan deteksi insiden. Aplikasi production kalian akan selalu terpantau.