Sebagian besar pengembang perangkat lunak beranggapan bahwa proses penskalaan aplikasi selalu membutuhkan infrastruktur backend, basis data, penyeimbang beban (load balancer), serta pengelolaan operasional pengembangan (DevOps) yang rumit. Namun, sebuah alat berbasis peramban (browser) berhasil dibangun untuk menangani hingga 100.000 pengguna bersamaan tanpa menggunakan satu pun komponen backend tersebut. Seluruh beban komputasi dan logika pemrosesan dijalankan sepenuhnya di dalam peramban web pengguna.
Lonjakan Pengguna Tanpa Dukungan Server Backend
Tantangan ini bermula ketika proyek kalkulator bernama Grow a Garden Calculators pertama kali diluncurkan ke publik. Pada awalnya, perkiraan jumlah pengguna hanya berkisar maksimal 100 orang, atau sekitar 1.000 pengguna jika mendapatkan momentum yang baik. Namun, peluncuran pembaruan permainan pada platform Roblox memicu lonjakan arus pengguna secara masif. Pada hari pertama, sistem mencatat 10.000 pengguna bersamaan; pada hari kedua melonjak menjadi 25.000 pengguna bersamaan; dan pada minggu pertama berhasil mencapai lebih dari 100.000 pengguna aktif bulanan. Seluruh aplikasi tersebut berjalan di atas layanan gratis GitHub Pages tanpa infrastruktur backend, tanpa basis data, dan tanpa server pemrosesan khusus, melainkan hanya memanfaatkan berkas statis HTML dan JavaScript.
Kegagalan skema penskalaan pada arsitektur backend tradisional umumnya bersumber dari hambatan basis data (database bottlenecks), pembatasan laju panggilan antarmuka pemrograman aplikasi (API rate limits), waktu pemrosesan server, keterbatasan memori, serta latensi jaringan. Pendekatan standar industri untuk mengatasi kendala tersebut biasanya dilakukan dengan menambahkan replikasi basis data, lapisan caching seperti Redis atau Memcached, penyeimbang beban, grup penskalaan otomatis (auto-scaling), dan penambahan jumlah server fisik maupun virtual. Meskipun solusi infrastruktur tersebut dapat bekerja, biaya operasionalnya tergolong sangat mahal, memiliki arsitektur yang kompleks, dan rentan terhadap titik kegagalan sistem.
Mekanisme Kerja Arsitektur Frontend-Only
Arsitektur frontend-only mengalihkan seluruh alur kerja ke sisi klien: masukan pengguna diproses secara langsung oleh kode JavaScript di peramban, mengeksekusi kalkulasi secara lokal, dan menampilkan hasil akhir seketika tanpa melibatkan komunikasi backend. Seluruh kumpulan data nilai dibundel secara langsung di dalam aplikasi. Sebagai contoh, data nilai dasar tanaman serta pengganda mutasi (seperti mutasi langka atau legendaris) didefinisikan secara lokal di kode aplikasi. Fungsi kalkulasi kemudian menghitung nilai total berdasarkan bobot dan mutasi yang dipilih secara instan tanpa perlu mengirimkan permintaan API ke server eksternal.
Penerapan pola arsitektur tanpa backend ini memberikan sejumlah keuntungan teknis dan efisiensi biaya. Manfaat tersebut mencakup latensi nol karena komputasi berjalan secara lokal, ketiadaan biaya server melalui pemanfaatan hosting statis gratis di GitHub Pages, serta kapasitas penskalaan tanpa batas karena setiap pengguna memproses beban komputasinya masing-masing. Selain itu, aplikasi dapat tetap berfungsi secara luring setelah pemuatan halaman pertama selesai, tidak membutuhkan pemeliharaan basis data yang rumit, dan terbebas dari kerentanan keamanan yang umumnya timbul pada titik akhir API.
Kriteria Aplikasi yang Cocok untuk Frontend Murni
Pendekatan frontend-only sangat cocok diterapkan apabila aplikasi memenuhi kriteria tertentu, seperti komputasi tanpa status (stateless), data yang bersifat tetap dan tidak berubah per pengguna (immutable), kebutuhan respons seketika (real-time performance), volume konkurensi pengguna yang tinggi, serta anggaran infrastruktur yang sangat terbatas. Jenis proyek yang sangat sesuai mencakup kalkulator, alat konversi, alat perencanaan, gim ringan, dan perangkat analisis langsung. Sebaliknya, aplikasi seperti jejaring sosial, aplikasi percakapan, gim multipemain interaktif, atau sistem apa pun yang mengelola data akun pengguna tetap membutuhkan infrastruktur backend.
Untuk menangani pembaruan data permainan—misalnya ketika pengembang permainan mengubah nilai dasar tanaman—solusi yang digunakan adalah mekanisme kontrol versi data. Berkas manifest versi (data-manifest.json) diperiksa secara asinkron setiap kali halaman dimuat. Jika nomor versi pada berkas manifest lebih baru daripada versi data yang tersimpan di dalam kode peramban pengguna, antarmuka akan memberikan informasi atau anjuran kepada pengguna untuk menyegarkan (refresh) peramban guna memuat nilai data terbaru dari repositori, tanpa perlu melakukan kueri basis data.
Perbandingan Metrik Performa dan Biaya Operasional
Berdasarkan metrik perbandingan performa, pendekatan frontend murni mencatatkan waktu pemuatan awal sekitar 150 milidetik, durasi komputasi di bawah 1 milidetik, kapasitas pengguna bersamaan yang praktis tak terbatas, biaya server nol dolar per bulan, serta tingkat kerumitan sistem yang rendah. Sebaliknya, arsitektur backend konvensional biasanya membutuhkan waktu pemuatan awal 300 milidetik (termasuk permintaan API), waktu kalkulasi 50 hingga 200 milidetik akibat latensi transmisi jaringan, kapasitas 1.000 hingga 10.000 pengguna bersamaan tergantung kapasitas server, biaya operasional 500 hingga 5.000 dolar AS per bulan, serta kompleksitas infrastruktur yang tinggi.
Pada saat pengujian beban nyata dengan 25.000 pengguna aktif mengakses secara bersamaan, GitHub Pages mampu mendistribusikan berkas statis dengan stabil, sementara peramban masing-masing pengguna menjalankan seluruh komputasi kalkulasi secara independen. Beban server tetap tidak berubah karena server hanya bertugas mengirimkan berkas statis HTML dan JavaScript. Tidak ada insiden server crash, tidak ada waktu habis (timeout), tidak ada kendala penskalaan sistem, dan tidak diperlukan penanganan darurat DevOps karena arsitektur tersebut tidak memiliki komponen terpusat yang perlu dinaikkan skalanya.
Batasan dan Tantangan Arsitektur Sisi Klien
Walaupun memiliki banyak keunggulan, arsitektur frontend murni memiliki beberapa batasan yang perlu dipertimbangkan secara realistis. Arsitektur ini tidak mendukung sinkronisasi data antar-pengguna secara langsung (real-time sync), tidak menyediakan fitur personalisasi antarmuka, memiliki keterbatasan dalam pelacakan analitik pengguna, tidak menyediakan sistem akun masuk (login), serta dibatasi oleh besaran memori peramban dalam menampung data. Jika pelacakan penggunaan tetap diperlukan, pengembang dapat menerapkan pencatatan anonim di tingkat klien melalui localStorage peramban atau mengirimkan data agregat ke layanan pencatatan eksternal seperti LogRocket tanpa harus membangun basis data mandiri.
Strategi penerapan arsitektur ini juga sangat sederhana karena tidak memerlukan konfigurasi pipa CI/CD yang kompleks. Pengembang hanya perlu memperbarui data atau kode secara lokal, melakukan git commit, lalu melakukan git push ke repositori utama di GitHub, di mana GitHub Pages atau GitHub Actions akan menerapkannya secara otomatis ke produksi. Apabila di masa mendatang aplikasi Grow a Garden Calculators membutuhkan fitur akun pengguna, pasar transaksi jual-beli, fitur sosial, atau sinkronisasi multipemain waktu nyata, backend minimal dapat ditambahkan secara bertahap tanpa perlu mengubah logika kalkulasi yang sudah berjalan optimal di sisi peramban.