
Pendahuluan
Bayangin lagi ngerjain fitur sederhana, tapi tiba-tiba sistem backend kamu down gara-gara satu user iseng atau script bot yang nembak API berkali-kali tanpa jeda. Situasi ini sering banget bikin saya keringat dingin di tengah malam, sampai akhirnya saya nemu Laravel RateLimiter sebagai penyelamat. Fitur ini bukan cuma sekadar pembatas, tapi semacam satpam cerdas yang ngatur lalu lintas request sebelum masuk ke logic utama aplikasi kita.
Tips & Best Practices
- Di banyak project, biasanya saya mulai dari pembatasan yang longgar dulu, lalu kita lihat log-nya. Jangan langsung pasang limit ketat di awal karena bisa jadi user asli yang malah kena blokir gara-gara perilaku aplikasinya.
- Saat saya menangani aplikasi dengan banyak microservices, saya sering pakai Redis sebagai store untuk RateLimiter biar sinkron antar server tetap terjaga dengan konsisten.
- Selalu pisahkan limit untuk guest dan user yang sudah login, karena kebutuhan mereka biasanya beda jauh banget dari segi keamanan dan kenyamanan akses.
Contoh Kode
Biasanya saya pasang logic ini di file RouteServiceProvider atau langsung di route file untuk kasus khusus seperti ini:
use Illuminate\Support\Facades\RateLimiter;\n\nRateLimiter::for('api-sensitif', function ($request) {\n return Limit::perMinute(60)->by($request->user()?->id ?: $request->ip());\n});Di sini saya nge-set 60 request per menit, dan kuncinya fleksibel: pakai ID user kalau mereka login, atau pakai IP kalau mereka tamu biasa.
Variasi Implementasi
Kita bisa pakai RateLimiter lewat middleware('throttle:60,1') untuk cara yang instan, atau pakai facade RateLimiter::attempt() kalau butuh kontrol penuh di dalam controller saat ada logika bisnis yang sangat spesifik yang butuh dicek sebelum proses berlanjut.
Kesalahan Umum
- Lupa kalau IP address bisa berubah-ubah di belakang load balancer, jadi kadang pembatasan berbasis IP malah bikin user yang pakai VPN atau shared connection kena getahnya.
- Terlalu pelit ngasih limit request sehingga UX aplikasi malah jadi buruk karena user sering banget kena error 429.
- Nggak kasih response yang ramah, sehingga user cuma dapet error default yang bikin mereka bingung harus ngapain selanjutnya.
- Mengabaikan cache driver; kalau aplikasi trafiknya tinggi tapi cuma pakai file driver, performa server malah jadi makin berat buat ngecek limit tersebut.
- Memasang rate limit yang sama rata untuk semua endpoint, padahal endpoint login harusnya jauh lebih ketat daripada endpoint ngambil data publik.
Ringkasan
Setelah sekian lama berkutat dengan isu traffic, saya sadar bahwa RateLimiter itu bukan soal membatasi user, tapi soal menjaga kestabilan aplikasi agar tetap bisa dinikmati semua orang. Pada akhirnya, nerapin ini bikin tidur saya jauh lebih tenang karena tahu kalau sistem punya pertahanan yang cukup saat ada request yang nggak wajar.
Komentar
Posting Komentar