Studi Kasus: Membangun Sistem Logistik Enterprise dengan Laravel & React
Dari semua proyek yang pernah saya kerjakan, sistem logistik enterprise adalah yang paling menantang sekaligus paling banyak mengajari saya tentang membangun perangkat lunak berskala besar. Sistem ini mengelola seluruh siklus pengiriman: dari order masuk, penugasan driver, pembuatan manifest, pelacakan real-time, hingga pencatatan pembayaran. Artikel ini membedah keputusan teknis di baliknya.
Tantangan: Skala dan Kompleksitas Peran
Angka mentahnya saja sudah menggambarkan skalanya: 72 model Eloquent, 71 migrasi, lebih dari 100 endpoint API, dan 155 halaman React. Yang membuatnya rumit bukan sekadar jumlahnya, tapi kenyataan bahwa sistem harus melayani 9+ role pengguna yang berbeda — admin, operasional, driver, keuangan, sales, hingga vendor — masing-masing dengan hak akses dan alur kerja tersendiri.
Arsitektur: Laravel 11 + React via Inertia.js
Kami memilih Laravel 11 di sisi server dan React 18 di sisi antarmuka, dijembatani oleh Inertia.js. Kenapa Inertia, bukan REST API terpisah + SPA?
- Tidak perlu membangun dan memelihara dua aplikasi terpisah beserta lapisan autentikasi ganda
- Routing dan otorisasi tetap terpusat di Laravel — satu sumber kebenaran
- Developer bisa fokus ke fitur, bukan ke sinkronisasi state antara backend dan frontend
Untuk kebutuhan integrasi eksternal (mobile app driver, mitra), kami tetap menyediakan REST API terpisah — dan pola yang saya pakai di sana persis seperti yang saya tulis di panduan membangun REST API dengan Laravel.
Menjaga Kode Tetap Terkelola
Pada skala 72 model, disiplin arsitektur bukan pilihan, tapi keharusan. Beberapa prinsip yang kami pegang:
- Pemisahan tanggung jawab: Controller ramping, logika bisnis di Service, akses data di Repository
- Modular per domain: order, manifest, CRM, dan keuangan dipisah jelas agar tim bisa bekerja paralel tanpa saling menabrak
- Otorisasi berbasis Policy: setiap aksi role dicek lewat Laravel Policy, bukan pengecekan
ifyang tersebar
Modul Inti
Order & Manifest. Jantung sistem. Order masuk diproses, driver ditugaskan, lalu digabung menjadi manifest untuk pengiriman. Setiap perubahan status memicu event yang menjaga data tetap konsisten.
CRM. Mengelola lead dan prospek pelanggan, lengkap dengan riwayat interaksi dan tahap penjualan.
Keuangan. Mendukung alur persetujuan (approval workflow), pencairan dana vendor, dan integrasi payment gateway.
Integrasi Pihak Ketiga
- Midtrans untuk pembayaran — dengan penanganan webhook yang idempoten agar notifikasi ganda tidak menggandakan transaksi
- Firebase Cloud Messaging untuk notifikasi push ke aplikasi driver
- WhatsApp Business via Qontak untuk notifikasi otomatis ke pelanggan
Pelajaran penting soal integrasi: selalu asumsikan layanan eksternal bisa gagal. Kami membungkus setiap panggilan dengan retry, timeout, dan logging agar satu layanan yang down tidak menjatuhkan seluruh alur.
Performa pada Data Besar
Dengan ribuan order per hari, query yang naif akan cepat menjadi hambatan. Kami banyak mengandalkan eager loading untuk menghindari masalah N+1, indexing yang tepat, dan caching untuk data yang jarang berubah — prinsip yang sejalan dengan apa yang saya bahas di artikel optimasi performa web.
Pelajaran Terbesar
Proyek sebesar ini mengajarkan bahwa kesederhanaan yang disiplin mengalahkan kepintaran yang berantakan. Konvensi yang konsisten, batas modul yang jelas, dan penanganan error yang serius membuat sistem tetap bisa dirawat meski terus tumbuh. Teknologi hanyalah alat; yang menentukan adalah bagaimana Anda menatanya.
Ingin melihat proyek lain yang pernah saya bangun? Kunjungi halaman portofolio.
