Apa yang Saya Pelajari Setelah Bertahun-Tahun Menggunakan Laravel di Real Project

Masih cukup jelas di ingatan saya ketika pertama kali menggunakan Laravel beberapa tahun lalu. Waktu itu ekspektasinya sederhana: mencari framework PHP yang lebih rapi, lebih cepat dikembangkan, dan tidak membuat kepala pusing saat project mulai membesar.

Awalnya saya pikir Laravel hanya soal syntax yang elegan.

Ternyata setelah bertahun-tahun dipakai di berbagai project — mulai dari company profile sederhana, sistem informasi, dashboard internal, sampai aplikasi dengan business logic yang cukup kompleks — saya sadar bahwa kekuatan Laravel bukan hanya di syntax.

Yang paling terasa justru ada pada cara framework ini membantu developer berpikir lebih terstruktur.

Dan menariknya, beberapa pelajaran penting justru datang dari kesalahan yang pernah saya buat sendiri.

Laravel Tidak Pernah Jadi Masalah, Architecture Developer yang Sering Jadi Masalah

Ini mungkin opini yang sedikit kontroversial.

Banyak developer mengatakan:

“Laravel berat”
“Laravel lambat”
“Laravel tidak cocok untuk aplikasi besar”

Menurut pengalaman saya, sebagian besar masalah bukan ada di Laravel.

Masalahnya sering ada di implementasi.

Saya pernah melihat project Laravel yang baru berjalan beberapa bulan tapi controller-nya sudah ribuan baris. Semua logic bercampur:

• Query database
• Validation
• Business logic
• API integration
• Response formatting

Semua ada di satu tempat.

Saat project masih kecil memang terasa cepat. Tapi begitu fitur bertambah, technical debt mulai terasa.

Di titik ini saya belajar satu hal penting:

Laravel akan tetap nyaman digunakan jika struktur aplikasinya disiplin sejak awal.

Karena itu, saya mulai lebih serius memisahkan:

• Service Layer
• Action Class
• Form Request
• Repository (jika memang diperlukan)
• DTO atau data transformation
• Reusable helper

Tidak selalu harus over-engineering. Tapi minimal project punya fondasi yang sehat.

Semakin lama menggunakan Laravel, saya semakin percaya:

Clean architecture lebih penting daripada mengejar syntax yang terlihat keren.

Jangan Terlalu Cepat Membuat Segalanya “Scalable”

Ini pelajaran yang cukup mahal.

Dulu saya sering terlalu semangat membuat struktur yang terasa “enterprise ready”.

Folder banyak.

Pattern banyak.

Abstraction di mana-mana.

Repository pattern dipakai untuk semua model.

Service layer dibuat hampir untuk semua proses.

Padahal project-nya masih kecil.

Akhirnya justru maintenance terasa berat.

Setelah bertahun-tahun menggunakan Laravel, saya belajar bahwa:

Tidak semua aplikasi perlu architecture yang kompleks.

Laravel sebenarnya sudah opinionated dengan cara yang cukup baik.

Kadang menggunakan:

User::query()->latest()->paginate(10);

itu sudah cukup.

Tidak semua query harus dibungkus lima lapisan abstraction.

Sekarang saya jauh lebih pragmatis.

Saya hanya membuat abstraction ketika memang mulai ada tanda-tanda:

• Logic mulai berulang
• Feature semakin kompleks
• Testing mulai sulit
• Controller mulai membesar
• Dependency semakin banyak

Dengan kata lain:

Bangun complexity hanya ketika benar-benar dibutuhkan.

Eloquent Itu Powerful, Tapi Bisa Menjadi Bumerang

Saya suka Eloquent.

Jujur saja, ini salah satu alasan Laravel terasa menyenangkan digunakan.

Syntax-nya expressive.

Readable.

Dan cepat untuk development.

Tapi ada satu fase di mana saya terlalu nyaman menggunakan Eloquent tanpa memikirkan performa.

Hasilnya?

N+1 query di mana-mana.

Query relationship tidak terkontrol.

Memory usage mulai membengkak.

Response API melambat.

Dari situ saya belajar untuk lebih sadar terhadap hal-hal seperti:

Gunakan eager loading

Daripada:

Post::all();

lebih baik:

Post::with('category', 'author')->get();

Gunakan select seperlunya

Tidak semua kolom harus diambil.

Hati-hati dengan nested relationship

Kadang satu halaman kecil ternyata menjalankan puluhan query tanpa sadar.

Sekarang, setiap membuat fitur Laravel, saya hampir selalu mengecek query performance lebih awal sebelum masalah muncul.

Karena optimasi setelah production biasanya jauh lebih melelahkan.

Validation yang Baik Bisa Mengurangi Banyak Bug

Salah satu hal yang sering diremehkan developer baru adalah validation.

Padahal menurut saya ini fondasi penting.

Laravel punya validation system yang sangat nyaman digunakan.

Dan semakin lama saya bekerja dengan Laravel, saya semakin jarang melakukan validation langsung di controller.

Saya lebih suka menggunakan:

Form Request

Contohnya:

StorePostRequest
UpdatePortfolioRequest

Keuntungannya sederhana:

• Controller lebih bersih
• Reusable
• Lebih mudah di-maintain
• Custom message lebih rapi

Hal kecil seperti ini ternyata punya dampak besar ketika project mulai berkembang.

Livewire Membuat Laravel Semakin Menyenangkan

Ketika pertama kali mencoba Livewire, saya cukup skeptis.

Karena sebelumnya banyak pekerjaan frontend reactive selalu identik dengan JavaScript framework.

Saya juga pernah membahas alasan kenapa saya cukup sering memilih Livewire untuk workflow Laravel modern.

Tapi setelah benar-benar dipakai di beberapa project Laravel, saya mulai menikmati workflow-nya.

Untuk dashboard, admin panel, CRUD system, atau data management, kombinasi Laravel + Livewire terasa sangat produktif.

Khususnya ketika target project adalah:

• Fast development
• Maintainable codebase
• Server-driven architecture
• Clean backend logic

Tentu bukan berarti Livewire selalu jadi jawaban.

Ada kondisi tertentu di mana Vue.js atau frontend SPA tetap lebih cocok.

Tapi untuk banyak business application, saya cukup sering memilih Livewire karena development speed dan maintainability-nya terasa lebih efisien.

Testing Bukan Membuang Waktu

Dulu saya termasuk developer yang sering berpikir:

“Yang penting feature jalan dulu.”

Testing terasa seperti pekerjaan tambahan.

Sampai akhirnya pernah ada perubahan kecil yang tanpa sadar merusak flow besar di production.

Dari situ perspektif saya berubah.

Sekarang minimal saya mulai lebih disiplin pada:

• Feature testing
• Validation testing
• Auth flow testing
• Critical business logic

Laravel membuat proses testing sebenarnya cukup nyaman.

Dan semakin besar project, semakin terasa manfaatnya.

Dokumentasi Laravel Adalah Salah Satu yang Terbaik

Ini mungkin terdengar sederhana, tapi dokumentasi Laravel menurut saya salah satu alasan framework ini terus berkembang.

Bahkan setelah bertahun-tahun menggunakan Laravel, saya masih sering membuka dokumentasi resmi.

Bukan karena lupa.

Tapi karena best practice selalu berubah.

Fitur baru muncul.

Pattern berkembang.

Dan dokumentasi Laravel biasanya sangat jelas.

Kadang jawabannya justru ada di sana, bukan di random tutorial internet.

Pelajaran Terbesar Saya: Maintainability Selalu Menang

Kalau ditanya apa yang paling saya pelajari setelah bertahun-tahun menggunakan Laravel, jawabannya sederhana:

Code yang mudah di-maintain selalu lebih penting daripada code yang terlihat pintar.

Saya pernah membuat code yang menurut saya “advanced”.

Tapi beberapa bulan kemudian malah diri sendiri yang bingung membacanya.

Sejak saat itu saya lebih memilih:

• Readable code
• Naming yang jelas
• Structure yang konsisten
• Simple over clever

Karena pada akhirnya software bukan hanya untuk dijalankan mesin.

Software juga harus nyaman dipahami developer berikutnya — termasuk diri kita sendiri di masa depan.