Pro / contro tra enfatizzazione dell'elaborazione lato client o lato server

Ci sono due problemi principali.

1. Il primo è semplice: di solito non si sa quale tipo di risorse sono disponibili sul lato client. Se richiede 1.5 GB per elaborare qualcosa, è possibile inserirlo in un browser client sconosciuto (IE, Safari, Opera, Firefox, ecc.) Su una piattaforma client sconosciuta? Il cliente apprezzerà il suo sistema di dogging quando lo sommergerai?

2. Il secondo è più architettonico: quali strati vuoi esporre al mondo esterno? La maggior parte sarebbe d'accordo sul fatto che è incredibilmente rischioso esporre il livello dati. E il tuo livello di servizio? Vuoi davvero fornire quella logica là fuori? Se lo fai, stai esponendo anche i punti di ingresso al tuo livello dati? Se mantieni il lato server del livello di servizio, cosa rimane? L'interfaccia utente, giusto? Vedi la motivazione 1 per le considerazioni su quanto di esso vive sul server e su quanto sul client.

Prima di tutto Sicurezza . Spingi tutta la tua logica al client ed è un gioco leale per hacker e exploit.

Qualsiasi cosa con qualsiasi valore percepito non durerà 5 minuti, in particolare il valore monetario, e sarà giocata, hackerata o sfruttata e interromperà molto il tuo sistema. Anche se ha poco o nessun valore monetario, c'è una classe di persone che lo hackerà per rompere il tuo sistema perché sono annoiati.

Lato client e lato server

L'elaborazione lato client è in linea con gli standard REST più popolari e con MVC e approcci basati su pagine e SOAP. L'emergere di queste tendenze e concentrarsi su AJAX e Html-RIA, scripting lato client è in aumento e più popolare; tuttavia, a causa di problemi di sicurezza e capacità del client, lo scripting lato client ha una nicchia particolare e non dovrebbe essere usato per tutto.

Considerazioni:

Cellulare

Se un segmento ampio del pubblico di destinazione saranno utenti mobili, l'elaborazione intensiva dovrebbe essere lasciata al server.

Consistenza cross-browser

Gli standard web hanno fatto molta strada e questo potrebbe non essere un problema, ma ogni sviluppatore web sa che IE 6,7, e 8 e talvolta Safari possono comportarsi in modo divertente dal lato client - alcune funzioni potrebbero non eseguire a causa di restrizioni di sicurezza e altri a causa di standard non implementati. È anche importante notare che l'utente finale può configurare un browser per avere alcune restrizioni o addirittura disattivare completamente l'elaborazione lato client (nessun javascript!). Se la coerenza è un requisito per il 100% degli utenti (e soprattutto se stai facendo qualcosa di non ortodosso) il lato server è più importante.

Sicurezza

Qualsiasi manipolazione di dati che si desidera proteggere deve essere eseguita sul server. Qualsiasi dato elaborato sul lato client è assolutamente aperto per la manipolazione. Ad esempio, se hai una funzione javascript che elabora alcune informazioni che poi vengono reinserite nel sistema, sarebbe molto facile manipolare il risultato appena prima che venga posticipato anche se hai una sicurezza back-end esemplare

UI / UX

L'elaborazione lato client è lasciata all'interfaccia utente e alla creazione di ricche applicazioni Internet (RIA). È utilizzato per creare animazioni, effetti, interazioni dell'utente e caricare dinamicamente il contenuto tramite chiamate AJAX anziché ricaricare un'intera pagina.

In primo luogo sarà una duplicazione degli sforzi. Molto probabilmente tutti i dati dal client saranno controllati ed elaborati di nuovo a livello di server.

Il server non può presumere che il tuo client ricco / robusto abbia inviato i dati, quindi con qualsiasi dato inviato, il server deve convalidarlo ed elaborarlo. Quindi ha senso metterlo lì.

Tuttavia, credo che alcune logiche possano essere fatte a livello di client per una migliore esperienza di interfaccia utente.

Sei corretto, perché inviare dati al server se non è completo o errato. È facile controllare i campi richiesti o i telefoni o gli indirizzi e-mail correttamente formattati. Non mi è mai piaciuto inviare un modulo e poi aspettare 5 secondi per dirmi che ho dimenticato di entrare in un campo. Questo tipo di elaborazione, certo, lo fa sul client e si assicura che sia corretto e utilizza la logica lato client per una risposta rapida all'utente. Come hai sottolineato, un effetto collaterale positivo sarebbe che il tuo server avrebbe dovuto gestire richieste di dati meno cattive. MA, il server deve ancora convalidare, quindi si sta facendo un ragionamento logico. Ma i tuoi utenti saranno più felici.

C'è una linea sottile qui. Semplice logica di convalida OK, logica di core business non OK.

1. Prima di tutto devi capire l'architettura delle applicazioni web, la maggior parte se non tutte sono a 3 livelli:

   a) Client / Presentazione - HTML e Javascript, possono contenere ActiveX / Flash / Applet Java / Silverlight. Uscirò su un arto e aggiungerò applicazioni mobili native che comunicano con un server di back-end. Fondamentalmente il ruolo di questo livello è quello di fornire un'interfaccia per l'utente del sistema per interagire con esso.

   b) Business Logic - PHP / RoR / Java in cui i dati del client vengono raccolti, elaborati e archiviati e in cui le richieste dei client per i dati vengono elaborate e inviate al client

   c) Backend Data Store: fornisce memoria permanente per le informazioni di sistema

2. Quindi, dove fai la validazione, in tutti i livelli. Perché?

   a) Lato client - assicurati che l'utente inserisca dati corretti, campi obbligatori ecc.

   b) Logica aziendale: filtrare, disinfettare e convalidare i dati del cliente. Esegui regole aziendali più complesse per garantire che i dati siano ben formati per l'archiviazione. Alcune delle convalide eseguite sul front-end vengono ripetute qui, poiché potrebbero esserci client diversi, ad esempio i browser che JavaScript può essere disabilitato. Ad esempio, può anche accettare dati da diverse fonti tramite API, quindi è necessario convalidarli tutti.

   c) Backend Data Store: i vincoli assicurano che i dati siano ben formati per la memorizzazione e il successivo recupero.

Quindi, dove focalizzi i tuoi sforzi di convalida, usa ogni livello per eseguire la convalida che si adatta meglio e lascia le regole più complesse per il livello in grado di gestirlo

Una grande parte è mantenere il processo vicino ai tuoi dati. Se hai centinaia di GB di dati, ovviamente non li spedirai a un cliente. Con l'aumento della velocità di accesso ai dati questo sta diventando meno di un problema, ma se hai un sito Big Data, vuoi comunque filtrare e restringere il server quanto più puoi prima di spedirlo.

Quando crei il tuo comportamento completamente sul lato client (ad esempio, con Javascript), la SEO può diventare un problema.

Le websolutions che mantengono molto sul lato server sono più facilmente in grado di mantenere i contenuti specifici pubblicati su un URL specifico (solitamente RESTful), in un modo che è visibile ai motori di ricerca.

Ciò significa anche che un visitatore può aggiungere un segnalibro a una pagina specifica. L'hai provato su Facebook?

Questa roba può essere risolta, ma di solito è incorporata in applicazioni che fanno molto sul server (RAILS, WordPress ecc.), mentre se stai costruendo, diciamo REACT, dovrai saltare i cerchi.

Il motivo è stabilità .

Dal lato server, posso scegliere componenti stabili. Di solito questo significa che scelgo Java e un mucchio di librerie molto attentamente selezionate come FreeMarker. Inutile dire che ogni libreria, a prescindere dalle librerie standard di Java, viene trattata come usa e getta, quindi accedo alle librerie esterne tramite un wrapper self-made. Ciò significa che posso cambiare facilmente da una libreria all'altra se si presenta il bisogno.

Ogni volta che aggiorno Java a una nuova versione, di solito funziona bene perché Java è un componente estremamente stabile anche attraverso i principali aggiornamenti di versione. E inoltre, ogni server che ho sta eseguendo la stessa versione di Java. Non tutti i client eseguono la stessa implementazione JavaScript.

Sul lato client, non posso scegliere componenti stabili. I produttori di browser mi obbligheranno a scegliere JavaScript, un linguaggio che non mi piace particolarmente, ma che sono obbligato a usare. (E non parlarmi di linguaggi compilati in JavaScript, sono orribili!) L'implementazione JavaScript di ogni browser è diversa. Ciò significa che è un vero inferno testare il mio prodotto con tutte le versioni supportate del browser.

La mia soluzione? Eseguo il maggior numero di elaborazioni possibile sul lato server e il lato client è solo un involucro leggero che invia i dati al server e riceve i dati dal server sotto forma di frammenti JSON e HTML. Evitare XML; usa invece JSON.

Non faccio il template sul lato client; Rendo il contenuto del server su un frammento HTML che poi assegno utilizzando l'attributo .innerHTML a vari elementi segnaposto sul lato client. Ciò mantiene lo stack tecnologico il più semplice possibile, perché non ho bisogno di due motori di template (uno Java e uno JavaScript).

L'inconveniente è ovviamente la latenza della velocità della luce; mezzo secondo di latenza non è raro tra i continenti.

Considera che i tuoi clienti in questi giorni potrebbero essere gli smartphone. Gli smartphone hanno una durata limitata della batteria, quindi se stai facendo calcoli pesanti, meglio scaricarlo sui tuoi server. Tuttavia, le cose semplici possono essere più efficienti dal punto di vista energetico quando vengono eseguite dal lato client, perché in tal caso è possibile evitare l'accesso radio. Ma l'argomento principale, la stabilità, potrebbe significare che in realtà potrebbe avere senso scaricare anche il calcolo semplice sul server.

Come appendice, come già osservato in alcune risposte, ottieni anche sicurezza . Se la logica dell'applicazione è interamente sul lato client, qualcuno può ad es. impostare un prezzo per qualsiasi cosa che stanno per acquistare dal tuo negozio online.