Beberapa waktu lalu saya memutuskan memigrasikan mastrigus.com dari WordPress ke CMS buatan sendiri, ditulis dengan Go satu binary, SQLite sebagai database, tanpa Node.js dan build pipeline terpisah. Alasannya sederhana, WordPress punya banyak lapisan (PHP, MySQL, plugin, tema) yang masing-masing perlu resource dan perawatan sendiri, sementara kebutuhan saya sebenarnya cuma menampilkan artikel, cepat, dan mudah dirawat.
Server yang saya pakai juga bukan VPS bulanan. Saya jalankan di STB (set-top box) Android TV bekas yang sudah di-flash ulang pakai Linux (Armbian) — perangkat yang tadinya cuma nongkrong di rak TV, sekarang jadi home server kecil yang menyalakan beberapa layanan sekaligus, termasuk blog ini.
Masalahnya build Go di STB itu berat
Setup awal saya jalankan CMS ini lewat Docker di STB itu sendiri. Setiap kali ada perubahan kode, container-nya build ulang di STB — menjalankan compiler Go plus compiler C (karena driver database yang saya pakai waktu itu butuh CGO), di atas image dasar yang berisi seluruh toolchain build.
Di laptop/desktop biasa, proses ini kerasa instan. Tapi di STB yang CPU dan RAM-nya jauh di bawah komputer biasa, build seperti ini jadi lambat dan boros — CPU terkuras, dan sebagian resource yang harusnya bisa dipakai layanan lain di STB itu malah habis buat mengompilasi ulang program yang sama setiap kali saya update satu baris kode.
Idenya build di tempat yang kuat, kirim yang sudah jadi
Solusinya ternyata bukan menambah resource di STB, tapi menghilangkan kebutuhan build di STB sama sekali. Go punya kemampuan cross-compile bawaan — bisa mengompilasi program untuk arsitektur lain (STB ini pakai ARM64) langsung dari komputer development, tanpa perlu STB ikut campur sama sekali di proses build.
Satu ganjalan teknis: driver SQLite yang tadinya dipakai butuh CGO (compiler C), yang bikin cross-compile jadi ribet karena butuh toolchain C khusus untuk target ARM64. Setelah diganti ke driver SQLite versi pure-Go (tanpa CGO sama sekali), cross-compile jadi satu perintah biasa dari komputer manapun, langsung menghasilkan satu file binary siap pakai untuk STB.
Alur deploy sekarang jadi jauh lebih sederhana:
- Compile di komputer development untuk target Linux ARM64 — beberapa detik.
- Salin satu file binary itu ke STB.
- Restart service.
Tidak ada lagi compiler, image Docker berisi toolchain build dan proses build yang menyita resource STB. STB cuma perlu menjalankan file yang sudah jadi.
Perubahan pemakaian resource
Setelah pindah ke pola ini, proses yang berjalan di STB cuma satu binary kecil (di bawah 15 MB) yang dijalankan langsung lewat systemd, dengan pemakaian RAM di kisaran 12 MB saat idle. Itu wajar karena image Docker untuk build dibuang sehingga tidak ada proses compiler yang numpang jalan tiap deploy, hasilnya STB jadi lebih lega untuk layanan-layanan lain yang juga jalan di perangkat yang sama.
Yang berubah bukan cuma soal ringan atau tidaknya program saat jalan — dua-duanya sebenarnya sama ringan saat idle. Bedanya ada di proses update-nya: yang tadinya butuh siklus build penuh di perangkat terbatas, sekarang cuma salin-tempel file yang sudah matang.
Prinsipnya
Cerita ini intinya sederhana, kalau perangkat yang menjalankan sesuatu terbatas, jangan paksa perangkat itu mengerjakan tugas berat yang sebenarnya tidak perlu dikerjakan di sana. Pisahkan proses yang berat (build/compile) dari proses yang ringan (menjalankan program jadi), lalu biarkan masing-masing dikerjakan di tempat yang paling cocok.
Ini juga alasan blog ini bisa jalan dengan biaya hosting nyaris nol, bukan karena triknya rumit, tapi karena arsitekturnya sengaja dibuat sederhana dari awal. Buat saya, itu kuncinya, sebelum menambah resource atau upgrade perangkat, cek dulu apakah masalahnya sebenarnya bisa hilang cuma dengan menyederhanakan cara kerjanya.
