Veri boyutu, gecikme, izinler ve önbellekleme temelinde sunucu veya istemci tarafı filtreleme seçimi için kontrol listesi; UI sızıntıları veya takılmalar olmadan karar verin.
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:
Üçü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.
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:
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.
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:
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.
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:
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.
İ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.
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:
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.
Ö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.
Hedef değişmez olmalı: ekran veri sızdırmadan hızlı hissetmeli.
Ç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.
En ciddi hata filtrelemeyi sunum olarak görmek. Tarayıcı alması gereken kayıtları alıyorsa, zaten kaybettiniz.
İki yaygın sebep:
Ö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.
Gecikme genellikle varsayımlardan gelir:
İ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.
İki bakış açısıyla son bir geçiş yapın: meraklı bir kullanıcı ve kötü ağ günü.
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.
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:
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.
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.
Sunucunun varsayılan olarak tercih edilmesi gerekir: kullanıcıların farklı izinleri varsa, veri seti büyükse veya tutarlı sayfalandırma ve toplamlar sizin için önemliyse. İstemci tarafı filtreleme yalnızca tüm veri seti küçükse, açığa çıkarmak güvenliyse ve indirmesi hızlıysa kullanılmalı.
Tarayıcıya ne gönderilirse incelenebilir. UI satırları veya sütunları gizlese bile kullanıcı ağ yanıtlarını, önbelleklenmiş yükleri veya bellekteki nesneleri görebilir.
Genellikle çok fazla veri gönderip her tuş vuruşunda büyük dizileri filtrelemek/sıralamak ya da her tuş vuruşunda debounced olmayan sunucu istekleri göndermekten kaynaklanır. Yükleri küçük tutun ve her giriş değişiminde ağır işler yapmaktan kaçının.
“Gerçek” filtreler için tek bir gerçek kaynağı tutun: izinler, arama, sıralama ve sayfalandırma birlikte sunucuda uygulanmalı. Ardından istemci tarafı mantığını, temel veri setini değiştirmeyen küçük UI-özel geçişlerle sınırlayın.
İstemci tarafı önbellekleme bayat veya yanlış veri gösterebilir ve doğru anahtarla yapılmazsa hesaplar arasında veri sızdırabilir. Sunucu tarafı önbellekleme izinler için daha güvenlidir; ancak tam filtre imzasını ve çağıran kimliğini içermelidir ki sonuçlar karışmasın.
İki soru sorun: bir kullanıcının gerçekte kaç satırı olabileceği ve her satırın byte cinsinden büyüklüğü. Tipik bir mobil bağlantıda rahatça yükleyemeyeceğiniz bir miktarsa, filtrelemeyi sunucuya taşıyın ve sayfalayın.
Sunucu tarafı. Roller, ekipler, bölgeler veya sahiplik kuralları birinin görebileceği satır veya alanları değiştiriyorsa, sunucu satır ve alan erişimini uygulamalıdır. İstemci yalnızca kullanıcının görmesine izin verilen kayıtları ve alanları almalı.
Önce API sözleşmesini tanımlayın: kabul edilen filtre alanları, varsayılan sıralama, sayfalandırma kuralları ve aramanın nasıl eşleştirdiği (büyük/küçük harf, aksanlar, kısmi eşleşme). Sonra aynı mantığı backend'de tutarlı biçimde uygulayın ve toplamlar ile sayfaların eşleştiğini test edin.
Yazmayı debounced yapın ki her tuş vuruşunda istek atılmasın, yeni sonuç gelene kadar eski sonuçları görünür tutun ki titreme azalır. Kullanıcıya hızlı bir şey göstermek için sayfalandırma veya kademeli yükleme kullanın, böylece büyük bir yanıt için engelleme olmaz.
İzinleri önce uygulayın, sonra filtreleri ve sıralamayı uygulayın; yalnızca bir sayfa ve toplam sayıyı döndürün. “İhtimal için ekstra alanlar” göndermekten kaçının ve önbellek anahtarlarının kullanıcı/organizasyon/rol içerdiğinden emin olun ki bir satış temsilcisi yöneticilere ait verileri almasın.
