23 Okt 2025·5 menit
Filter sisi-server vs sisi-klien: daftar periksa pengambilan keputusan
Daftar periksa filter sisi-server vs sisi-klien untuk memilih berdasarkan ukuran data, latensi, izin, dan caching — tanpa kebocoran UI atau lag.
Daftar periksa filter sisi-server vs sisi-klien untuk memilih berdasarkan ukuran data, latensi, izin, dan caching — tanpa kebocoran UI atau lag.
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:
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.
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:
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.
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:
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.
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:
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.
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.
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:
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.
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.
Anggap tujuan sebagai tak bisa ditawar: layar harus terasa cepat tanpa membocorkan data.
Kebanyakan tim terjebak oleh pola yang sama: UI yang terlihat hebat di demo, lalu data nyata, izin nyata, dan kecepatan jaringan nyata memperlihatkan retakannya.
Kegagalan paling serius adalah memperlakukan filtering sebagai presentasi. Jika browser menerima record yang tidak boleh dimiliki, Anda sudah kalah.
Dua penyebab umum:
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.
Lag sering datang dari asumsi:
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.
Lakukan pemeriksaan akhir dengan dua pola pikir: pengguna penasaran dan hari jaringan buruk.
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.
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:
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.
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.
Default ke sisi-server ketika pengguna memiliki izin berbeda, dataset besar, atau ketika Anda membutuhkan pagination dan total yang konsisten. Gunakan filtering sisi-klien hanya ketika keseluruhan dataset kecil, aman untuk dibuka, dan cepat diunduh.
Karena apapun yang diterima browser bisa diperiksa. Meski UI menyembunyikan baris atau kolom, pengguna tetap bisa melihat data di respons jaringan, payload yang di-cache, atau objek di memori.
Biasanya terjadi ketika Anda mengirim terlalu banyak data lalu memfilter/men-sort array besar pada setiap penekanan tombol, atau ketika Anda mengirimkan request ke server pada setiap keypress tanpa debouncing. Jaga payload tetap kecil dan hindari pekerjaan berat pada setiap perubahan input.
Pertahankan satu sumber kebenaran untuk filter “nyata”: izin, pencarian, sorting, dan pagination harus ditegakkan bersama di server. Batasi logika sisi-klien pada toggle UI kecil yang tidak mengubah dataset dasar.
Caching sisi-klien bisa menampilkan data usang atau salah, dan dapat bocor antar akun jika kunci cache tidak tepat. Caching sisi-server lebih aman untuk izin, tetapi harus menyertakan signature filter penuh dan identitas pemanggil agar hasil tidak tercampur.
Tanyakan dua hal: berapa banyak baris yang realistis dimiliki pengguna, dan seberapa besar setiap baris dalam byte. Jika Anda tidak nyaman memuatnya di koneksi mobile biasa atau di perangkat lama, pindahkan filtering ke server dan gunakan pagination.
Sisi-server. Jika peran, tim, region, atau aturan kepemilikan mengubah apa yang boleh dilihat seseorang, server harus menegakkan akses baris dan field. Klien hanya boleh menerima record dan field yang pengguna berhak lihat.
Definisikan kontrak filter dan sort terlebih dulu: field filter yang diterima, sorting default, aturan pagination, dan bagaimana pencarian mencocokkan (case, aksen, kecocokan parsial). Lalu terapkan logika yang sama secara konsisten di backend dan uji agar total serta halaman sinkron.
Debounce saat mengetik supaya Anda tidak mengirim permintaan pada setiap keypress, dan pertahankan hasil lama terlihat sampai hasil baru datang untuk mengurangi flicker. Gunakan pagination atau progressive loading agar pengguna melihat sesuatu dengan cepat tanpa menunggu respons besar.
Terapkan izin terlebih dulu, lalu filter dan sorting, dan kembalikan hanya satu halaman ditambah total count. Hindari mengirim “field ekstra untuk berjaga-jaga,” dan pastikan kunci cache menyertakan user/org/role sehingga seorang rep tidak pernah menerima data yang diperuntukkan manager.