Panduan Efektif Memisahkan Logika Laravel dengan Laravel Events

Pendahuluan

Bayangin lagi ngerjain fitur registrasi pengguna, tapi tiba-tiba controller kamu membengkak karena harus kirim email verifikasi, update statistik user, sampai integrasi ke layanan pihak ketiga. Awalnya emang kelihatan rapi, tapi lama-kelamaan *controller* tersebut jadi 'god object' yang susah banget di-maintain. Di titik inilah Laravel Events jadi penyelamat supaya kode kita nggak berantakan karena logika yang saling tumpang tindih.

Tips & Best Practices

• Di banyak project, biasanya saya mulai dari memisahkan *side-effects*. Kalau ada proses yang nggak harus nunggu selesai buat ngebalikin *response* ke user (seperti kirim email atau log ke Slack), segera masukkan ke dalam Event Listener.
• Waktu bikin sistem, jangan lupa buat bikin *Contract* atau *Interface* untuk Event. Ini ngebantu banget pas nanti kita mau nambahin listener baru tanpa harus bongkar kode yang sudah berjalan.
• Pas lagi diskusi sama tim, saya selalu nyaranin untuk pakai *Queue* buat listener yang berat. Ini menjaga *request lifecycle* tetap enteng dan user nggak nunggu lama di browser.

Contoh Kode

Contohnya pas user registrasi, daripada nulis banyak *logic* di controller, kita cukup fire event seperti ini:

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

Lalu, buat listener untuk menangani pengiriman email, kita pisahkan logic-nya:

class SendWelcomeEmail {
    public function handle(UserRegistered $event) {
        Mail::to($event->user)->send(new WelcomeMail());
    }
}

Variasi Implementasi

Ada dua pendekatan yang sering saya pakai. Pertama, *Synchronous Events* yang berjalan langsung; cocok untuk logic yang krusial dan harus selesai saat itu juga (misal: update status database). Kedua, *Queued Listeners* yang menggunakan Laravel Queues; ini standar emas buat logic yang lambat seperti ngirim API call ke pihak ketiga. Pakai yang *Sync* buat kecepatan, pakai yang *Queued* buat performa aplikasi jangka panjang.

Kesalahan Umum

• Seringkali kita terlalu semangat bikin event buat segala hal, padahal cuma dipanggil sekali. Akhirnya malah pusing sendiri pas *debugging* karena alurnya lompat-lompat.
• Lupa nambahin *ShouldQueue* di listener yang sebenarnya berat, alhasil aplikasi terasa lambat karena nungguin API eksternal respons.
• Menaruh logika bisnis yang terlalu kompleks di dalam Listener. Ingat, Listener itu cuma 'pengirim pesan', jangan taruh kalkulasi berat di situ.
• Nggak pakai *Type Hinting* yang jelas di *constructor* Event, bikin kita susah buat nge-trace data apa saja yang dibawa pas *event* dipicu.
• Salah kaprah membedakan antara Event dan Observer. Kalau logic-nya cuma soal CRUD model, mending pakai Model Observer, jangan dipaksa pakai Event.

Ringkasan

Menggunakan Laravel Events itu seperti membagi beban kerja ke tim. Controller kita jadi lebih bersih, *decoupled*, dan pastinya lebih enak dibaca. Jangan takut buat bereksperimen, karena pada akhirnya, kode yang rapi bakal bikin hidup kamu sebagai developer jauh lebih tenang di masa depan.