Informazioni sul filtraggio delle applicazioni Web lato client vs lato server?

Question

Informazioni sul filtraggio delle applicazioni Web lato client vs lato server?

#1 da (6 voti)

4

Ho un'app web che fornisce dati (aggiornati su un intervallo) per gli utenti della rete Intranet, che sono in grado di filtrare le informazioni in base alla posizione.

Stavo discutendo con un collega sul fatto che il filtro dovesse avvenire sul lato client vs server. La quantità di informazioni non è ampia, ma gli utenti sono in genere interessati a una determinata posizione.

La mia domanda ... è preferibile lasciare che il database filtri i dati e invii i risultati al client, o restituisca tutti i dati al client e poi li ordina per posizione? Se non è chiaro, quando sceglieresti il metodo rispetto all'altro?

sql web-development web-applications

posta fbynite 15.07.2014 - 06:20

fonte

1 risposta

Leggi altre domande sui tag sql web-development web-applications

Problema della password del database quando si utilizza GIT per gestire il progetto che utilizza Spring per avviare l'origine dati Se utilizzo i componenti con licenza MIT nel mio software, i miei clienti possono rivenderli?

score 6 · Accepted Answer

Alcuni problemi di filtraggio del lato client:

Invalidità della cache . Il filtro lato server funzionerà sempre con dati aggiornati, mentre le cache client dovranno essere aggiornate quando i dati cambiano. Questo può essere molto complesso a seconda della correttezza che si desidera avere. Il futuro sviluppatore maledirà questa soluzione. Se non funziona correttamente, i clienti malediranno questa soluzione.
Lingua query . Il tuo server supporta già SQL out of the box (assunto a causa del tag "sql") ed è molto diverso da JSON + JavaScript, il candidato più ovvio per una soluzione di interrogazione lato client. Potrebbe esserci una struttura dati lato client sufficientemente generica + una soluzione di interrogazione in giro che è possibile schiaffarla sul sito Web con quasi nessuno sforzo, ma l'alternativa invariabilmente risulterà in un codice più (e più complesso) rispetto all'utilizzo di query lato server . Il futuro sviluppatore maledirà questa soluzione.
Propagazione delle modifiche al codice . Molti siti Web sono caduti in una trappola con codice lato client in cui un aggiornamento della pagina non scarica il codice più recente. Probabilmente, gli utenti non saranno in grado di eseguire query fino a quando non svuoteranno la cache del browser. I clienti malediranno questa soluzione.
Dimensione del trasferimento di rete . Potresti avere un piccolo database in questo momento, ma trasferirlo a tutti i clienti su base regolare sarà piuttosto lento e costoso a lungo termine. Il sysadmin maledirà questa soluzione. Qualsiasi cliente con connessioni lente maledirà questa soluzione.
Uso CPU / batteria . JavaScript utilizza più CPU (e quindi batteria) rispetto al testo normale. E no, non avrai le risorse per ottimizzare il codice. I clienti con laptop e macchine lente malediranno questa soluzione.

Se il tuo database è veramente piccolo e crei una soluzione di filtraggio lato server che è praticamente sensata, il tempo di andata e ritorno del filtro dovrebbe essere nei bassi millisecondi. Questo è abbastanza veloce che nessuno se ne accorgerà e tu eviterai un sacco di complessità extra e possibili problemi.