Memahami Event & Listener Laravel untuk Arsitektur Kode Bersih

Pendahuluan

Bayangin lagi ngerjain fitur sederhana, tapi lama-lama controller kamu jadi 'gemuk' banget gara-gara harus ngirim email, nge-update log, sampai ngirim notifikasi ke Slack secara bersamaan. Rasanya kayak nimbun sampah di satu tempat, susah dibaca dan bikin maintenance jadi mimpi buruk. Di sinilah Laravel Event & Listener datang sebagai penyelamat biar logic kamu nggak tumpang tindih.

Tips & Best Practices

Di banyak project, biasanya saya mulai dari memisahkan logic yang nggak krusial untuk response user ke dalam listener agar proses loading terasa jauh lebih instan. Saya juga selalu membiasakan diri buat memberi nama event yang merepresentasikan aksi, bukan teknis, misalnya UserRegistered lebih baik daripada SendWelcomeEmail. Terakhir, saya sering pakai ShouldQueue di listener supaya proses berat kayak integrasi pihak ketiga nggak bikin user nunggu lama di depan layar.

Contoh Kode

Misalnya kita mau ngirim email pas user daftar, daripada naruh Mail::to(...) di Controller, mending kita lempar event:

// Di Controller
event(new UserRegistered($user));

// Di Listener
public function handle(UserRegistered $event) {
    Mail::to($event->user)->send(new WelcomeEmail());
}

Dengan cara ini, Controller cuma fokus terima input dan return response, urusan 'ikutan' setelah itu biarkan Listener yang handle.

Variasi Implementasi

Ada dua jalur yang biasa saya tempuh. Pertama, pakai EventServiceProvider buat mapping manual, ini enak kalau project masih kecil. Kedua, kalau udah kompleks, saya pakai Event Discovery yang bikin Laravel otomatis deteksi event berdasarkan nama folder, bikin struktur folder lebih rapi tanpa banyak boilerplate.

Kesalahan Umum

Sering banget saya nemuin beberapa kesalahan ini di code review: 1. Naruh logic bisnis yang kritikal di listener (seharusnya cuma side-effect). 2. Lupa antre (queue) listener yang makan waktu lama sampai bikin request timeout. 3. Data yang dikirim ke event terlalu besar (sebaiknya kirim ID saja lalu ambil lagi dari database). 4. Terlalu banyak listener untuk satu event sampai sulit di-debug. 5. Gak handle error di listener, jadi kalau gagal, user gak tau apa-apa karena background process silent.

Ringkasan

Intinya, Event & Listener itu bukan cuma soal rapi-rapi kode, tapi gimana kita bikin sistem yang bisa 'bernapas' dan lebih mudah dikembangin tanpa harus bongkar pasang controller yang sudah jalan. Kalau kamu ngerasa controller mulai kerasa berat, coba deh pecah jadi event, biasanya sih langsung terasa bedanya saat kita mau nambahin fitur baru di kemudian hari.