Cara Membangun Fitur Search Sederhana dengan Laravel Query Builder

Pendahuluan

Bayangin lagi ngerjain fitur sederhana, tapi client minta pencarian data yang bisa nyari di banyak kolom sekaligus tanpa bikin aplikasi lemot. Sering banget kita terjebak nulis query panjang lebar di Controller yang akhirnya bikin code jadi berantakan alias spaghetti code. Padahal, pakai Query Builder bawaan Laravel, kita bisa bikin fitur search yang clean dan tetep performant tanpa harus install package pencarian yang berat.

Tips & Best Practices

• Di banyak project, biasanya saya mulai dari menaruh logika pencarian di dalam Scope Model supaya controller tetap bersih dan fokus ke request-response aja.
• Pernah kejadian user minta pencarian yang bisa nembus ke relasi, jadi saya selalu membiasakan pakai whereHas daripada join manual yang kadang bikin query jadi ambigu.
• Pas lagi handling database besar, saya pasti selalu nambahin when() agar query cuma ditambahin ke builder kalau input request-nya beneran ada isinya, ini ngebantu banget biar query nggak kepanjangan tanpa alasan.

Contoh Kode

Gini cara saya biasanya nulis query pencarian di model supaya gampang dipanggil di mana aja:

public function scopeSearch($query, $search) { return $query->when($search, function ($q) use ($search) { $q->where('title', 'like', "%{$search}%") ->orWhere('content', 'like', "%{$search}%"); }); }

Terus di controller tinggal panggil santai: $posts = Post::search($request->q)->paginate(10);

Variasi Implementasi

Tergantung kebutuhan, kalau datanya mulai jutaan row, pendekatan like memang bakal mulai kerasa berat. Biasanya saya mulai nimbang buat beralih ke Full-Text Search bawaan MySQL kalau tabelnya nggak terlalu kompleks, atau sekalian pakai Laravel Scout kalau mau performa yang lebih serius. Tapi buat dashboard internal atau aplikasi skala menengah, pendekatan Query Builder standar biasanya udah lebih dari cukup.

Kesalahan Umum

• Lupa nge-sanitize input, padahal biar simpel, tetap harus waspada sama input user meski udah pakai parameter binding.
• Terlalu banyak pakai orWhere tanpa grouping, ini sering bikin query pencarian jadi berantakan dan return data yang nggak relevan karena logic OR-nya bocor ke kondisi lain.
• Sering lupa pakai pagination, alhasil kalau datanya ribuan, aplikasi langsung kena memory limit pas ditarik semua sekaligus.
• Nggak pakai index di database, padahal fitur pencarian yang pakai like itu butuh banget index supaya nggak full table scan.
• Terlalu maksa naruh query pencarian langsung di file View pakai raw SQL, ini bikin susah di-debug kalau nanti ada perubahan kolom database.

Ringkasan

Fitur search memang kelihatannya sepele, tapi kalau dibangun dengan pola yang rapi, bakal bikin codebase kita lebih enak dirawat. Jangan buru-buru install library berat kalau kebutuhan dasarnya masih bisa dicover sama Query Builder yang solid. Intinya, konsisten naruh logic di model dan selalu perhatiin performa sejak dini, nanti hidup jadi lebih tenang pas maintenance project-nya.