Migrasi Frontend Laravel ke React: Pelajaran dari DBO
Memimpin migrasi frontend retail bahan bangunan bukan soal ganti framework. Yang menentukan sukses adalah urutan rilis, data yang sudah hidup, dan dashboard yang tidak boleh mati di jam operasional.
Masalahnya bukan “Laravel sudah ketinggalan”
Di PT Depoguna Bangunan Online saya memimpin pekerjaan frontend untuk ekosistem retail bahan bangunan. Ada toko, salesman, dan dashboard manajer. Stack lama berbasis Laravel sudah cukup untuk menampilkan halaman. Yang mulai pecah adalah kecepatan iterasi: setiap perubahan UI menarik template, query, dan alur bisnis yang sudah saling terkait.
Orang sering menyarankan rewrite total. Itu terdengar bersih di slide. Di lapangan, rewrite total berarti membekukan fitur selama berbulan-bulan sementara gudang tetap menerima order. Saya menolak pendekatan itu.
Mulai dari permukaan yang paling sering dipakai
Manager App di mngr.dbo.id adalah tempat keputusan harian: stok, order masuk, kinerja salesman. Kalau halaman itu lambat atau salah hitung, orang di lapangan menelepon, bukan membuat tiket Jira. Jadi migrasi dimulai dari permukaan yang paling terlihat dan paling berisiko, bukan dari “fondasi yang sempurna”.
Kami memisahkan UI ke React secara bertahap, sementara Laravel tetap menjadi sumber data. Pendekatan ini tidak elegan. Ada masa di mana dua cara merender halaman hidup berdampingan. Tetapi pengguna tidak peduli elegan. Mereka peduli tombol terima order tetap ada besok pagi.
Tiga hal yang baru kelihatan setelah masuk ke data nyata
- Status order tidak linear. Diagram alur di dokumen selalu lebih rapi daripada order yang dibatalkan sebagian, dikirim pecah, atau dikoreksi setelah jam gudang tutup.
- Angka di dashboard adalah janji. Selisih kecil antara stok di layar dan stok di rak merusak kepercayaan lebih cepat daripada bug visual.
- Perangkat pengguna tidak seragam. Dashboard yang indah di laptop saya bisa terasa sempit di layar staf yang membuka banyak tab sambil menerima telepon.
Yang saya bawa ke proyek berikutnya
Migrasi frontend yang sehat punya kontrak data yang jelas sebelum punya desain baru. Saya belajar menuliskan: field mana yang wajib, kapan angka dihitung di server, dan apa yang terjadi jika request gagal di tengah submit. Tanpa itu, React hanya memindahkan kekacauan ke file yang lebih modern.
Saya juga belajar membatasi lingkup rilis. Satu alur yang benar-benar selesai lebih berharga daripada setengah aplikasi yang “hampir sama dengan yang lama”. Tim yang tidak sabar ingin menunjukkan rewrite. Pengguna ingin menunjukkan bahwa order kemarin tidak hilang.
Framework baru tidak memperbaiki proses bisnis yang belum ditulis dengan jujur.
Kesimpulan
Jika Anda memimpin migrasi serupa, jangan mulai dari perdebatan Tailwind versus Blade. Mulai dari satu pekerjaan yang orang lakukan setiap hari, ukur apakah pekerjaan itu tetap benar setelah rilis, baru perluas. Itu pelajaran paling mahal yang saya bawa dari DBO, dan saya masih memakainya saat merapikan produk lain.