Sunucu tarafı vs istemci tarafı filtreleme: karar kontrol listesi

Gerçek problem: sızıntılar, gecikme ve tutarsız sonuçlar

Bir UI'da filtreleme tek bir arama kutusundan daha fazlasıdır. Genellikle kullanıcının gördüklerini değiştiren birkaç ilişkili işlemi içerir: metin araması (isim, e-posta, sipariş ID'si), yüzeyler (durum, sahip, tarih aralığı, etiketler) ve sıralama (yeniler, en yüksek değer, son aktivite).

Ana soru hangi tekniğin “daha iyi” olduğu değil. Tam veri setinin nerede olduğu ve kimin ona erişmesine izin verildiğidir. Eğer tarayıcı kullanıcının görmemesi gereken kayıtları alırsa, UI bunları görsel olarak gizleseniz bile hassas veriyi açığa çıkarabilir.

Sunucu tarafı ve istemci tarafı filtreleme üzerine çoğu tartışma aslında kullanıcıların hemen fark ettiği iki başarısızlığa verilen tepkidir:

• Sızıntılar: veriler ağ yüklerinde, önbelleğe alınmış yanıtlarda veya beklenmedik filtrelerde gizli satırları açığa çıkarır.
• Gecikme: ekran çok fazla veri gönderdiğiniz için yavaş hisseder ve her tuş vuruşunda cihazın ağır iş yapmasına neden olur.

Üçüncü bir konu da bitmeyen hata raporlarına yol açar: tutarsız sonuçlar. Bazı filtreler istemcide, bazıları sunucuda çalışırsa kullanıcılar sayımlar, sayfalar ve toplamların eşleşmediğini görür. Bu, özellikle sayfalandırılmış listelerde güveni hızlıca zedeler.

Pratik bir varsayılan basittir: kullanıcı tam veri setine erişmemesi gerekiyorsa, sunucuda filtreleyin. Erişime izin veriliyorsa ve veri seti hızlıca yüklenebilecek kadar küçükse, istemci tarafı filtreleme iyi olabilir.

Basit dilde hızlı tanımlar

Filtreleme sadece “eşleşen öğeleri göster” demektir. Ana soru eşlemenin nerede gerçekleştiğidir: kullanıcının tarayıcısında (istemci) mı yoksa backend'inizde (sunucu) mı.

İstemci tarafı filtreleme tarayıcıda çalışır. Uygulama bir kayıt kümesi indirir (genellikle JSON) ve sonra filtreleri yerelde uygular. Veri yüklendikten sonra anlık hissedebilir, ancak yalnızca veri seti gönderilebilecek kadar küçük ve açığa çıkarılabilecek kadar güvenliyse işe yarar.

Sunucu tarafı filtreleme backend'inizde çalışır. Tarayıcı filtre girdilerini (ör. status=open, owner=me, createdAfter=Jan 1) gönderir ve sunucu yalnızca eşleşen sonuçları döndürür. Pratikte bu, filtreleri kabul eden, veritabanı sorgusu oluşturan ve sayfalanmış liste artı toplamları döndüren bir API uç noktasıdır.

Basit bir zihinsel model:

• İstemci tarafı: çok indir, burada filtrele.
• Sunucu tarafı: tam olarak ihtiyacını iste.

Hibrit kurulumlar yaygındır. İyi bir desen, “büyük” filtreleri sunucuda zorlamak (izinler, sahiplik, tarih aralığı, arama), sonra küçük UI-özel geçişleri yerelde kullanmaktır (arşivleneni gizle, hızlı etiket çipleri, sütun görünürlüğü) ekstra bir istek gerektirmeden.

Sıralama, sayfalandırma ve arama genellikle aynı karara dahildir. Bunlar yük boyutunu, kullanıcı hissini ve hangi veriyi açığa çıkardığınızı etkiler.

Karar faktörü 1: veri boyutu ve yük maliyeti

Başlangıç için en pratik soru: istemci tarafında filtrelersen tarayıcıya ne kadar veri göndereceksiniz? Dürüst cevap “birkaç ekranın çok ötesinde” ise, indirmenin, bellek kullanımının ve daha yavaş etkileşimlerin maliyetini ödersiniz.

Kusursuz tahminlere gerek yok. Sadece büyüklük mertebesini alın: kullanıcı kaç satır görebilir ve bir satırın ortalama büyüklüğü nedir? Birkaç kısa alanlı 500 öğelik liste, uzun notlar, zengin metin veya iç içe nesneler içeren 50.000 öğeden çok farklıdır.

Geniş (wide) kayıtlar sessizce yükü öldürür. Bir tablo satır sayısı bakımından küçük görünebilir ama her satır çok alan, büyük dizeler veya join edilmiş veriler (iletişim + şirket + son aktivite + tam adres + etiketler) içeriyorsa ağırdır. Sadece üç sütun gösteriyor olsanız bile ekipler sıklıkla “her şeyi gönderelim, gerekirse” der ve payload şişer.

Büyümeyi de düşünün. Bugün iyi olan bir veri seti birkaç ay sonra zahmetli olabilir. Veri hızlı büyüyorsa, istemci tarafı filtrelemeyi kısa vadeli bir kestirme olarak görün, varsayılan olarak değil.

Parmak kurallar:

• Tam veri setini tipik bir mobil bağlantı üzerinden rahatça gönderemiyorsanız, sunucuda filtreleyin.
• Kullanıcılar hep küçük bir dilimi aynı anda kullanıyorsa, o dilimi getirin ve sunucu tarafında filtreleyin.
• Veri seti küçük, stabil ve gerçekten açığa çıkarılması güvenliyse, istemci tarafı filtreleme harika hissettirebilir.

Bu son nokta performanstan daha fazlası için önemlidir. “Tüm veri setini tarayıcıya gönderebilir miyiz?” sorusu aynı zamanda bir güvenlik sorusudur. Cevap kesin bir evet değilse, göndermeyin.

Karar faktörü 2: gecikme ve kullanıcı hissi

Filtreleme seçimleri genellikle doğrulukta değil histe başarısız olur. Kullanıcılar milisaniyeleri ölçmez; duraklamaları, titremeyi ve yazarken sonuçların etrafa savrulmasını fark ederler.

Zaman farklı yerlerde kaybolabilir:

• Ağ: istek/yanıt süresi ve yük boyutu
• Sunucu: veritabanı sorguları, joinler, sıralama, izin kontrolleri
• Tarayıcı: JSON ayrıştırma, satır renderlama, büyük dizileri filtreleme

Bu ekran için “yeterince hızlı”nın ne demek olduğunu tanımlayın. Bir liste görünümü yazarken duyarlı yazı girişi ve akıcı kaydırma gerektirebilirken, bir rapor sayfası ilk sonuç hızlı göründüğü sürece kısa bir beklemeyi tolere edebilir.

Sadece ofis Wi‑Fi ile değerlendirmeyin. Yavaş bağlantılarda istemci tarafı filtreleme ilk yüklemeden sonra harika hissedebilir, ancak o ilk yükleme yavaş olabilir. Sunucu tarafı filtreleme yükleri küçük tutar, ama her tuş vuruşunda istek atarsanız gecikmeli hissedebilir.

İnsan girdiğine göre tasarlayın. Yazmayı debounce edin. Büyük sonuç setleri için, sayfa gösterimini kademeli yükleyin ki sayfa hızlıca bir şey göstersin ve kullanıcı kaydırdıkça yavaşça dolsun.

Karar faktörü 3: izinler ve veri açığa çıkması

İzinler, performanstan daha çok filtreleme yaklaşımınızı belirlemelidir. Tarayıcıya kullanıcıların görmesine izin verilmeyen veri bir kere gönderildiyse, zaten problem vardır; görsel olarak devre dışı bırakılmış bir düğme veya daraltılmış bir sütunla gizleseniz bile.

Bu ekranda neyin hassas olduğunu isimlendirerek başlayın. Bazı alanlar barizdir (e‑posta, telefon, adres). Diğerleri gözden kaçması kolaydır: dahili notlar, maliyet veya marj, özel fiyatlandırma kuralları, risk skorları, moderasyon flag'leri.

Büyük tuzak “istemci tarafında filtreleme yapıyoruz ama sadece izin verilen satırları gösteriyoruz” düşüncesidir. Bu hâlâ tam veri setinin indirildiği anlamına gelir. Herkes ağ yanıtını inceleyebilir, geliştirici araçlarını açabilir veya payload'u kaydedebilir. UI'da sütun gizlemek erişim kontrolü değildir.

Sunucu tarafı filtreleme güvenli varsayılandır

Farklı kullanıcıların farklı satırları görebildiği durumlarda sunucu tarafı filtreleme daha güvenli varsayılandır, özellikle farklı kullanıcılar farklı satırları veya alanları görebiliyorsa.

Hızlı kontrol:

• Farklı roller farklı satırlar görüyor mu (takım‑sadece, bölge‑sadece, bana‑atanmış)?
• Farklı roller farklı alanlar görüyor mu (notlar, fiyatlandırma, PII)?
• Satır düzeyinde kurallar var mı (hesap sahibi, anlaşma aşaması, “özel” flag)?
• Dışa aktarma, sıralama veya toplamlar kısıtlı bilgiyi açığa çıkarabilir mi?
• Sızan bir payload uyumluluk sorununa yol açar mı?

Eğer herhangi birine evet ise, filtreleme ve alan seçimini sunucuda tutun. Kullanıcıya yalnızca görmesine izin verileni gönderin ve aynı kuralları arama, sıralama, sayfalandırma ve dışa aktarma için de uygulayın.

Örnek: bir CRM iletişim listesinde temsilciler sadece kendi hesaplarını görürken yöneticiler tümünü görebilir. Tarayıcı tüm kişileri indirip yerelde filtre yaparsa, bir temsilci hala yanıt içinden gizli hesapları kurtarabilir. Sunucu tarafı filtreleme bunları asla göndermeyerek bunu engeller.

Karar faktörü 4: önbellekleme ve tazelik

Önbellekleme bir ekranı anlık hissettirebilir. Aynı zamanda yanlış gerçekliği gösterebilir. Anahtar, neyi yeniden kullanmaya izin verdiğinizi, ne kadar süre ve hangi olayların önbelleği silmesi gerektiğini kararlaştırmaktır.

Önce önbellek birimini seçin. Tam listeyi önbelleğe almak basittir ama genellikle bant genişliği israfı olur ve çabuk bayatlar. Sayfaları önbelleğe almak sonsuz kaydırma için iyi çalışır. Sorgu sonuçlarını (filtre + sıralama + arama) önbelleğe almak doğrudur ama kullanıcı birçok kombinasyon denedikçe büyüyebilir.

Tazelik bazı alanlarda daha önemlidir. Veri hızlı değişiyorsa (stok seviyeleri, bakiyeler, teslimat durumu) 30 saniyelik bir önbellek bile kullanıcıyı şaşırtabilir. Veri yavaş değişiyorsa (arşiv kayıtları, referans verisi) daha uzun önbellekler genellikle uygundur.

Kodu yazmadan önce invalidasyonu planlayın. Süre geçmesinin dışında hangi olaylar yenilemeyi zorlamalı: oluşturma/düzenleme/silme, izin değişiklikleri, toplu içe aktarma veya birleştirmeler, durum geçişleri, geri alma/rollback ve kullanıcıların filtrelediği alanları arka planda güncelleyen işler.

Ayrıca önbelleğin nerede yaşadığını kararlaştırın. Tarayıcı belleği geri/ileri gezinmeyi hızlı yapar, ama kullanıcı ve organizasyon bazında anahtar edilmezse hesaplar arasında veri sızdırabilir. Backend önbellekleme izinler ve tutarlılık için daha güvenlidir, ancak tam filtre imzası ve çağıran kimliği dahil edilmelidir ki sonuçlar karışmasın.

Adım adım: yeni bir ekran için nasıl seçilir

Hedef değişmez olmalı: ekran veri sızdırmadan hızlı hissetmeli.

Pratik karar akışı

1. En güçlü kısıtlamayla başla. Erişim role, takım, bölge, organizasyon veya abonelik tarafından değişiyorsa izinler kazanır. Veri seti büyük veya hızlı büyüyorsa boyut kazanır.
2. Veri büyük veya hassassa varsayılan olarak sunucu tarafına dön. Tam veri setini tarayıcı konsoluna kaydetmekten rahat olmazsanız, göndermeyin.
3. İstemci tarafı filtrelemeyi yalnızca küçük, güvenli, tekrar kullanılan listeler için kullanın. Durum açılır listeleri, küçük etiket listeleri, tek bir sayfada onaylanmış sonuçlar gibi.
4. UI'den önce API şeklini tanımlayın. Filtreleri, sıralamayı, sayfalandırmayı ve varsayılanları yazın ki sunucu ve UI anlaşmasın.
5. Koruyucu önlemler ekleyin. Maks sayfa boyutu uygulayın, zaman aşımı belirleyin ve filtreleme yavaşsa UI'nin nasıl davranacağını kararlaştırın (spinner göster, eski sonuçları tut, tekrar deneme öner).

Sızıntı veya gecikmeye neden olan yaygın hatalar

Çoğu ekip aynı desenlerden zarar görür: demo sırasında güzel görünen bir UI, gerçek veriler, gerçek izinler ve gerçek ağ hızlarıyla kırılır.

Veri sızdıran hatalar

En ciddi hata filtrelemeyi sunum olarak görmek. Tarayıcı alması gereken kayıtları alıyorsa, zaten kaybettiniz.

İki yaygın sebep:

• Hızı gerekçe gösterip tam veri setini tarayıcıya gönderip yerelde filtrelemek. Herkes yanıtı inceleyebilir veya bellekte sorgulayabilir.
• Filtrelenmiş yanıtları önbelleğe alıp önbellek anahtarını kullanıcı kimliği, organizasyon, rol veya politika versiyonuna bağlamamak. Bir izin değişikliği eski verileri sessizce açığa çıkarabilir.

Örnek: stajyerler sadece bölgelerine ait lead'leri görmelidir. API tüm bölgeleri döndürürse ve dropdown React'te filtre yapıyorsa, stajyer yine tam listeyi çıkarabilir.

Ekranı yavaş hissettiren hatalar

Gecikme genellikle varsayımlardan gelir:

• İstemci tarafı filtrelemenin her zaman daha hızlı olduğunu varsaymak. 50.000 satırla indirme ve ayrıştırma, odaklanmış bir sorgudan daha uzun sürebilir.
• Sayfalandırma ve yükleme durumlarını unutmak. Büyük bir liste render ederken ekran bloklanıyorsa, sorgu doğru olsa bile kırık hisseder.

İnce ama acı veren bir sorun da eşleşmeyen kurallardır. Sunucu “başlayan ile” diye ele alırken UI farklı davranırsa kullanıcılar sayımların eşleşmediğini veya öğelerin yenilemeden sonra kaybolduğunu görür.

Göndermeden önce hızlı kontrol listesi

İki bakış açısıyla son bir geçiş yapın: meraklı bir kullanıcı ve kötü ağ günü.

• Yük sağduyusu: yanıtların kullanıcı görmemesi gereken satır veya alanları asla içermediğini doğrulayın, UI bunları gizlese bile. Toplamlar, grup sayıları veya ID'ler kısıtlı veriyi türetebilir.
• Güvenli loglama: filtreler genellikle e‑posta, isim veya ID içerir. Hassas filtre değerlerini, tam SQL'i veya tam istek gövdelerini herkesin erişebildiği yerlerde kaydetmeyin.
• Cihazlar arası tutarlılık: desktop ve mobilde aynı filtreleri uygulayın. Farklar genellikle istemci tarafı sıralama, yerel kurallar (büyük/küçük harf, aksanlar) veya varsayılan değerlerden gelir.
• Açık durumlar: yükleniyor, boş ve hata durumları belli olmalı. Hızlı değişimleri (yaz, backspace, toggla) test edin ki UI titremesin veya bayat sonuç göstermesin.
• En kötü durum koruyucuları: maksimum sayfa boyutu, maksimum tarih aralığı ve zaman aşımı. Pahalı sorgulara karşı koruyun (joker, çok fazla OR koşulu, indekslenmemiş alanlar).

Basit bir test: kısıtlı bir kayıt oluşturun ve geniş şekilde filtreleseniz veya filtreleri temizleseniz bile payload'ta, sayımlarda veya önbellekte asla görünmediğini doğrulayın.

Örnek senaryo: bir CRM iletişim listesi

200.000 iletişime sahip bir CRM hayal edin. Satış temsilcileri sadece kendi hesaplarını görebilir, yöneticiler ekiplerini, adminler her şeyi görebilir. Ekranda arama, filtreler (durum, sahip, son aktivite) ve sıralama var.

İstemci tarafı filtreleme burada çabuk başarısız olur. Yük ağırdır, ilk yük yavaşlar ve veri sızıntısı riski yüksektir. UI satırları gizlese bile tarayıcı veriyi almıştır. Ayrıca cihaza baskı yaparsınız: büyük diziler, ağır sıralama, tekrar eden filtre çalıştırmaları, yüksek bellek kullanımı ve eski telefonlarda çökme.

Daha güvenli yaklaşım sayfalandırmalı sunucu tarafı filtrelemedir. İstemci filtre seçimlerini ve arama metnini gönderir; sunucu yalnızca kullanıcının görmesine izin verilen, zaten filtrelenmiş ve sıralanmış satırları döndürür.

Pratik bir desen:

• Önce izinleri uygulayın, sonra filtreleri ve sıralamayı.
• Bir seferde bir sayfa döndürün (ör. 50 satır) artı toplam sayıyı.
• Önbellekleme dikkatli yapılandırın (kullanıcı veya rol bazlı) ki izinler arasında sonuç karışmasın.

Küçük bir istisna: küçük, statik veriler için istemci tarafı filtreleme uygundur. 8 değerden oluşan bir “İletişim durumu” açılır listesi bir kez yüklenip yerelde güvenle filtrelenebilir.

Sonraki adımlar: kararları belgeleyin ve daha az yeniden yazma ile inşa edin

Ekipler genellikle “yanlış” seçimi bir kere yapmaktan yanmazlar. Her ekranda farklı bir seçim yapıp sonra sızıntıları ve yavaş sayfaları baskı altında düzeltmeye çalışırken yanılırlar.

Her ekran için kısa bir karar notu yazın: filtreler, veri seti büyüklüğü, göndermenin maliyeti, “yeterince hızlı” hissinin tanımı, hangi alanların hassas olduğu ve sonuçların nasıl önbelleğe alınacağı (veya alınmayacağı). Sunucu ve UI'yi hizalı tutun ki filtreleme için “iki gerçeklik” oluşmasın.

Eğer Koder.ai (koder.ai) ile hızlı ekranlar inşa ediyorsanız, baştan hangi filtrelerin backend'de zorlanması gerektiğini (izinler ve satır seviyesinde erişim) ve hangi küçük, UI-özel geçişlerin React katmanında kalabileceğini belirlemek faydalıdır. Bu bir seçim genellikle sonraki en maliyetli yeniden yazmaları önler.