Belajar Fullstack Developer - Fullstack Architecture
Membandingkan empat arsitektur fullstack utama — monolith, server-rendered, SPA+API, dan serverless — lengkap dengan kelebihan, kekurangan, serta kriteria praktis untuk memilih arsitektur yang tepat bagi produk nyata.
#Pendahuluan
Setelah di episode 1 kita memahami peran fullstack sebagai pemilik fitur end-to-end, pada episode ini kita memutuskan di mana fitur itu hidup: arsitektur aplikasi. Pilihan arsitektur adalah keputusan paling mahal dalam sebuah produk — karena menggantinya di kemudian hari jauh lebih sulit daripada mengganti framework atau database.
Episode ini membandingkan empat arsitektur fullstack utama yang umum dipakai: monolith, server-rendered, SPA+API, dan serverless. Tidak ada arsitektur yang "paling benar" — yang ada adalah arsitektur yang paling cocok dengan konteks produk: tahap, tim, trafik, dan cara pengguna memakainya.
#Peta Empat Arsitektur
#1. Monolith: Satu Aplikasi, Semua di Dalam
Semua lapisan — UI, API, business logic, akses database — hidup dalam satu proses deploy. Ini adalah arsitektur default untuk mayoritas produk, dan sering diejek secara tidak adil.
| Kelebihan | Kekurangan |
|---|---|
| Sederhana: satu repo, satu deploy, satu proses | Bisa jadi besar dan sulit dipahami |
| Data lokal, tanpa latency antar layanan | Skala hanya bisa vertikal (atau replikasi baca) |
| Transaksi database mudah dijamin | Deploy satu fitur berarti deploy semuanya |
Kesalahpahaman umum: monolith itu "buruk". Faktanya, mayoritas startup yang sukses di 2026 masih berjalan di monolith — karena biaya operasional dan kecepatan pengiriman jauh lebih penting daripada kepura-puraan skalabilitas. Migrasi ke microservice dilakukan saat monolith memang terbukti menjadi hambatan, bukan sebagai tren.
#2. Server-Rendered: HTML dari Server
Arsitektur klasik yang hidup kembali lewat meta-framework: server merender HTML lengkap setiap request, lalu mengirimnya ke browser. Ini pola default Next.js App Router (SSR/SSG) dan framework Rails/Django/Laravel.
Kelebihannya: SEO baik, first load cepat, dan logika sensitif (auth, secrets) tidak bocor ke client. Kekurangannya: setiap navigasi bergantung pada server, dan interaktivitas rumit butuh lapisan client tambahan.
#3. SPA + API: Dua Proyek Terpisah
Browser memuat aplikasi JavaScript (SPA), lalu berkomunikasi dengan API terpisah (REST/GraphQL). Ini pola klasik React/Vue + Express/NestJS.
| Kelebihan | Kekurangan |
|---|---|
| Interaktivitas tinggi, transisi mulus | SEO dan first load lebih sulit |
| Frontend dan backend bisa dikembangkan paralel | Dua codebase, dua pipeline, dua tim |
| API bisa dipakai banyak client (mobile, third-party) | Over-fetching, auth harus dipikirkan dua sisi |
SPA+API masih menjadi pilihan tepat saat memang punya client ganda (web + mobile) atau API publik yang dikonsumsi pihak ketiga. Untuk sekadar web app internal, biayanya sering tidak sebanding.
#4. Serverless: Tanpa Server yang Kalian Kelola
Fungsi dijalankan on-demand di cloud atau edge, diskalakan otomatis, dan kalian hanya membayar per eksekusi. Ini cocok untuk beban yang tidak menentu atau global dengan latensi rendah.
| Kelebihan | Kekurangan |
|---|---|
| Skala otomatis, tanpa provisioning | Cold start bisa terasa di fungsi Java/Node besar |
| Billing per eksekusi (murah saat idle) | Debugging lebih sulit, batas runtime & memory |
| Edge deployment: dekat dengan pengguna | Stateful session dan WebSocket butuh desain khusus |
Serverless bukan pengganti server — ia adalah alat untuk beban tertentu. Episode 18 membedah serverless & edge secara penuh.
#Kriteria Praktis Memilih Arsitektur
Jangan memilih arsitektur dari tren. Gunakan empat pertanyaan berikut:
- Berapa besar tim? Tim 1-5 orang dan satu produk → monolith/server-rendered. Lebih hemat konteks.
- Siapa konsumennya? Hanya web → server-rendered. Web + mobile + third-party → SPA+API.
- Bagaimana pola trafiknya? Menentu → server selalu. Spiky/global → pertimbangkan serverless.
- Seberapa penting SEO? Sangat penting → server-rendered. Internal app → SPA bebas.
Note
Poin kuncinya: arsitektur bisa berevolusi. Banyak produk mulai dari monolith server-rendered, lalu menambahkan lapisan API saat punya mobile app, dan memindahkan sebagian beban ke serverless saat trafik spike. Jangan over-engineer di hari pertama — optimalkan yang terbukti, bukan yang dibayangkan.
#Rekomendasi untuk Series Ini
Sepanjang series ini kita memakai satu pola utama: meta-framework Next.js dalam mode server-rendered + server actions, dengan database PostgreSQL. Alasannya:
- Satu codebase penuh (TypeScript end-to-end) — selaras dengan prinsip fullstack 2026.
- Konsep yang dipelajari (ORM, auth, caching, testing, deploy) bisa dipindahkan ke arsitektur lain.
- Kompleksitas serverless/edge kita masukkan sebagai tema tersendiri di episode 18.
Setiap konsep di episode berikutnya — database, API, auth, deployment — akan kita tempatkan dalam kerangka arsitektur ini, sehingga kalian tahu "di lapisan mana" sebuah masalah hidup.
#Penutup
Inti yang harus dibawa pulang:
- Empat arsitektur: monolith, server-rendered, SPA+API, serverless — masing-masing punya trade-off.
- Monolith sering dilawan tren, tapi tetap pilihan paling rasional untuk mayoritas produk.
- Pilih berdasarkan tim, konsumen, pola trafik, dan kebutuhan SEO — bukan tren.
- Arsitektur bisa berevolusi; hindari over-engineering di awal.
- Series ini memakai Next.js server-rendered + PostgreSQL sebagai pola utama.
Di episode 3 selanjutnya kita mulai praktik sungguhan: membangun fullstack framework dengan Next.js — App Router, Server Components, Server Actions, dan alur data fullstack dalam satu aplikasi. Siapkan terminal kalian, karena kita akan menulis kode yang bisa langsung dijalankan!