NestJS Adalah: Cara Kerja, Kelebihan & Bedanya dari Next.js

Selama bertahun-tahun, JavaScript hanya hidup di dalam browser. Node.js mengubah keadaan itu dengan memindahkan mesin penjalan JavaScript ke sisi server, sehingga satu bahasa pemrograman yang sama bisa dipakai untuk tampilan sekaligus logika di belakangnya.

Kebebasan itu datang dengan satu kekosongan. Node.js — dan Express, pustaka yang paling umum menemaninya — nyaris tidak mengatur apa pun soal susunan berkas Anda. Selama proyek dikerjakan satu orang, kekosongan itu terasa membebaskan. Begitu anggota tim bertambah dan berkas menembus angka ratusan, setiap orang punya definisi "rapi" sendiri.

NestJS adalah framework Node.js yang mengisi kekosongan tersebut dengan menyediakan arsitektur aplikasi bawaan. Ia tidak membuat server Anda lebih cepat; ia membuat susunan kode Anda seragam dan bisa ditebak. Artikel ini membahas cara kerjanya dari dalam, kelebihan dan kekurangannya, serta memisahkannya dari tiga nama lain yang sering tertukar dengannya.

Apa Itu NestJS?

NestJS adalah framework untuk membangun aplikasi sisi server di atas Node.js, yang menyediakan struktur aplikasi siap pakai sehingga kode tetap mudah diuji seiring proyek membesar. Nama resminya Nest; penyebutan "NestJS" maupun "nest js adalah" merujuk pada hal yang sama. Ia dibuat Kamil Mysliwiec, dipublikasikan ke npm pada Mei 2017, dan berlisensi MIT.

Tiga hal membentuk karakternya. Pertama, NestJS tidak menulis ulang lapisan HTTP dari nol — di bawah permukaan ia memakai Express secara bawaan. Kedua, ia ditulis dengan dan sepenuhnya mendukung TypeScript, walau tetap bisa dipakai dengan JavaScript murni. Ketiga, arsitekturnya terbuka mengambil inspirasi dari Angular.

Satu hal perlu ditegaskan sejak awal: NestJS berjalan sepenuhnya di sisi server. Ia tidak menghasilkan halaman web yang tampil di layar pengguna. Keluarannya adalah REST API, layanan GraphQL, koneksi WebSocket, atau layanan microservice yang dipanggil aplikasi lain. Sebagai gambaran ukurannya, repositori resminya mengumpulkan 76.397 bintang GitHub dengan hanya 17 isu terbuka, dan versi stabil terbarunya 11.2.1 yang dirilis 14 Agustus 2026.

NestJS, Next.js, Node.js, dan Google Nest: Empat Nama yang Tertukar

Empat nama ini terdengar mirip, dua di antaranya bahkan hanya beda satu huruf. Memahami perbedaan keempatnya sekarang akan menghemat banyak kebingungan nanti.

Mulai dari arti katanya. Nest artinya sarang dalam bahasa Inggris. Nama resmi framework ini memang Nest, sedangkan penulisan "NestJS" adalah bentuk lazim yang menegaskan bahwa ia hidup di ekosistem JavaScript — dokumentasi resminya menuliskan keduanya berdampingan.

Node.js bukan framework, melainkan runtime (lingkungan tempat program dijalankan). Ia adalah mesin yang membuat berkas JavaScript bisa dieksekusi di luar browser. Tanpa Node.js, NestJS tidak punya tempat berjalan.

NestJS adalah framework backend yang berdiri di atas Node.js: menerima permintaan, memvalidasi data, berbicara dengan basis data, lalu mengembalikan jawaban.

Next.js dibangun di atas React dan mengurus sisi frontend: halaman yang dilihat pengguna, perutean antar-halaman, dan perenderan di server. Nest dan Next tidak saling menggantikan; keduanya justru sering dipakai berdampingan — Next.js di depan, NestJS di belakang.

Google Nest sama sekali bukan perangkat lunak pemrograman, melainkan merek perangkat rumah pintar milik Google seperti termostat dan kamera pengawas. Bila Anda mencari "nest adalah" lalu menemukan artikel tentang pengatur suhu ruangan, inilah penyebabnya.

Karena itu, pertanyaan NestJS vs Next.js sebenarnya salah alamat. Keduanya tidak bersaing memperebutkan pekerjaan yang sama.

Di Atas Express: Cara NestJS Menumpang Framework Lain

Kesalahpahaman berikutnya muncul saat orang membandingkan NestJS vs Express, seolah yang satu menggantikan yang lain. Kenyataannya sebaliknya: proyek NestJS yang Anda buat hari ini menjalankan Express di dalamnya, sebagai lapisan abstraksi yang tetap membuka akses ke API Express asli.

Lapisan penghubungnya disebut adapter (adaptor platform), dan karena penghubung inilah mesin HTTP di bawah NestJS bisa ditukar tanpa mengubah logika aplikasi. Pola menumpang seperti ini adalah ciri khas framework yang mengatur alur, bukan menggantikan pustaka di bawahnya. Selain Express, tersedia adaptor resmi untuk Fastify, yang menurut dokumentasi NestJS sendiri mencatat benchmark hampir dua kali lebih cepat. Lalu kenapa Express tetap jadi bawaan? Alasannya ekosistem — middleware siap pakai untuk Express jauh lebih banyak.

Angka unduhan npm memperlihatkan pilihan yang benar-benar diambil orang. Pada pekan 9–15 Agustus 2026, @nestjs/core diunduh 9,38 juta kali, sementara adaptor @nestjs/platform-fastify hanya 1,33 juta kali. Artinya sekitar satu dari tujuh proyek NestJS yang memakai Fastify, sisanya tetap di Express bawaan. Pindah ke Fastify itu sah, tetapi jangan jadikan langkah pertama — kerjakan saat pengukuran Anda sendiri menunjukkan lapisan HTTP memang sudah jadi penghambat.

Tiga Blok Bangunan: Module, Controller, dan Provider

Seluruh aplikasi NestJS tersusun dari tiga jenis berkas yang sama, berulang-ulang.

Struktur modul NestJS: kotak Module membungkus Controller di kiri, yang meneruskan permintaan ke Provider di kanan.

Module adalah pembungkus fitur. Penandanya adalah decorator atau dekorator — penanda metadata yang ditempel di atas kelas atau metode. Kelas bertanda @Module() mendaftarkan isi fitur lewat empat properti: controllers, providers, imports (modul lain yang dibutuhkan), dan exports (bagian yang boleh dipakai modul lain). Setiap aplikasi punya minimal satu modul akar. Yang penting, modul bersifat menutup diri: sebuah layanan tidak bisa dipakai modul lain kecuali sengaja diekspor. Batas inilah yang mencegah proyek besar menjadi kusut.

Controller adalah pintu masuk permintaan. Tugasnya menerima permintaan HTTP dan menentukan siapa yang mengerjakannya, bukan mengerjakan sendiri. Rutenya ditentukan lewat dekorator:

import { Controller, Get } from '@nestjs/common';

@Controller('artikel')
export class ArtikelController {
  @Get()
  cariSemua(): string {
    return 'Mengembalikan seluruh artikel';
  }
}

Dekorator @Controller('artikel') menetapkan awalan rute, @Get() menandai metode di bawahnya sebagai penangan permintaan GET. Gabungannya mengarahkan GET /artikel ke cariSemua(), yang namanya bebas. Nilai balik berupa objek atau array otomatis menjadi JSON, dengan status bawaan 200 kecuali POST yang memakai 201.

Provider adalah tempat logika sesungguhnya tinggal — kelas layanan, repositori basis data, dan pembantu perhitungan. Pemisahannya dari controller mengikuti semangat yang sama dengan pola MVC: yang menerima permintaan dan yang memproses data sengaja tidak dijadikan satu berkas.

Penghubung ketiganya adalah dependency injection (penyuntikan dependensi). Anda cukup menyebutkan layanan yang dibutuhkan sebuah kelas di konstruktornya, lalu NestJS yang memberikan objeknya — Anda tidak pernah menulis new ArtikelService() sendiri. Manfaatnya paling terasa saat menulis pengujian: layanan asli bisa ditukar versi tiruan tanpa menyentuh controller.

Perjalanan Satu Permintaan HTTP di Dalam NestJS

Guard, pipe, dan interceptor mudah dipahami satu per satu, tetapi urutan kemunculannyalah yang menjelaskan perilaku aplikasi Anda. Urutan itu disebut siklus request (request lifecycle): setiap permintaan yang masuk melewati beberapa pos pemeriksaan dengan urutan tetap sebelum mencapai kode Anda.

Siklus request NestJS: middleware, guard, interceptor, dan pipe dilewati sebelum handler, lalu interceptor arah balik.

Berikut arti tiap pos tersebut:

1. Middleware: berjalan paling awal, sebelum NestJS tahu rute mana yang dituju. Cocok untuk pekerjaan mentah seperti pencatatan atau pembacaan header.
2. Guard: menjawab satu pertanyaan biner, boleh lewat atau tidak. Di sinilah pemeriksaan token dan peran pengguna ditempatkan.
3. Interceptor: membungkus pemanggilan handler dari dua sisi, untuk menyeragamkan bentuk respons, mengukur durasi, atau menyimpan hasil di cache.
4. Pipe: memeriksa dan mengubah data masukan sebelum masuk ke handler. Inilah yang menolak isi permintaan tidak sesuai dan mengembalikan status 400 otomatis.
5. Handler: metode di controller yang memanggil provider — satu-satunya tempat logika bisnis Anda berjalan.
6. Exception filter: menangkap error dari mana pun sepanjang jalur di atas dan menerjemahkannya menjadi respons rapi, misalnya 404 atau 403.

Satu keanehan layak diingat. Guard dan pipe berjalan dari yang paling global ke yang paling spesifik, tetapi interceptor diselesaikan terbalik pada arah pulang: yang terpasang di rute selesai lebih dulu, baru yang global. Penyebabnya, interceptor mengembalikan Observable RxJS sehingga bekerja seperti tumpukan.

Urutan ini juga menjelaskan kesalahan yang sering terjadi pada pemula: menaruh pemeriksaan hak akses di dalam pipe. Karena pipe berjalan setelah guard, permintaan yang seharusnya sudah ditolak justru terlebih dahulu melewati proses validasi data.

Ekosistem Resmi: Database, Autentikasi, dan Microservice

Yang membedakan NestJS dari kerangka kosong adalah kumpulan paket resmi yang dirawat tim intinya. Untuk basis data, tersedia integrasi resmi ke TypeORM, Prisma, Mongoose, dan Sequelize, dengan pasangan PostgreSQL atau MongoDB. Untuk autentikasi, ada pembungkus Passport dengan strategi JWT yang dipasangkan dengan guard untuk membatasi akses per peran pengguna. Untuk dokumentasi API, satu modul Swagger membaca dekorator yang sudah Anda tulis lalu menghasilkan halaman OpenAPI otomatis — isinya ikut berubah setiap kali kode berubah.

Ada pula mode microservice. Di NestJS, sebuah microservice pada dasarnya aplikasi yang memakai lapisan transport selain HTTP, dengan transporter bawaan untuk TCP, Redis, Apache Kafka, RabbitMQ, NATS, dan gRPC. Karena controller, guard, dan pipe yang sama tetap berlaku, memindahkan modul dari layanan HTTP ke layanan berbasis antrean tidak menuntut penulisan ulang logika.

Ekosistemnya juga masih tumbuh. Sejak awal 2025 muncul kebutuhan menjadikan aplikasi NestJS sebagai MCP server (jembatan yang membuat data dan fungsi aplikasi bisa dipanggil agen AI), dan modul komunitas untuk itu bermunculan cepat.

Kelebihan NestJS

1. Struktur seragam lintas proyek: dua aplikasi NestJS dari tim berbeda tetap punya susunan berkas yang mirip, sehingga developer baru bisa menemukan letak sebuah logika tanpa diberi peta lebih dulu.
2. TypeScript sejak baris pertama: proyek hasil generator sudah dikonfigurasi lengkap, dan kesalahan tipe data tertangkap saat kompilasi.
3. Pengujian yang tidak menyakitkan: karena dependensi disuntikkan dari luar, mengganti basis data asli dengan versi tiruan hanya soal mendaftarkan provider pengganti.
4. Kebutuhan umum sudah dijawab paket resmi: validasi, autentikasi, penjadwalan tugas, antrean pekerjaan, cache, dan dokumentasi API tersedia sebagai modul yang dirawat tim inti.
5. Satu basis kode untuk banyak bentuk layanan: aplikasi yang sama melayani permintaan HTTP, koneksi WebSocket, dan pesan dari antrean tanpa tiga gaya penulisan berbeda.
6. Proyeknya terawat: 17 isu terbuka untuk repositori berbintang 76 ribu menunjukkan triase yang ketat, dan rilis perbaikan terbit dalam hitungan pekan.

Kekurangan dan Hal yang Perlu Anda Pertimbangkan

1. Kurva belajar di awal terasa curam: sebelum menulis baris kode yang berguna, Anda perlu memahami dekorator, dependency injection, dan pembagian modul. Bagi yang terbiasa menulis satu berkas Express lalu langsung jalan, minggu pertama akan terasa lambat.
2. Banyak berkas untuk hasil yang sedikit: API dengan tiga endpoint (alamat akses yang dilayani aplikasi) tetap menuntut modul, controller, dan service terpisah — ongkos strukturnya lebih besar daripada manfaatnya.
3. Kepuasan pemakainya bukan yang tertinggi: pada survei State of JS 2025, tingkat kepuasan NestJS berada di 73% — di bawah Hono (95%), Fastify (86%), dan Express (81%).
4. Populasi penggunanya jauh lebih kecil dari Express: Stack Overflow Developer Survey 2025 mencatat NestJS dipakai 6,7% responden, sementara Express 19,9% dan Next.js 20,8%. Ini terasa saat mencari jawaban atas masalah tidak umum, maupun saat merekrut anggota tim.
5. Kompilasi cepat menuntut kompromi: NestJS mendukung SWC yang sekitar 20 kali lebih cepat dari compiler TypeScript bawaan. Namun SWC tidak memeriksa tipe sama sekali, sehingga pemeriksaannya harus dinyalakan terpisah lewat opsi --type-check.
6. Kurang ideal untuk fungsi serverless: aplikasi NestJS memuat seluruh grafik modul saat dinyalakan. Beban itu ringan untuk server yang hidup terus-menerus, tetapi terasa pada model yang menyalakan proses baru tiap permintaan.

Kapan NestJS Sepadan, dan Apa yang Dibutuhkan Servernya

Daripada mengejar daftar best practice lebih dulu, pertanyaan yang lebih berguna adalah kapan struktur NestJS sepadan dengan ongkosnya. Sebagai patokan konkret, NestJS mulai membayar ongkos strukturnya ketika jumlah endpoint melewati sekitar 20, tim beranggotakan tiga orang atau lebih, atau aplikasi direncanakan hidup di atas dua tahun. Di bawah ukuran itu — sebuah webhook, satu layanan integrasi, atau prototipe — Express atau Fastify polos lebih hemat waktu.

Ada satu konsekuensi teknis yang sering terlambat disadari, terutama oleh pembaca berlatar PHP. Aplikasi NestJS berjalan sebagai proses yang hidup terus-menerus dan mendengarkan port tertentu, secara bawaan 3000. Berbeda dari model PHP, tempat setiap permintaan dilayani proses baru yang langsung mati sesudahnya.

Konsekuensinya, tiga hal harus tersedia. Pertama, Node.js versi 20 atau lebih baru. Kedua, kemampuan menjalankan proses latar yang tidak dimatikan sistem. Ketiga, penjaga proses agar aplikasi menyala kembali setelah gagal atau setelah server dinyalakan ulang — umumnya PM2, unit systemd, atau Docker. Sebagian besar paket shared hosting tidak menyediakan ketiganya, walau sebagian panel memang punya menu khusus untuk menjalankan aplikasi Node.js di hosting cPanel dengan batasan proses dan memori yang ketat. Karena itu aplikasi NestJS produksi umumnya diletakkan di VPS atau server mandiri, dengan Nginx di depannya sebagai reverse proxy (penerus permintaan ke port aplikasi). Bila Anda sedang menyiapkan tempatnya, layanan VPS Indonesia memberi akses root untuk memasang Node.js, PM2, maupun Docker sesuai kebutuhan.

Pastikan versi Node.js yang tersedia sebelum menyewa server. NestJS 11 menetapkan Node.js 20 sebagai batas minimum, sementara gambar sistem operasi lama masih kerap membawa versi 18 yang sudah tidak didukung.

Cara Mulai Mencoba NestJS

Cara tercepat merasakan struktur di atas adalah membuat satu proyek kosong. Tiga langkah berikut bukan pengganti tutorial lengkap, tetapi memakan waktu di bawah sepuluh menit.

Langkah #1: Pasang Nest CLI dan Buat Proyek

Nest CLI adalah alat baris perintah resmi untuk membuat dan mengelola proyek. Cara membuat proyek pertama Anda hanya dua perintah — pasang CLI-nya lewat npm, lalu panggil generatornya:

npm i -g @nestjs/cli
nest new proyek-pertama

CLI akan menanyakan package manager yang Anda pakai, membuat folder proyek, lalu memasang dependensinya. Tambahkan opsi --strict untuk pemeriksaan tipe yang lebih ketat sejak awal.

Langkah #2: Kenali Lima Berkas di Dalam src/

Masuk ke folder proyek, jalankan npm run start:dev, lalu buka http://localhost:3000 di browser. Sambil berjalan, perhatikan struktur folder yang dibuatkan CLI — lima berkas di dalam src/:

• main.ts — titik awal aplikasi; di sinilah NestFactory menyalakan pendengar HTTP.
• app.module.ts — modul akar, tempat seluruh modul lain didaftarkan.
• app.controller.ts — controller contoh dengan satu rute.
• app.service.ts — provider contoh dengan satu metode.
• app.controller.spec.ts — berkas pengujian untuk controller tersebut.

Struktur proyek inilah yang akan Anda temui di hampir semua aplikasi NestJS, dan membacanya berurutan memberi gambaran utuh lebih cepat daripada penjelasan konsep mana pun.

Langkah #3: Buat Satu Resource CRUD Lengkap

Setelah struktur dasarnya masuk akal, cobalah generator resource. Satu perintah berikut menghasilkan modul, controller, service, berkas pengujian, dan DTO untuk operasi CRUD lengkap:

nest g resource artikel

CLI akan menanyakan gaya transport yang diinginkan, misalnya REST API atau GraphQL. Buka berkas yang dihasilkan lalu bandingkan dengan penjelasan tiga blok bangunan di atas — pola itulah yang berulang di setiap fitur berikutnya.

Pertanyaan yang Sering Muncul

NestJS digunakan untuk apa? NestJS dipakai untuk membangun sisi belakang aplikasi: REST API, layanan GraphQL, koneksi WebSocket, dan layanan microservice berbasis antrean pesan. Ia paling sering dipakai pada aplikasi bisnis yang dikerjakan tim dan direncanakan tumbuh jangka panjang.

Apakah NestJS sama dengan Next.js? Tidak, keduanya berbeda peran meski namanya hanya beda satu huruf. NestJS bekerja di sisi server menyediakan data dan logika, sedangkan Next.js menghasilkan halaman yang dilihat pengguna. Keduanya justru sering dipakai bersamaan dalam satu produk.

Node.js digunakan untuk apa? Node.js adalah runtime yang membuat kode JavaScript bisa dijalankan di luar browser: di server, di alat baris perintah, atau di proses latar. NestJS, Next.js, dan Express berjalan di atasnya — ketiganya pustaka, Node.js mesinnya.

Apakah NestJS itu frontend atau backend? NestJS sepenuhnya backend. Ia berjalan di server, tidak menghasilkan tampilan yang dilihat pengguna, dan keluarannya berupa data atau respons yang dikonsumsi aplikasi lain. Untuk sisi frontend, Anda tetap membutuhkan React, Vue, Next.js, atau kerangka tampilan lain.

Apakah NestJS wajib memakai TypeScript? Tidak wajib. NestJS mendukung JavaScript murni lewat Babel, tetapi Anda kehilangan keuntungan pemeriksaan tipe yang justru menjadi alasan utama orang memilihnya. Dalam praktiknya, hampir semua proyek NestJS ditulis dengan TypeScript.

Berapa versi NestJS terbaru? Versi stabil terbaru saat artikel ini ditulis adalah 11.2.1, dirilis 14 Agustus 2026, sementara seri 11 dimulai pada 16 Januari 2025. Seri 12 sudah tersedia dalam bentuk pra-rilis alpha tetapi belum stabil, sehingga proyek produksi sebaiknya tetap di seri 11.

Apakah NestJS bisa berjalan di shared hosting? Umumnya tidak nyaman. NestJS membutuhkan proses Node.js yang hidup terus-menerus, sementara sebagian besar paket shared hosting membatasi proses latar dan pemakaian memori. Untuk produksi, VPS atau server mandiri lebih tepat.

Kesimpulan

NestJS adalah framework Node.js yang menjual satu hal utama: struktur. Ia tidak membuat aplikasi Anda lebih cepat dari Express; di bawah permukaan ia justru memakai Express. Yang ia berikan adalah susunan kode yang seragam, mudah diuji, dan tetap terbaca setelah puluhan fitur bertambah.

Harga kerapian itu adalah kurva belajar di awal dan sejumlah berkas yang terasa berlebihan untuk proyek kecil. Ia sepadan ketika aplikasi Anda punya banyak endpoint, dikerjakan lebih dari satu orang, dan direncanakan hidup lama. Untuk prototipe singkat, framework yang lebih ringan biasanya lebih cepat.

Semoga artikel ini membantu.