Filter sisi-server vs sisi-klien: daftar periksa pengambilan keputusan

Masalah sebenarnya: kebocoran, lag, dan hasil yang tidak konsisten

Memfilter di UI lebih dari sekadar kotak pencarian tunggal. Biasanya mencakup beberapa tindakan terkait yang semuanya mengubah apa yang dilihat pengguna: pencarian teks (nama, email, ID pesanan), facet (status, pemilik, rentang tanggal, tag), dan pengurutan (terbaru, nilai tertinggi, aktivitas terakhir).

Pertanyaan kuncinya bukan teknik mana yang “lebih baik.” Pertanyaannya adalah di mana dataset penuh berada, dan siapa yang diizinkan mengaksesnya. Jika browser menerima record yang seharusnya tidak dilihat pengguna, UI bisa mengekspos data sensitif meski Anda menyembunyikannya secara visual.

Sebagian besar perdebatan tentang sisi-server vs sisi-klien sebenarnya reaksi terhadap dua kegagalan yang langsung dirasakan pengguna:

• Kebocoran: data muncul di payload jaringan, respons yang di-cache, atau melalui filter tak terduga yang mengungkap baris tersembunyi.
• Lag: layar terasa lambat karena Anda mengirim terlalu banyak data, lalu membuat perangkat melakukan pekerjaan berat pada setiap penekanan tombol.

Ada masalah ketiga yang menghasilkan laporan bug tak berujung: hasil yang tidak konsisten. Jika beberapa filter dijalankan di klien dan yang lain di server, pengguna melihat jumlah, halaman, dan total yang tidak cocok. Itu merusak kepercayaan dengan cepat, terutama pada daftar yang dipaginasi.

Default praktisnya sederhana: jika pengguna tidak diizinkan mengakses dataset penuh, lakukan filter di server. Jika diizinkan dan dataset cukup kecil untuk dimuat cepat, filter di klien bisa diterima.

Definisi singkat dalam bahasa sederhana

Memfilter hanyalah “tunjukkan item yang cocok.” Pertanyaan kuncinya adalah di mana pencocokan terjadi: di browser pengguna (klien) atau di backend Anda (server).

Filtering sisi-klien berjalan di browser. Aplikasi mengunduh sekumpulan record (sering JSON), lalu menerapkan filter secara lokal. Bisa terasa instan setelah data dimuat, tetapi hanya bekerja ketika dataset cukup kecil untuk dikirim dan aman untuk dibuka.

Filtering sisi-server berjalan di backend Anda. Browser mengirim input filter (mis. status=open, owner=me, createdAfter=Jan 1), dan server mengembalikan hanya hasil yang cocok. Dalam praktiknya ini biasanya endpoint API yang menerima filter, membangun query database, dan mengembalikan daftar ter-paginasi plus total.

Model mental sederhana:

• Sisi-klien: unduh banyak, filter di sini.
• Sisi-server: minta tepat yang Anda butuhkan.

Setup hibrida umum. Pola yang baik adalah menegakkan filter “besar” di server (izin, kepemilikan, rentang tanggal, pencarian), lalu gunakan toggle kecil di UI secara lokal (sembunyikan arsip, chip tag cepat, visibilitas kolom) tanpa permintaan tambahan.

Sorting, pagination, dan pencarian biasanya termasuk dalam keputusan yang sama. Mereka memengaruhi ukuran payload, rasa pengguna, dan data yang Anda ekspos.

Faktor keputusan 1: ukuran data dan biaya payload

Mulailah dengan pertanyaan paling praktis: berapa banyak data yang akan Anda kirim ke browser jika memfilter di klien? Jika jawaban jujur adalah “lebih dari beberapa layar,” Anda akan membayar dalam waktu unduh, penggunaan memori, dan interaksi yang melambat.

Anda tidak perlu perkiraan sempurna. Cukup dapatkan orde magnitudo: berapa banyak baris yang mungkin dilihat pengguna, dan berapa ukuran rata-rata sebuah baris? Daftar 500 item dengan beberapa field pendek sangat berbeda dari 50.000 item di mana setiap baris berisi catatan panjang, teks kaya, atau objek bersarang.

Record yang lebar adalah pembunuh payload senyap. Tabel bisa terlihat kecil berdasarkan jumlah baris tapi tetap berat jika setiap baris berisi banyak field, string besar, atau data gabungan (kontak + perusahaan + aktivitas terakhir + alamat lengkap + tag). Bahkan jika Anda hanya menampilkan tiga kolom, tim sering mengirimkan “semua, untuk berjaga-jaga,” dan payload membengkak.

Pikirkan juga pertumbuhan. Dataset yang baik hari ini bisa menjadi menyakitkan setelah beberapa bulan. Jika data tumbuh cepat, anggap filtering sisi-klien sebagai jalan pintas jangka pendek, bukan default.

Pedoman:

• Jika Anda tidak bisa dengan nyaman mengirim seluruh dataset lewat koneksi mobile tipikal, filter di server.
• Jika pengguna hanya pernah menyentuh irisan kecil pada satu waktu, ambil irisan itu dan filter di server.
• Jika dataset kecil, stabil, dan benar-benar aman untuk dibuka, filtering sisi-klien bisa terasa menyenangkan.

Poin terakhir ini penting bukan hanya untuk kinerja. “Bisakah kita mengirim seluruh dataset ke browser?” juga pertanyaan keamanan. Jika jawabannya bukan ya dengan yakin, jangan kirim.

Faktor keputusan 2: latensi dan pengalaman pengguna

Pilihan filtering sering gagal pada aspek feel, bukan kebenaran. Pengguna tidak mengukur milidetik. Mereka memperhatikan jeda, flicker, dan hasil yang melompat-lompat saat mengetik.

Waktu bisa hilang di beberapa tempat:

• Jaringan: waktu request/response dan ukuran payload
• Server: query database, join, sorting, pengecekan izin
• Browser: parsing JSON, merender baris, memfilter array besar

Tentukan apa yang berarti “cukup cepat” untuk layar ini. Tampilan daftar mungkin butuh ketikan responsif dan scroll yang mulus, sementara halaman laporan bisa mentolerir sedikit penantian selama hasil pertama muncul cepat.

Jangan menilai hanya dari Wi‑Fi kantor. Pada koneksi lambat, filtering sisi-klien bisa terasa hebat setelah muatan pertama, tetapi muatan pertama itu mungkin bagian yang lambat. Filtering sisi-server menjaga payload kecil, tetapi bisa terasa lag jika Anda menembakkan permintaan pada setiap penekanan tombol.

Rancang mengelilingi input manusia. Debounce permintaan saat mengetik. Untuk hasil besar, gunakan progressive loading sehingga halaman menunjukkan sesuatu dengan cepat dan tetap mulus saat pengguna menggulir.

Faktor keputusan 3: izin dan eksposur data

Izin harus menentukan pendekatan filtering lebih dari kecepatan. Jika browser pernah menerima data yang pengguna tidak berhak lihat, Anda sudah punya masalah, meski Anda menyembunyikannya di balik tombol yang dinonaktifkan atau kolom yang terlipat.

Mulailah dengan menamai apa yang sensitif pada layar ini. Beberapa field jelas (email, nomor telepon, alamat). Lainnya mudah terlewat: catatan internal, biaya atau margin, aturan harga khusus, skor risiko, flag moderasi.

Perangkap besar adalah “kita filter di klien, tapi hanya tampilkan baris yang diizinkan.” Itu tetap berarti dataset penuh sudah diunduh. Siapa pun bisa memeriksa respons jaringan, membuka dev tools, atau menyimpan payload. Menyembunyikan kolom di UI bukanlah kontrol akses.

Kapan filtering sisi-server adalah default yang aman

Filtering sisi-server adalah default yang lebih aman ketika otorisasi bervariasi menurut pengguna, terutama ketika pengguna berbeda dapat melihat baris atau field berbeda.

Cek cepat:

• Apakah peran berbeda melihat baris yang berbeda (hanya tim, hanya region, ditugaskan-ke-saya)?
• Apakah peran berbeda melihat field yang berbeda (catatan, harga, PII)?
• Adakah aturan baris (pemilik akun, tahap deal, flag “private”)?
• Dapatkah export, sorting, atau total mengungkap info terbatasi?
• Apakah payload bocor akan menimbulkan isu kepatuhan?

Jika ada jawaban ya, lakukan filtering dan pemilihan field di server. Kirim hanya yang pengguna diizinkan lihat, dan terapkan aturan yang sama untuk pencarian, sorting, pagination, dan export.

Contoh: di daftar kontak CRM, sales rep bisa melihat akun mereka sendiri sementara manager bisa melihat semua. Jika browser mengunduh semua kontak dan memfilter lokal, seorang rep tetap bisa mengambil akun tersembunyi dari respons. Filtering sisi-server mencegah itu dengan tidak pernah mengirim baris tersebut.

Faktor keputusan 4: caching dan kesegaran data

Caching bisa membuat layar terasa instan. Ia juga bisa menampilkan kebenaran yang salah. Intinya adalah memutuskan apa yang boleh Anda gunakan ulang, berapa lama, dan peristiwa apa yang harus menghapusnya.

Mulailah dengan memilih unit cache. Meng-cache seluruh daftar sederhana tetapi biasanya boros bandwidth dan cepat usang. Meng-cache halaman bekerja baik untuk infinite scroll. Meng-cache hasil query (filter + sort + search) akurat, tetapi bisa tumbuh cepat jika pengguna mencoba banyak kombinasi.

Kesegaran lebih penting di beberapa domain daripada yang lain. Jika data berubah cepat (stok, saldo, status pengiriman), bahkan cache 30 detik bisa membingungkan. Jika data berubah lambat (record arsip, data referensi), caching lebih panjang biasanya aman.

Rencanakan invalidasi sebelum Anda koding. Selain waktu berlalu, putuskan apa yang harus memaksa refresh: create/edit/delete, perubahan izin, import/merge massal, transisi status, undo/rollback, dan job latar yang memperbarui field yang difilter pengguna.

Tentukan juga di mana caching berada. Memori browser membuat navigasi back/forward cepat, tetapi bisa membocorkan data antar akun jika Anda tidak memberi kunci berdasarkan user dan org. Caching di backend lebih aman untuk izin dan konsistensi, tetapi harus menyertakan signature filter penuh dan identitas pemanggil agar hasil tidak tercampur.

Langkah demi langkah: cara memilih untuk layar baru

Anggap tujuan sebagai tak bisa ditawar: layar harus terasa cepat tanpa membocorkan data.

Alur keputusan praktis

1. Mulai dengan kendala terkuat. Jika akses bervariasi menurut peran, tim, region, org, atau langganan, izin menang. Jika dataset besar atau bisa tumbuh cepat, ukuran menang.
2. Default ke sisi-server saat data besar atau sensitif. Jika Anda tidak akan nyaman mencatat dataset penuh di konsol browser, jangan kirim.
3. Gunakan filtering sisi-klien hanya untuk daftar kecil, aman, dan sering digunakan. Dropdown status, daftar tag kecil, satu halaman hasil yang sudah disetujui.
4. Tentukan bentuk API sebelum UI. Tuliskan filter, sorting, pagination, dan default supaya server dan UI tidak berbeda pendapat.
5. Tambahkan pengamanan. Terapkan ukuran halaman maksimum, set timeout, dan putuskan bagaimana UI berperilaku saat filtering lambat (tampilkan spinner, pertahankan hasil lama, tawarkan retry).

Kesalahan umum yang menyebabkan kebocoran atau lag

Kebanyakan tim terjebak oleh pola yang sama: UI yang terlihat hebat di demo, lalu data nyata, izin nyata, dan kecepatan jaringan nyata memperlihatkan retakannya.

Kesalahan yang menyebabkan kebocoran data

Kegagalan paling serius adalah memperlakukan filtering sebagai presentasi. Jika browser menerima record yang tidak boleh dimiliki, Anda sudah kalah.

Dua penyebab umum:

• Mengirim seluruh dataset ke browser dan memfilter lokal “supaya cepat.” Siapa pun bisa memeriksa respons atau memanggilnya di memori.
• Meng-cache respons terfilter tanpa mengaitkan kunci cache ke identitas pengguna, org, role, atau versi kebijakan. Perubahan izin bisa diam‑diam mengekspos data lama.

Contoh: intern hanya boleh melihat leads dari region mereka. Jika API mengembalikan semua region dan dropdown memfilter di React, intern masih bisa mengekstrak daftar penuh.

Kesalahan yang membuat layar terasa lambat

Lag sering datang dari asumsi:

• Menganggap filtering sisi-klien selalu lebih cepat. Dengan 50.000 baris, mengunduh dan parsing bisa lebih lama daripada query fokus.
• Lupa pagination dan state loading. Layar yang terblokir saat merender daftar besar terasa rusak meski query benar.

Masalah halus tapi menyakitkan adalah aturan yang tidak cocok. Jika server menangani “starts with” berbeda dari UI, pengguna melihat jumlah yang tak cocok, atau item yang menghilang setelah refresh.

Daftar periksa cepat sebelum rilis

Lakukan pemeriksaan akhir dengan dua pola pikir: pengguna penasaran dan hari jaringan buruk.

• Kewarasan payload: pastikan respons tidak pernah menyertakan baris atau field yang pengguna tak boleh lihat, walau UI menyembunyikannya. Perhatikan total, group count, atau ID yang memungkinkan seseorang menebak data terbatasi.
• Logging aman: filter sering berisi email, nama, atau ID. Jangan catat nilai filter sensitif, SQL penuh, atau body request lengkap di tempat yang banyak orang dapat mengakses.
• Konsistensi di perangkat: terapkan filter yang sama di desktop dan mobile. Perbedaan sering datang dari sorting sisi-klien, aturan lokal (case, aksen), atau default yang berbeda.
• State yang jelas: loading, empty, dan error harus jelas. Uji perubahan cepat (ketik, backspace, toggle) supaya UI tidak berkedip atau menampilkan hasil usang.
• Pengaman kondisi terburuk: batas ukuran halaman, batas rentang tanggal, dan timeout. Lindungi dari query mahal (wildcard luas, terlalu banyak kondisi OR, field tanpa index).

Tes sederhana: buat record yang dibatasi dan pastikan itu tidak pernah muncul di payload, total, atau cache, meski saat Anda memfilter secara luas atau menghapus filter.

Contoh skenario: daftar kontak CRM

Bayangkan CRM dengan 200.000 kontak. Sales rep hanya bisa melihat akun mereka sendiri, manager bisa melihat tim mereka, dan admin bisa melihat semuanya. Layar memiliki pencarian, filter (status, owner, aktivitas terakhir), dan sorting.

Filtering sisi-klien cepat gagal di sini. Payload berat, muatan pertama melambat, dan risiko kebocoran data tinggi. Bahkan jika UI menyembunyikan baris, browser tetap menerima data. Anda juga memberi tekanan pada perangkat: array besar, sorting berat, eksekusi filter berulang, penggunaan memori tinggi, dan crash pada ponsel lama.

Pendekatan yang lebih aman adalah filtering sisi-server dengan pagination. Klien mengirim pilihan filter dan teks pencarian, dan server mengembalikan hanya baris yang pengguna diizinkan lihat, sudah difilter dan disortir.

Pola praktis:

• Terapkan izin terlebih dulu, lalu filter dan sort.
• Kembalikan satu halaman saja (misalnya, 50 baris) plus total count.
• Cache secara hati-hati (per user atau per role) agar Anda tidak mencampur hasil antar izin.

Pengecualian kecil di mana filtering sisi-klien baik: data kecil dan statis. Dropdown “Contact status” dengan 8 nilai bisa dimuat sekali dan difilter lokal tanpa risiko atau biaya besar.

Langkah selanjutnya: dokumentasikan keputusan dan bangun dengan lebih sedikit penulisan ulang

Tim biasanya tidak terbakar karena memilih opsi “salah” sekali. Mereka terbakar karena memilih opsi berbeda pada setiap layar, lalu mencoba memperbaiki kebocoran dan halaman lambat di bawah tekanan.

Tulis catatan keputusan singkat per layar dengan filter: ukuran dataset, berapa biaya mengirimnya, apa yang terasa “cukup cepat,” field mana yang sensitif, dan bagaimana hasil harus di-cache (atau tidak). Jaga agar server dan UI selaras sehingga Anda tidak berakhir dengan “dua kebenaran” untuk filtering.

Jika Anda membangun layar dengan cepat di Koder.ai (koder.ai), ada baiknya memutuskan di muka filter mana yang harus ditegakkan di backend (izin dan akses baris) dan toggle kecil mana yang boleh tetap di layer React. Satu keputusan itu cenderung mencegah penulisan ulang paling mahal nanti.