Logica lato client O logica lato server?

Question

Ho fatto alcuni progetti basati sul web e la maggior parte delle difficoltà che ho incontrato (domande, confusione) potrebbero essere risolte con l'aiuto. Ma ho ancora una domanda importante, anche dopo aver chiesto ad alcuni sviluppatori esperti: Quando la funzionalità può essere implementata sia con codice lato server e scripting lato client (JavaScript), quale dovrebbe essere preferito?

Un semplice esempio:

per il rendering di una pagina html dinamica, posso formattare la pagina in codice lato server (PHP, Python) e utilizzare Ajax per recuperare la pagina formattata e renderlo direttamente (più logica sul lato server, meno sul lato client).

È anche possibile utilizzare Ajax per recuperare i dati (non formattati, JSON) e utilizzare lo script sul lato client per formattare la pagina e renderla più elaborata (il server riceve i dati da un DB o altra origine e restituisce al client con JSON o XML. Più logica sul lato client e meno sul server).

Quindi, come posso decidere qual è il migliore? Quale offre prestazioni migliori? Perché? Quale è più user-friendly?

Con i motori JS dei browser in evoluzione, JS può essere interpretato in meno tempo, quindi dovrei preferire lo scripting lato client?

D'altra parte, con l'hardware in continua evoluzione, le prestazioni del server sono in aumento e il costo della logica lato server diminuirà, quindi dovrei preferire lo scripting lato server?

EDIT:

Con le risposte, voglio dare un breve riassunto.

A favore di logica lato client:

1. migliore esperienza utente (più veloce).
2. Minore larghezza di banda della rete (costo inferiore).
3. Scalabilità aumentata (carico server ridotto).

A favore di logica server-side:

1. problemi di sicurezza.
2. Migliore disponibilità e accessibilità (dispositivi mobili e vecchi browser).
3. Meglio SEO.
4. Espandibile facilmente (può aggiungere più server, ma non può rendere il browser più veloce).

Sembra che abbiamo bisogno di bilanciare questi due approcci di fronte a uno scenario specifico. Ma come? Qual è la migliore pratica?

userò la logica lato client ad eccezione delle seguenti condizioni:

1. critici di sicurezza.
2. Gruppi speciali (JavaScript disabilitato, dispositivi mobili e altro).

Answer 1

In molti casi, temo che la risposta migliore sia sia.

Come affermato da Ricebowl, non fidarsi mai del cliente. Tuttavia, ritengo che sia quasi sempre un problema se ti fidi del cliente. Se vale la pena scrivere la tua applicazione, vale la pena proteggerla correttamente. Se qualcuno può infrangerlo scrivendo il proprio client e passando dati che non ti aspetti, è una brutta cosa. Per questo motivo, è necessario convalidare sul server.

Sfortunatamente se si convalida tutto sul server, questo spesso lascia all'utente un'esperienza utente scadente. Possono compilare un modulo solo per scoprire che un numero di cose che hanno inserito non sono corretti. Questo potrebbe aver funzionato per "Internet 1.0", ma le aspettative della gente sono più alte su Internet di oggi.

Questo potenzialmente ti lascia scrivere un bel po 'di codice ridondante e mantenerlo in due o più posti (alcune delle definizioni come le lunghezze massime devono essere mantenute anche nel livello dati). Per applicazioni ragionevolmente grandi, tendo a risolvere questo problema utilizzando la generazione del codice. Personalmente utilizzo uno strumento di modellazione UML (Enterprise Architect di Sparx System) per modellare le "regole di input" del sistema, quindi utilizzare classi parziali (di solito lavoro in .NET) per codificare la logica di validazione. È possibile ottenere una cosa simile codificando le proprie regole in un formato come XML e derivando un numero di verifiche da quel file XML (lunghezza dell'input, maschera di input, ecc.) Sul livello client e server.

Probabilmente non è quello che volevi sentire, ma se vuoi farlo bene, devi applicare le regole su entrambi i livelli.

Answer 2

Penso che la seconda variante sia migliore. Ad esempio, se implementi qualcosa di simile a "skin" in un secondo momento, ti ringrazierai di non aver formattato il codice HTML sul server :)

Mantiene anche una differenza tra visualizzazione e controller. I dati Ajax sono spesso prodotti dal controller, quindi lascia che restituisca solo i dati, non html.

Se avete intenzione di creare un'API in seguito, sarà necessario apportare poche modifiche nel codice

Inoltre, i dati 'nudo' è più cachable di HTML, credo. Ad esempio, se aggiungi uno stile ai collegamenti, dovrai riformattare tutto il codice HTML o aggiungere una riga al tuo js. E non è grande quanto l'html (in byte).

Ma se sono necessari molti script pesanti per formattare i dati, non è interessante chiedere ai browser degli utenti di formattarlo.

Answer 3

Tendo a preferire la logica lato server. Le mie ragioni sono abbastanza semplici:

1. Non mi fido del cliente; questo può essere o non essere un vero problema, ma è abituale
2. lato server riduce il volume per transazione (anche se aumenta il numero di transazioni)
3. lato server significa che posso essere abbastanza sicuro su quale logica è in corso (non devo preoccuparmi del motore Javascript disponibile per il browser del client)

Probabilmente ci sono più - e migliori - ragioni, ma queste sono le più importanti in questo momento. Se penso a più li aggiungerò, o ascolterò quelli che li inventano prima di me.

---

Modificato, valya commenti che l'utilizzo della logica lato client (utilizzando Ajax/JSON) consente la (più semplice) creazione di un'API. Questo potrebbe essere vero, ma posso solo acconsentire (è per questo che non ho ancora votato questa risposta).

La mia nozione di logica lato server è quella che recupera i dati e li organizza; se ho capito bene la logica è il 'controller' (C in MVC). E questo è poi passato alla 'vista'. Io tendo ad usare il controller per ottenere i dati, quindi la 'vista' si occupa di presentarla all'utente/cliente. Quindi non vedo che le distinzioni client/server siano necessariamente rilevanti per l'argomento della creazione di un'API, in pratica: cavalli per i corsi. :)

... inoltre, come hobbista, riconosco che potrei avere un utilizzo leggermente distorto di MVC, quindi sono disposto a correggermi su questo punto. Ma continuo a tenere la presentazione separata dalla logica. E quella separazione è il punto in più per quanto riguarda le API.

Answer 4

Finché non è necessario inviare molti dati al client per consentirgli di eseguire il lavoro, il lato client offre un sistema più scalabile, in quanto si sta distrubuendo il carico per i client anziché martellare il tuo server per fare tutto.

Il rovescio della medaglia, se è necessario elaborare un sacco di dati per produrre una piccola quantità di html da inviare al client, o se è possibile effettuare ottimizzazioni per utilizzare il lavoro del server per supportare più client contemporaneamente (ad es. elaborare i dati una volta e inviare l'html risultante a tutti i client), quindi potrebbe essere un uso più efficiente delle risorse per eseguire il lavoro sul server.

Answer 5

Generalmente implemento il lato client ragionevole. Le uniche eccezioni che farebbero andare sul lato server sarebbe quello di risolvere il seguente:

Fiducia emette

Chiunque è in grado di eseguire il debug JavaScript e leggere la password di, ecc gioco da ragazzi qui.

prestazioni emette

motori JavaScript si stanno evolvendo velocemente, quindi questo sta diventando un problema minore, ma siamo ancora in un mondo IE-dominato, quindi le cose saranno rallentare quando avete a che fare con la grande insiemi di dati.

Lingua questioni linguistiche

è debolmente tipizzato Javascript e fa un sacco di ipotesi di codice. Questo può causare l'impiego di soluzioni spettrali per far funzionare le cose come dovrebbero su determinati browser. Evito questo tipo di cose come la peste.

---

Dalla tua domanda, sembra che tu stia semplicemente cercando di caricare valori in un modulo. Escludendo una delle questioni di cui sopra, si dispone di 3 opzioni:

Pure lato client

Lo svantaggio è che il tempo di caricamento dei vostri utenti sarebbe doppia (un carico per il modulo in bianco, un altro carico per i dati). Tuttavia, gli aggiornamenti successivi al modulo non richiederebbero un aggiornamento della pagina. Agli utenti piacerà questo se ci sarà un sacco di recupero dei dati dal caricamento del server nello stesso modulo.

Pure lato server

Il vantaggio è che la pagina si carica i dati contenuti. Tuttavia, i successivi aggiornamenti dei dati richiederebbero l'aggiornamento a tutte le parti significative della pagina.

server-client ibrido

Si avrebbe il meglio dei due mondi, ma si avrebbe bisogno di creare due punti di estrazione dei dati, causando il codice per gonfiare un po '.

Non ci sono compromessi con ogni opzione in modo da avere a pesare e decidere quale vi offre il massimo beneficio.

Answer 6

Mi piacerebbe dare i miei due centesimi su questo argomento.

Sono generalmente a favore di un approccio server-side, ed ecco perché.

• Più SEO friendly. Google non può eseguire Javascript, quindi tutto quel contenuto sarà invisibile ai motori di ricerca
• Le prestazioni sono più controllabili. L'esperienza utente è sempre variabile con SOA perché ti stai affidando quasi interamente al browser e alla macchina degli utenti per eseguire il rendering. Anche se il tuo server sta andando bene, un utente con una macchina lenta pensa che il tuo sito sia il colpevole.
• Probabilmente, l'approccio lato server è più facilmente gestibile e leggibile.

Ho scritto diversi sistemi utilizzando entrambi gli approcci e, secondo la mia esperienza, il lato server è il modo. Tuttavia, questo non vuol dire che non usi AJAX. Tutti i sistemi moderni che ho costruito incorporano entrambi i componenti.

Spero che questo aiuti.

Answer 7

Una considerazione non ho sentito menzionato era la larghezza di banda della rete. Per dare un esempio specifico, un'app con cui ero coinvolto era stata gestita dal lato server e il sito Web da 200 Mb veniva inviato al client (era impossibile fare di meno senza importanti riprogettazioni importanti di un gruppo di app); con conseguente tempo di caricamento della pagina di 2-5 minuti.

quando abbiamo ri-implementato inviando i dati JSON-codificato dal server e hanno JS locali generare la pagina, il vantaggio principale è che i dati inviati ridotto a 20Mb, con conseguente:

• HTTP dimensione di risposta: 200Mb + => 20Mb + (con corrispondenti risparmio di banda!)

• tempo per caricare la pagina: 2-5mins => 20 sec (10-15 dei quali sono tratti da interrogazione DB che è stato ottimizzato all'inferno un ulteriore).

• processo di IE dimensione: 200MB + => 80 MB +

Intendiamoci, gli ultimi 2 punti sono stati principalmente a causa del fatto che il lato server ha dovuto usare scadente implementazione albero tavoli-entro-tavoli, mentre in corso dal lato client ci ha permesso di ridisegnare il livello di visualizzazione per utilizzare una pagina molto più leggera. Ma il mio punto principale era il risparmio della larghezza di banda della rete.

Answer 8

Se lo fate in Ajax:

si dovrà prendere in considerazione i problemi di accessibilità (ricerca su web in Google) per le persone disabili, ma anche per i vecchi browser, quelli che non hanno JavaScript, bot (come google bot), ecc.

Dovrai flirtare con "miglioramento progressivo" che non è semplice da fare se non hai mai lavorato molto con JavaScript. In breve, dovrai far funzionare la tua app con i vecchi browser e quelli che non hanno JavaScript (alcuni cellulari per esempio) o se è disabilitato.

Ma se tempo e denaro non sono un problema, andrei con miglioramento progressivo.

Ma considerare anche il "pulsante Indietro". Lo odio quando sto navigando su un sito web 100% AJAX che rende inutilizzabile il tuo pulsante indietro.

Buona fortuna!

Answer 9

ho costruito un'applicazione web RESTful dove sono disponibili tutti funzionalità CRUD in assenza di JavaScript, in altre parole, tutti gli effetti AJAX sono rigorosamente miglioramenti progressivi.

Credo con sufficiente dedizione, la maggior parte delle applicazioni Web possono essere progettate in questo modo, erodendo quindi molte delle "differenze" logiche del server vs logica client, come sicurezza, espandibilità, sollevate nella domanda perché in entrambi i casi, la richiesta viene instradato allo stesso controller, di cui la logica di business è lo stesso fino all'ultimo miglio, dove JSON/XML, invece dell'intero HTML della pagina, viene restituito per quelli XHR.

Solo in alcuni casi in cui l'applicazione AJAXified è molto più avanzata della sua controparte statica, GMail è l'esempio migliore che mi viene in mente, quindi è necessario creare due versioni e separarle completamente (Kudos su Google!).

Answer 10

In questa fase la tecnologia lato client sta aprendo la strada, con l'avvento di molte librerie lato client come Backbone, Knockout, Spine e quindi con l'aggiunta di modelli lato client come JSrender, baffi, ecc, lo sviluppo lato client è diventato molto facile. quindi, se il mio requisito è quello di andare per l'app interattiva, andrò sicuramente per il lato client. Nel caso si abbia più contenuto html statico, allora si deve andare dal lato server. Ho fatto alcuni esperimenti usando entrambi, devo dire che il lato server è relativamente più facile da implementare quindi lato client. Per quanto riguarda le prestazioni. Leggilo capirai i punteggi delle prestazioni lato server. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

Answer 11

So che questo post è vecchio, ma volevo commentare.

Secondo la mia esperienza, l'approccio migliore è l'utilizzo di una combinazione di lato client e lato server. Sì, Angular JS e framework simili sono ora popolari e hanno reso più facile lo sviluppo di applicazioni Web leggere, con prestazioni migliorate e lavoro sulla maggior parte dei server web. MA, il requisito principale nelle applicazioni aziendali è la visualizzazione di dati di report che possono comprendere oltre 500 record su una pagina. Con le pagine che restituiscono grandi elenchi di dati, gli utenti spesso desiderano funzionalità che renderanno questo elenco enorme facile da filtrare, cercare ed eseguire altre funzionalità interattive. Poiché IE 11 e i browser IE precedenti sono il "browser di scelta" della maggior parte delle aziende, devi essere consapevole del fatto che questi browser hanno ancora problemi di compatibilità con i moderni JavaScript, HTML5 e CSS3. Spesso, l'esigenza è di rendere un sito o un'applicazione compatibile su tutti i browser. Ciò richiede l'aggiunta di shiv o l'utilizzo di prototipi che, con il codice incluso per creare un'applicazione client-side, aggiungono al caricamento della pagina sul browser.

Tutto ciò riduce le prestazioni e può causare il temuto errore di IE "Uno script su questa pagina sta causando l'esecuzione di Internet Explorer lentamente" costringendo l'utente a scegliere se continuare a eseguire lo script oppure no ... creando cattive esperienze utente.

Determinare la complessità dell'applicazione e ciò che l'utente desidera ora e potrebbe desiderare in futuro in base alle proprie preferenze nelle applicazioni esistenti. Se si tratta di un semplice sito o di un'app con dati medio-piccoli, utilizzare JavaScript Framework. Ma, se vogliono incorporare l'accessibilità; SEO; o è necessario visualizzare grandi quantità di dati, utilizzare il codice lato server per eseguire il rendering di dati e codice lato client con parsimonia. In entrambi i casi, utilizza uno strumento come Fiddler o gli strumenti per sviluppatori di Chrome per controllare i tempi di caricamento e risposta della pagina e utilizzare le best practice per ottimizzare il codice.

Acquista app MVC sviluppate con ASP.NET Core.