Pro / contro tra enfasi sull'elaborazione lato client o lato server

Perché dovrei voler scrivere un'app Web con molte elaborazioni sul lato server?

Per me, scrivere il programma sul lato client è un enorme vantaggio perché toglie il maggior carico possibile al server perché deve solo inviare dati al client con un'elaborazione minima.

Vedo molto poco nello scrivere app web oltre a scriverlo sul lato server e trattare il lato client solo come una vista . Perché dovrei mai voler fare questo? L'unico vantaggio che vedo è che posso scrivere in qualsiasi lingua io voglia ( http://www.paulgraham.com/avg.html ).

Ci sono due problemi principali.

1. Il primo è semplice: di solito non sai che tipo di risorse sono disponibili sul lato client. Se sono necessari 1,5 GB per elaborare qualcosa, puoi davvero spingerlo su un browser client sconosciuto (IE, Safari, Opera, Firefox, ecc.) Su una piattaforma client sconosciuta? Il cliente apprezzerà il suo sistema dogging quando lo travolgerai?

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

Innanzitutto è la sicurezza . Invia tutta la tua logica al client ed è un gioco equo per hacker e exploit.

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

Lato client contro lato server

L'elaborazione lato client è in linea con i più popolari standard REST e MVC rispetto agli approcci basati sulla pagina e SOAP. L'emergere di queste tendenze e l'attenzione su AJAX e Html-RIA, lo scripting lato client è in aumento e più popolare; tuttavia, a causa di problemi di sicurezza e capacità del client, gli script lato client hanno una nicchia particolare e non devono essere utilizzati per tutto.

considerazioni:

Mobile

Se un ampio segmento del tuo pubblico di destinazione sarà rappresentato da utenti mobili, l'elaborazione pesante dovrebbe essere lasciata al server.

Coerenza tra browser

Gli standard Web hanno fatto molta strada e questo potrebbe non essere tanto un problema, ma ogni sviluppatore web sa che IE 6,7 e 8 e talvolta Safari può agire in modo divertente sul lato client - alcune funzioni potrebbero non essere eseguite a causa di restrizioni di sicurezza e altre 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 (senza 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 dei dati che si desidera proteggere deve essere eseguita sul server. Tutti i dati che vengono elaborati sul lato client sono assolutamente aperti alla manipolazione. Ad esempio, se si dispone di una funzione javascript che elabora alcune informazioni che vengono poi registrate nel sistema, sarebbe molto semplice manipolare il risultato appena prima che venga registrato anche se si dispone di una sicurezza back-end esemplare

UI / UX

L'elaborazione sul lato client viene lasciata per l'interfaccia utente e la creazione di applicazioni Internet avanzate (RIA). Viene utilizzato per creare animazioni, effetti, interazioni dell'utente, nonché per caricare dinamicamente il contenuto tramite chiamate AJAX anziché ricaricare un'intera pagina.

Principalmente sarà una duplicazione di sforzi. Molto probabilmente tutti i dati dal client saranno nuovamente controllati ed elaborati 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 convalidarli ed elaborarli. Quindi ha senso metterlo lì.

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

Hai ragione, perché inviare i dati al server se non sono completi o errati. È facile controllare i campi obbligatori o i telefoni o gli indirizzi e-mail correttamente formattati. Non mi è mai piaciuto inviare un modulo e quindi aspettare 5 secondi per dirmi che ho dimenticato di entrare in un campo. Quel tipo di elaborazione, sicuramente, lo fa sul client e si assicura che sia corretto e che usi la logica lato client per una risposta rapida all'utente. Come hai sottolineato, un effetto collaterale bonus sarebbe che il tuo server dovrebbe gestire meno richieste di dati errati. MA, anche il server deve ancora convalidare, quindi si esegue il duping della logica. Ma i tuoi utenti saranno più felici.

C'è una linea sottile qui. Logica di convalida semplice OK, logica di business principale 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 / Java Applets / Silverlight. Uscirò da un arto e aggiungerò applicazioni mobili native che comunicano con un server back-end. Fondamentalmente il ruolo di questo livello è quello di fornire un'interfaccia per l'utente del sistema per interagire con esso.

   b) Logica aziendale - PHP / RoR / Java in cui i dati dal client vengono raccolti, elaborati e archiviati e in cui le richieste dei client per i dati vengono elaborate e rispedite al client

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

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

   a) Lato client: assicurarsi 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. Parte della convalida effettuata sul front-end viene ripetuta qui, a causa del fatto che potrebbero esserci client diversi, ad esempio browser che JavaScript può essere disabilitato. Ad esempio, può anche accettare dati da origini diverse tramite API, quindi è necessario convalidarli tutti.

   c) Archivio dati back-end: i vincoli assicurano che i dati siano ben formati per l'archiviazione e il successivo recupero.

Quindi, dove concentri i tuoi sforzi di convalida, usa ogni livello per eseguire la convalida più adatta e lascia regole più complesse per il livello che può gestirlo

Una parte importante consiste nel mantenere il trattamento vicino ai tuoi dati. Se hai centinaia di GB di dati, ovviamente non li spedirai a un client. Con l'aumentare della velocità di accesso ai dati questo sta diventando un problema minore, ma se hai un sito Big Data, vuoi ancora fare il maggior filtraggio e restringimento sul server prima di spedirlo.

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

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

Questo significa anche che un visitatore può aggiungere una pagina specifica ai segnalibri. L'hai provato su Facebook?

Queste cose possono essere risolte, ma di solito sono integrate in applicazioni che fanno molto sul server (RAILS, WordPress ecc.), Mentre se stai costruendo in REACT, dovrai saltare attraverso i cerchi.

Il motivo è la stabilità .

Sul lato server, posso scegliere componenti stabili. Di solito questo significa che scelgo Java e un sacco di librerie accuratamente selezionate come FreeMarker. Inutile dire che ogni libreria a parte le librerie standard di Java è trattata come usa e getta, quindi accedo alle librerie esterne tramite un wrapper fatto da sé. Ciò significa che posso passare facilmente da una libreria all'altra se si presenta la necessità.

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. Inoltre, ogni server che ho esegue la stessa versione di Java. Non tutti i client eseguono la stessa implementazione JavaScript.

Dal lato client, non posso scegliere componenti stabili. I produttori di browser mi costringeranno a scegliere JavaScript, una lingua che non mi piace particolarmente, ma che sono costretto a usare. (E non parlarmi delle lingue compilate 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 di browser supportate.

La mia soluzione? Eseguo il più possibile l'elaborazione sul lato server e il lato client è solo un wrapper leggero che invia i dati al server e riceve i dati dal server sotto forma di frammenti JSON e HTML. Evita XML; usa invece JSON.

Non faccio il modello lato client; Rendo il contenuto sul server in un frammento HTML che poi assegno usando il.innerHTML attributo 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).

Lo svantaggio è 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 smartphone. Gli smartphone hanno una durata limitata della batteria, quindi se stai eseguendo un calcolo pesante, è meglio scaricarlo sui tuoi server. Tuttavia, le cose semplici possono essere più efficienti dal punto di vista energetico se eseguite sul lato client perché è possibile evitare l'accesso alla radio. Ma l'argomento principale, la stabilità, può significare che in realtà può avere senso scaricare anche un semplice calcolo sul server.

Come addendum, come già osservato in alcune risposte, guadagni anche sicurezza . Se la logica dell'applicazione è interamente sul lato client, qualcuno può ad esempio stabilire un prezzo per qualsiasi cosa acquisterà dal tuo negozio online.