Di Next.js 16, memilih runtime bukan keputusan kecil. Pilihan antara Edge Runtime dan Node.js Runtime akan memengaruhi latency, kompatibilitas library, pola akses data, kemampuan memakai API bawaan Node, sampai cara Anda mendesain route handler, middleware, dan proses backend.

Banyak tim tergoda memakai edge untuk semua hal karena terdengar lebih cepat. Padahal, runtime edge dan node punya karakteristik yang berbeda. Edge unggul untuk eksekusi ringan yang dekat dengan pengguna secara geografis, sementara Node.js lebih fleksibel untuk proses berat, integrasi library yang luas, dan akses penuh ke ekosistem server-side tradisional.

Artikel ini membahas perbedaan keduanya secara praktis: bagaimana cara kerjanya, batasan API, isu cold start, latency global, kompatibilitas package, akses filesystem, use case ideal, serta studi kasus nyata menggabungkan middleware ringan di edge dengan proses berat di Node.js runtime.

Memahami dua runtime di Next.js

Secara umum, Next.js memungkinkan sebagian kode backend Anda berjalan di dua lingkungan berbeda:

  • Node.js Runtime: berjalan di lingkungan server Node.js. Ini adalah model yang paling fleksibel dan paling kompatibel dengan package npm yang mengandalkan API Node seperti fs, net, tls, crypto versi Node, child process, dan sebagainya.
  • Edge Runtime: berjalan di lingkungan yang lebih ringan dan tersebar secara geografis. API yang tersedia lebih dekat ke standar Web Platform seperti Request, Response, fetch, URL, Headers, dan Web Crypto. Namun akses ke API khas Node dibatasi atau tidak tersedia.

Dalam praktiknya, keputusan runtime biasanya dibuat per kebutuhan endpoint atau komponen server tertentu, bukan selalu seluruh aplikasi. Karena itu, penting memahami beban kerja apa yang paling cocok untuk masing-masing.

Perbedaan utama: Edge Runtime vs Node.js Runtime

1. Model eksekusi dan lokasi

Edge Runtime dirancang untuk dieksekusi lebih dekat ke pengguna. Artinya, request dari pengguna di Singapura bisa diproses di region yang dekat, dan pengguna di Eropa bisa dilayani dari titik yang berbeda. Tujuan utamanya adalah mengurangi round-trip latency untuk pekerjaan yang singkat.

Node.js Runtime biasanya berjalan pada region server tertentu atau lingkungan serverless berbasis Node. Walau banyak platform mendukung multi-region, model ini secara umum tidak se-terdistribusi edge untuk eksekusi request yang sangat dekat dengan pengguna akhir.

2. Batasan API

Ini adalah pembeda paling penting.

Di Node.js Runtime, Anda bisa menggunakan API Node standar, misalnya:

  • fs untuk baca/tulis file
  • path
  • stream
  • crypto versi Node
  • net dan library yang membuka koneksi TCP langsung
  • driver database native tertentu

Di Edge Runtime, Anda harus berpikir seperti berada di lingkungan Web Worker atau server ringan berbasis Web API. Umumnya Anda dapat menggunakan:

  • fetch
  • Request / Response
  • URL
  • Headers
  • ReadableStream
  • crypto.subtle atau Web Crypto API

Namun, Anda tidak bisa mengandalkan modul seperti fs atau package yang secara implisit mengakses API internal Node.

Aturan praktis: jika package npm Anda butuh modul built-in Node atau native binding, anggap dulu package itu tidak aman untuk edge sampai terbukti sebaliknya.

3. Cold start

Cold start adalah waktu tambahan saat runtime perlu dipersiapkan sebelum menangani request pertama setelah periode idle atau saat instance baru dibuat.

Edge Runtime biasanya dipilih untuk startup yang ringan dan respons cepat pada beban kerja sederhana. Karena eksekusinya kecil dan dekat pengguna, edge sering cocok untuk operasi singkat seperti redirect, validasi token sederhana, personalisasi ringan, atau rewrite URL.

Node.js Runtime bisa memiliki overhead inisialisasi yang lebih besar, terutama jika aplikasi atau route Anda memuat banyak dependency, membuat koneksi database, atau menjalankan proses berat saat startup. Namun ini bukan berarti Node selalu lambat; pada workload yang tepat dan deployment yang baik, Node tetap sangat efektif. Hanya saja, beban inisialisasi biasanya lebih terasa dibanding edge untuk request mikro.

4. Latency global

Untuk pengguna global, Edge Runtime unggul ketika pekerjaan yang dilakukan memang bisa selesai di edge tanpa harus memanggil layanan jauh di region lain. Kalau request diproses di edge tapi tetap harus menunggu database yang hanya ada di satu region jauh, keunggulan latencynya bisa berkurang drastis.

Contoh:

  • Bagus untuk edge: redirect berdasarkan negara, A/B test ringan, validasi bot sederhana, pengecekan session cookie, geolocation header processing.
  • Kurang efektif di edge: query database utama yang hanya ada di satu region, pembuatan PDF, transcoding file, ORM berat, pemrosesan data besar.

Dengan kata lain, edge mempercepat compute yang dekat pengguna, tetapi tidak bisa menghapus latency ke backend lain yang tetap jauh.

5. Kompatibilitas package

Kompatibilitas library sering menjadi faktor penentu.

Node.js Runtime kompatibel dengan mayoritas package server-side di ekosistem npm, terutama yang dirancang untuk backend tradisional. Ini penting jika aplikasi Anda memakai:

  • ORM tertentu
  • SDK cloud yang bergantung pada API Node
  • library image processing
  • package autentikasi lama
  • library observability yang memakai hook Node

Edge Runtime lebih selektif. Package yang aman dipakai di edge biasanya:

  • murni JavaScript
  • tidak mengakses API Node
  • tidak bergantung pada native addon
  • bisa berjalan dengan Web API standar

Kesalahan umum adalah mengimpor helper yang terlihat sederhana, tetapi ternyata helper tersebut mengimpor dependency lain yang memakai fs atau modul Node. Hasilnya build gagal atau route tidak bisa dieksekusi di edge.

6. Akses filesystem

Node.js Runtime mendukung akses ke filesystem sesuai lingkungan deployment. Pada server persisten, Anda mungkin bisa membaca file lokal. Pada serverless, akses file tetap ada untuk artefak yang dibundel, tetapi Anda tidak boleh menganggap disk lokal sebagai penyimpanan persisten untuk state aplikasi.

Edge Runtime secara praktik bukan tempat untuk logika yang bergantung pada filesystem. Jika Anda perlu membaca template file, memproses file lokal, atau berinteraksi dengan library yang mengakses disk, pilih Node.js runtime.

Contoh implementasi runtime di Next.js

Di route handler Next.js, Anda bisa menyatakan runtime secara eksplisit.

Route ringan di Edge Runtime

export const runtime = 'edge'

export async function GET(request) {
  const country = request.headers.get('x-vercel-ip-country') || 'unknown'

  return new Response(
    JSON.stringify({ country, edge: true }),
    {
      headers: { 'content-type': 'application/json' }
    }
  )
}

Contoh ini cocok karena hanya membaca header request dan mengembalikan respons kecil. Tidak ada kebutuhan filesystem, ORM berat, atau API Node.

Route berat di Node.js Runtime

export const runtime = 'nodejs'

import { readFile } from 'node:fs/promises'
import path from 'node:path'

export async function GET() {
  const filePath = path.join(process.cwd(), 'templates', 'report.json')
  const content = await readFile(filePath, 'utf8')

  return Response.json({
    runtime: 'nodejs',
    templateSize: content.length
  })
}

Route ini jelas membutuhkan Node.js karena memakai fs dan path.

Studi kasus: middleware ringan di edge, proses berat di node

Pola arsitektur yang sangat umum adalah:

  1. Middleware di edge untuk keputusan cepat sebelum request masuk lebih jauh.
  2. Route handler atau backend process di Node.js untuk pekerjaan kompleks.

Bagian 1: Middleware ringan di edge

Misalnya Anda ingin:

  • memblokir bot tertentu
  • mengalihkan pengguna ke locale yang sesuai
  • mengecek keberadaan session cookie
  • menambahkan header tracing sederhana

Middleware adalah kandidat ideal untuk edge karena logikanya kecil dan dieksekusi sebelum request mencapai route utama.

import { NextResponse } from 'next/server'

export function middleware(request) {
  const session = request.cookies.get('session')?.value
  const pathname = request.nextUrl.pathname

  if (!session && pathname.startsWith('/dashboard')) {
    const loginUrl = new URL('/login', request.url)
    loginUrl.searchParams.set('from', pathname)
    return NextResponse.redirect(loginUrl)
  }

  const response = NextResponse.next()
  response.headers.set('x-runtime-layer', 'edge-middleware')
  return response
}

export const config = {
  matcher: ['/dashboard/:path*']
}

Mengapa edge cocok? Karena middleware ini hanya membaca cookie, mengecek path, lalu redirect bila perlu. Tidak perlu query database kompleks atau memuat dependency besar.

Bagian 2: Proses berat di Node.js Runtime

Setelah pengguna lolos middleware, route Node.js bisa menangani pekerjaan inti seperti:

  • query database dengan ORM
  • generasi laporan
  • akses filesystem atau template
  • integrasi SDK pihak ketiga yang membutuhkan API Node
export const runtime = 'nodejs'

import { generateMonthlyReport } from '@/lib/report-service'

export async function POST(request) {
  const body = await request.json()
  const result = await generateMonthlyReport({
    accountId: body.accountId,
    month: body.month
  })

  return Response.json({
    ok: true,
    reportId: result.id,
    generatedAt: result.generatedAt
  })
}

Pemisahan ini baik karena setiap runtime dipakai sesuai kelebihannya. Edge menangani keputusan cepat yang sensitif terhadap latency geografis, sedangkan Node menangani proses berat dengan kompatibilitas library yang lebih luas.

Kapan sebaiknya memilih Edge Runtime?

  • Anda butuh respons cepat untuk pengguna global.
  • Logika request sangat ringan dan singkat.
  • Anda hanya butuh Web API seperti fetch, Headers, Request, Response.
  • Anda ingin menjalankan middleware, redirect, rewrite, auth gate sederhana, atau personalisasi berbasis header/cookie.
  • Dependency yang dipakai aman untuk edge dan tidak menggunakan API Node.

Contoh use case ideal:

  • redirect berdasarkan geografi
  • rate limiting ringan berbasis header atau token
  • bot filtering sederhana
  • eksperimen A/B dengan cookie
  • session presence check sebelum route berat dipanggil

Kapan sebaiknya memilih Node.js Runtime?

  • Anda membutuhkan kompatibilitas package npm yang luas.
  • Anda memakai ORM, driver database tertentu, atau SDK yang bergantung pada API Node.
  • Anda perlu akses filesystem.
  • Anda menjalankan proses berat seperti pembuatan dokumen, parsing file besar, image processing, atau komputasi server-side yang lebih kompleks.
  • Anda membutuhkan integrasi backend tradisional yang sulit dijalankan di edge.

Contoh use case ideal:

  • proses pembayaran backend yang memakai SDK Node tertentu
  • webhook handler kompleks
  • render atau generate PDF
  • ekspor data CSV besar
  • proses ETL ringan atau agregasi data server-side

Kesalahan umum dan tips debugging

1. Memaksa package Node berjalan di edge

Jika build gagal atau route edge error saat runtime, cek dependency tree. Sering kali masalahnya bukan file utama, tetapi import transitif dari package lain.

Tips: pisahkan utility khusus Node ke file terpisah dan jangan diimpor dari kode edge.

2. Mengira edge otomatis lebih cepat untuk semua kasus

Kalau route edge tetap memanggil database tunggal di region jauh, total latency bisa tetap tinggi. Optimalkan arsitektur data, bukan hanya lokasi compute.

3. Menyimpan state di filesystem lokal

Baik di serverless maupun edge, asumsi disk lokal persisten adalah jebakan. Pakai object storage, database, cache terkelola, atau KV store sesuai kebutuhan.

4. Mengabaikan observability

Pastikan Anda punya logging, tracing, dan error reporting yang kompatibel dengan runtime yang dipakai. Beberapa alat observability punya dukungan berbeda antara edge dan node.

5. Menaruh logika berat di middleware

Middleware sebaiknya tetap kecil. Jika middleware mulai memuat banyak dependency, memanggil banyak layanan, atau memproses data besar, Anda sedang mengikis keuntungan edge.

Checklist pemilihan runtime

Gunakan checklist berikut sebelum menentukan runtime:

  • Apakah logika ini harus sedekat mungkin dengan pengguna?
    Jika ya, pertimbangkan edge.
  • Apakah pekerjaan ini sangat ringan dan singkat?
    Jika ya, edge biasanya cocok.
  • Apakah saya butuh modul Node seperti fs, path, net, atau library native?
    Jika ya, pilih Node.js runtime.
  • Apakah dependency npm saya sepenuhnya kompatibel dengan Web API?
    Jika tidak yakin, lebih aman mulai dari Node.js runtime.
  • Apakah route ini mengakses database atau service yang hanya ada di satu region?
    Jika ya, manfaat edge mungkin terbatas.
  • Apakah saya sedang membangun middleware, auth gate sederhana, redirect, atau personalization ringan?
    Edge adalah kandidat kuat.
  • Apakah saya sedang menjalankan proses berat, ekspor data, image/PDF processing, atau integrasi backend kompleks?
    Node.js runtime lebih tepat.
  • Mana yang lebih penting untuk kasus ini: kecepatan geografis atau kompatibilitas library?
    Jika prioritas utama adalah latency global untuk logika ringan, pilih edge. Jika prioritas utama adalah ekosistem dan fleksibilitas server, pilih Node.

Kesimpulan

Tidak ada runtime yang selalu lebih baik. Edge Runtime unggul untuk logika ringan yang perlu dijalankan dekat pengguna dengan latensi serendah mungkin, sementara Node.js Runtime unggul dalam fleksibilitas, kompatibilitas package, akses filesystem, dan proses backend yang lebih kompleks.

Untuk banyak aplikasi Next.js 16, strategi terbaik justru bukan memilih salah satu secara mutlak, tetapi menggabungkan keduanya: gunakan edge untuk middleware dan keputusan awal yang cepat, lalu delegasikan pekerjaan berat ke Node.js runtime. Dengan pendekatan ini, Anda mendapatkan manfaat performa di sisi yang tepat tanpa mengorbankan kompatibilitas teknis.