Xowlsmith
Kembali ke Jurnal
Build July 17, 2026 · 5 min

Kenapa Kami Meninggalkan Laravel untuk Go

Oleh Solo Mandor, Xowlsmith

Server yang penuh yang membuat kami mulai mencari alternatif. Tapi yang membuat kami bertahan dengan Go sampai sekarang, ternyata bukan lagi soal itu.

Sebelum membangun Merlin, kami sudah cukup lama bekerja dengan Laravel.

Beberapa proyek, satu pola yang sama: begitu mulai membesar, server jadi bottleneck — sesuatu yang kami alami hampir tiap kali beban naik.

Yang ada di kepala waktu itu sederhana: mencari sesuatu yang lebih ringan, yang membuat server tetap tenang walau trafik naik.

Mengira Ini Cuma Soal Berat

Dari situ kami mulai mencari.

Waktu itu, anggapannya sederhana: cari saja yang lebih ringan dari Laravel, selesai masalah.

Node.js dan NestJS masuk daftar pertama. Alasannya praktis — sudah terbiasa dengan ekosistem JavaScript, jadi kelihatannya jadi pilihan paling masuk akal.

Di atas kertas, semua kotak tercentang. Lebih ringan dari Laravel, ekosistemnya besar, dan sudah dikuasai sejak lama.

Kalau Cuma Soal Berat, Kenapa Masih Enggan

Tapi setiap kali serius mempertimbangkan Node, ada sesuatu yang mengganjal.

Kami coba cari tahu lebih jauh, dan ternyata beban Node kurang lebih setara dengan Laravel yang sedang ingin ditinggalkan.

Kalau alasannya cuma soal berat, harusnya di titik ini masalah selesai — Node cukup ringan, ekosistemnya sudah dikuasai, tinggal pindah.

Rasa enggan itu justru tetap bertahan.

Titik Baliknya

Butuh waktu untuk sadar kenapa.

Yang mengganjal ternyata pendekatan kerjanya — masih ada satu lapisan besar yang menentukan bagaimana kode kami harus disusun, sebelum kami sendiri sempat memutuskan.

Selama ini kami kira yang dicari adalah stack yang lebih ringan.

Yang sebenarnya kami temukan adalah cara kerja yang terasa benar-benar milik sendiri: cara kerja kami susun sendiri sesuai kebutuhan produk, di tempat yang biasanya sudah ditentukan lebih dulu oleh sebuah framework.

Pertanyaannya berubah di titik itu, dari "mana yang lebih ringan" menjadi "pendekatan seperti apa yang paling nyaman untuk membangun Merlin".

Begitu pertanyaannya berubah, jawabannya pun ikut berubah.

Yang Akhirnya Ditemukan: Go

Di antara pilihan yang kami lihat saat itu, Go terasa paling dekat dengan yang sedang kami cari.

Kecepatan dan reputasinya cuma bonus yang belakangan makin terasa.

Yang membuat Go bertahan adalah kesederhanaannya. Alur sistem jadi lebih gampang dipahami, karena sebagian besar keputusan ada di kode yang kami tulis sendiri — titik awal debugging pun mulai dari situ.

Dependency yang digunakan pun dipilih sadar satu per satu, sesuai kebutuhan sistem.

Harga yang Kami Bayar

Keputusan ini juga punya harga.

Meninggalkan framework berarti kami juga membangun ulang semua hal kecil yang biasanya sudah disediakan gratis — validasi yang sudah teruji, pola keamanan yang sudah dipikirkan orang lain lebih dulu.

Sebagian dari itu kami rasakan sendiri belakangan, dalam bentuk kesalahan yang harus diperbaiki setelah Merlin berjalan.

Ceritanya panjang, dan pantas menjadi tulisan sendiri — bukan di sini.

Yang Bertahan Sampai Sekarang

Server yang penuh itu yang membuat kami mulai mencari.

Yang kami temukan di ujung pencarian ternyata soal yang sama sekali lain.

Stack yang kami pakai berubah. Cara kami berpikir soal kode yang kami tulis pun ikut berubah — dari sekadar mencari yang muat di server, menjadi mencari cara kerja yang benar-benar terasa milik sendiri.

Masalah yang membuat kami mulai berjalan, bukan alasan yang membuat kami tetap di jalan itu.

AH

Ditulis oleh Solo Mandor Xowlsmith

Software Engineer | System Design • API-Driven Systems • Technology Exploration

Ikuti di LinkedIn →

Baca Juga

Tanya Kebutuhan Sistem