Dua Cara Mengirimkan Frontend: File Statis atau Server yang Berjalan

Saat Anda mulai membangun aplikasi frontend, satu pertanyaan akan membentuk seluruh pipeline deployment Anda lebih dari pilihan framework apa pun: apakah aplikasi ini membutuhkan server yang tetap hidup, atau bisa hidup sebagai folder berisi file?

Ini bukanlah perdebatan arsitektur teoretis. Ini adalah keputusan praktis yang menentukan bagaimana Anda membangun, di mana Anda melakukan deploy, apa yang bisa salah, dan bagaimana Anda memperbaikinya.

Frontend Statis: File yang Berbicara Sendiri

Bayangkan Anda sedang membangun halaman profil perusahaan, situs dokumentasi, atau halaman arahan pemasaran. Anda menulis beberapa HTML, menambahkan CSS, menyisipkan beberapa gambar, dan mengunggahnya ke suatu tempat. Browser mengunduh file-file tersebut dan merendernya. Selesai.

Itulah frontend statis. Semua yang dibutuhkan browser sudah siap saat waktu build. HTML, CSS, JavaScript, font, gambar — semuanya menjadi file yang bisa diletakkan di server web dasar, CDN, atau bucket S3. Tidak ada proses server yang berjalan setelah deployment. Tidak perlu menunggu runtime untuk memulai. File-file itu hanya duduk di sana, menunggu untuk disajikan.

Namun statis bukan berarti sederhana. Aplikasi React atau Vue yang mengambil data dari API tetap bisa dibangun menjadi file statis. Perbedaannya adalah data tidak muncul sampai browser menjalankan JavaScript dan melakukan panggilan API. Ini disebut client-side rendering. HTML awal mungkin hanya berupa kerangka, dan konten asli terisi setelah halaman dimuat.

Pipeline untuk frontend statis sangat sederhana:

  1. Jalankan perintah build.
  2. Kumpulkan file output.
  3. Unggah ke penyimpanan atau CDN.

Tidak perlu restart server. Tidak perlu health check. Tidak perlu menunggu proses menjadi siap. Deployment bisa sesederhana mengganti file di bucket atau memperbarui pointer CDN. Jika ada yang salah, Anda cukup kembali ke file sebelumnya. Ini cepat, murah, dan sulit rusak.

Frontend SSR: Halaman yang Dimasak Sesuai Permintaan

Sekarang pertimbangkan situs e-commerce yang menampilkan harga real-time, ketersediaan stok, dan rekomendasi yang dipersonalisasi. Jika Anda membangun ini sebagai file statis, pengguna akan melihat data basi sampai browser menjalankan JavaScript dan mengambil informasi terbaru. Keterlambatan itu bisa mengurangi penjualan, membingungkan pelanggan, dan membuat aplikasi terasa lamban.

Di sinilah server-side rendering (SSR) berperan. Saat pengguna meminta halaman, server mengambil data terbaru, merender HTML, dan mengirimkan halaman yang sudah terbentuk sempurna ke browser. Pengguna melihat konten segera, tanpa menunggu JavaScript dimuat dan dijalankan.

SSR berarti frontend Anda bukan lagi sekadar file. Ini adalah aplikasi yang berjalan dan membutuhkan server, dependensi, variabel lingkungan, dan urutan startup yang tepat. Pipeline sekarang lebih mirip dengan deployment backend:

  1. Bangun aplikasi menjadi kode siap-server.
  2. Instal dependensi runtime.
  3. Konfigurasikan variabel lingkungan untuk lingkungan target.
  4. Mulai proses server atau deploy ke dalam container.
  5. Jalankan health check untuk memastikan server menerima permintaan.
  6. Arahkan lalu lintas ke versi baru.
  7. Pantau kesalahan setelah peralihan.

Jika ada yang salah, rollback berarti mengembalikan versi server, bukan sekadar menukar file. Anda perlu menangani koneksi database, status sesi, dan invalidasi cache. Ini lebih kompleks, tetapi diperlukan saat pengguna membutuhkan data segar di setiap muatan halaman.

Jalan Tengah: Static Site Generation

Ada pendekatan hibrida yang disebut static site generation (SSG). Ini terlihat seperti SSR saat waktu build, tetapi berperilaku seperti situs statis saat runtime. Rendering terjadi sekali selama build, bukan pada setiap permintaan. Hasilnya adalah sekumpulan file HTML yang sudah di-render sebelumnya yang bisa disajikan secara statis.

SSG bekerja dengan baik untuk konten yang tidak berubah setiap detik. Posting blog, halaman dokumentasi, halaman produk yang diambil dari CMS — ini bisa di-render saat waktu build dan disajikan sebagai file statis. Pengguna mendapatkan muatan halaman yang cepat, dan Anda menghindari pengelolaan runtime server.

Namun SSG memiliki trade-off. Jika konten Anda sering berubah, Anda perlu membangun ulang dan melakukan deploy ulang seluruh situs. Untuk blog dengan satu posting baru per minggu, itu tidak masalah. Untuk situs e-commerce dengan pembaruan inventaris setiap menit, SSG menjadi tidak praktis.

Artinya bagi Pipeline Anda

Pilihan antara statis, SSR, dan SSG bukan hanya tentang arsitektur. Ini tentang seberapa sering konten Anda berubah, seberapa cepat pengguna perlu melihat pembaruan, dan seberapa besar beban operasional yang bisa ditangani tim Anda.

Berikut cara cepat untuk memikirkannya:

Diagram di bawah memandu keputusan dan menunjukkan pipeline yang sesuai untuk setiap jalur.

flowchart TD A[Apakah aplikasi butuh server?] -->|Tidak| B[Frontend Statis] A -->|Ya| C[Konten berubah terus-menerus?] C -->|Tidak| D[SSG - Static Site Generation] C -->|Ya| E[SSR - Server-Side Rendering] B --> F[Build file statis] F --> G[Unggah ke CDN / S3] G --> H[Sajikan file] D --> I[Build & pre-render HTML] I --> J[Unggah output statis] J --> K[Sajikan sebagai file statis] E --> L[Build kode server] L --> M[Instal dependensi runtime] M --> N[Mulai proses server] N --> O[Health check & arahkan lalu lintas]
  • Statis: Konten jarang berubah. Pengguna bisa mentolerir sedikit keterlambatan sebelum data muncul. Anda menginginkan deployment yang sesederhana mungkin.
  • SSR: Konten berubah terus-menerus. Pengguna membutuhkan data segar di setiap muatan halaman. Anda bersedia mengelola runtime server.
  • SSG: Konten berubah secara periodik. Anda menginginkan muatan halaman cepat tanpa menjalankan server. Anda bisa membangun ulang situs saat konten diperbarui.

Pipeline Anda harus mengikuti keputusan ini, bukan melawannya. Jika Anda memilih statis, jangan menambahkan manajemen server yang tidak perlu. Jika Anda memilih SSR, jangan berpura-pura itu hanya folder berisi file.

Daftar Periksa Praktis Sebelum Memutuskan

Sebelum Anda berkomitmen pada strategi deployment, jawab pertanyaan-pertanyaan ini:

  • Seberapa sering konten di halaman ini berubah? Setiap detik, setiap jam, atau setiap minggu?
  • Bisakah pengguna menunggu JavaScript mengambil data setelah halaman dimuat, atau mereka membutuhkan konten segera?
  • Apakah tim Anda memiliki kapasitas untuk mengelola runtime server, termasuk pemantauan, restart, dan rollback?
  • Seberapa cepat Anda perlu pulih dari deployment yang buruk? Menukar file lebih cepat daripada me-restart server.
  • Apakah halaman yang sama akan terlihat berbeda untuk pengguna yang berbeda berdasarkan sesi atau lokasi mereka?

Jawaban Anda akan mengarahkan Anda ke pendekatan yang tepat. Jangan biarkan framework atau hype yang memutuskan untuk Anda.

Intisari Konkret

Frontend statis adalah folder berisi file. Frontend SSR adalah aplikasi yang berjalan. Perlakukan mereka secara berbeda di pipeline Anda, dan Anda akan menghindari kompleksitas yang tidak perlu atau melewatkan langkah-langkah kritis. Mulailah dengan pendekatan paling sederhana yang memenuhi kebutuhan pengguna akan konten segar, dan hanya tambahkan server-side rendering saat data menuntutnya.