Logica aziendale in JavaScript. Fat client vs thin client

Question

È una buona idea implementare la logica di business sul lato client con JavaScript?

Che tipo di logica dovrebbe essere lì? Logica di convalida? Relativo alla GUI?

Cosa farebbe se la stessa logica volesse essere utilizzata in un'altra applicazione (esposta) implementandola in JavaScript significherebbe che non è possibile riutilizzare tale logica.

D'altra parte avere tutta la logica sul lato server significherebbe più richieste al server.

Cosa ne pensi?

Answer 1

È possibile creare moduli Javascript riutilizzabili in modo che non ci sia una barriera intrinseca alla reimpostazione della logica in diversi sistemi rich. Tuttavia, come è già stato sottolineato, probabilmente si finisce con la duplicazione tra JavaScript e qualsiasi cosa si stia utilizzando sul server (Java, PHP ...) - nel caso della validazione è un compromesso tra il dare un performante esperienza utente e complessità dovute alla duplicazione.

Posso immaginare scenari in cui si sceglie di duplicare più di una semplice convalida. Prendi in considerazione il calcolo di un valore totale dell'ordine: vogliamo davvero fare un viaggio andata e ritorno dal lato server per questo? Ordinamento di un elenco: tendiamo a farlo felicemente in JavaScript, ma l'ordinamento può ottenere funzioni di confronto specializzate e specializzate? Disegnare il confine può essere alquanto complicato, calcolando sconti e imposte sulle vendite?

Alla fine è un giudizio, seguito da un'attenta comprensione delle conseguenze. Se duplichi la logica, puoi ideare una strategia di test che assicuri coerenza? Con i sistemi a basso volume si può essere inclini a favorire più interazioni con il server e meno duplicazioni, ma si possono prendere decisioni diverse per una base di utenti più ampia o più esigente.

Answer 2

È conveniente implementare la logica di convalida in javascript dal punto di vista delle prestazioni, in quanto l'utente non deve attendere le chiamate del server, ma è comunque necessario convalidare tutti i dati inviati al server.

Se non lo fai, finirai con persone malevoli che corrompono il tuo sistema posteriore.

Answer 3

Uno non dovrebbe mai fidarsi del cliente. Pertanto, qualsiasi convalida effettuata sul lato client con JavaScript può solo migliorare la praticità e l'usabilità dell'utente. Devi sempre convalidare i dati in arrivo sul tuo server in un secondo momento per assicurarti che nessuno inietti dati, ecc.

Answer 4

Javascript dovrebbe essere usato per arricchire l'esperienza dell'utente nella GUI ma il tuo sito/webapp dovrebbe funzionare senza di esso.

I parametri inviati al server possono essere modificati dall'utente. Se ti affidi a Javascript per convalidare o creare questi valori, in sostanza chiedi ai tuoi utenti di provare a fare cose cattive. (E lo saranno)

Javascript per la convalida va bene, ridurrà la quantità di richieste al tuo server per gli utenti che usano l'applicazione normalmente. Ma quello cade ancora arricchendo la loro esperienza. È comunque necessario convalidare il lato server per l'1% di l33t h @ x0rs che tenterà di creare problemi.

Answer 5

Un modo per tentare di fare ciò che stai cercando è utilizzare un qualche tipo di accesso al web service/metodo web e fare in modo che il tuo javascript effettui chiamate ajax ai metodi, effettuare la convalida sulla logica di business e quindi inviare un ritorna al front-end.

Ora il front-end sarebbe loquace con il server, ma avresti la possibilità di condividere facilmente la convalida della logica aziendale con altre app dello stesso dominio. Un secondo vantaggio di questo approccio è che tutta la logica aziendale e la convalida si trovano sul server e non sono esposte in modo tale che una persona maliziosa potrebbe facilmente visualizzare o manipolare il codice.

Buona fortuna, e spero che questo aiuti alcuni.

Answer 6

Ho fatto un sacco di lavoro AJAX in questi ultimi anni e il mio prendere su di esso è questo:

• Mettere la logica di business nel client per aumentare più importanti convalide lato server. Ho lavorato per alcune istituzioni finanziarie e hanno sempre avuto una buona sicurezza perché è stato fatto in profondità. Validazioni lato client, convalide lato server, sicurezza framework, ecc ..., ma lo hanno sempre avuto in ogni sezione delle applicazioni. Non hanno mai pensato che nulla fosse sicuro e hanno costruito le loro app intranet come se fossero app internet.
• Un'altra logica di business può essere inserita, ma mantenere l'idea di un thin client in ogni momento. L'altro motivo principale per cui metterei la logica di business nel client è per le prestazioni.

Ad esempio, una volta ho avuto un dropdown più in alto che ha attivato cinque altri controlli sotto di esso nella pagina. Anziché eseguire un intervento sul lato server per ciascuno dei controlli, mi sono reso conto che il controllo più in alto faceva una chiamata e controllava il display dei dati su tutti i controlli successivi in ​​modalità a cascata. Gli altri controlli interagivano tra loro con gli stessi dati, a meno che non fosse stato modificato il menu a discesa più in alto. Così ho creato un manager che memorizzava nella cache/gestiva i dati e la performance era eccellente! La maggior parte delle interazioni utente erano basate su quella selezione iniziale, una specie di regola d'uso 80-20. Il più delle volte hanno appena fatto una selezione e ottenuto ciò che volevano.

• Utilizzare la logica di presentazione nel client. Con questo voglio dire se hai un ordinamento su un menu a discesa che puoi fare in un Widget della GUI tramite una proprietà, quindi con tutti i mezzi farlo. Quando ho lavorato con GWT nel paradigma MVP (Model View Presenter) non hai mai inserito alcuna logica di business nella vista, ma ti è stato permesso di inserire la logica di presentazione lì. Non è la logica del business, ma in armonia con l'altro.

Answer 7

'Coppia (possibilmente opiniated) nota dal 2013:

applicazioni Web non dovrebbero essere sviluppate in modo diverso rispetto a qualsiasi altra applicazione.

Prendere qualsiasi applicazione di livello 2+ (qualsiasi normale modello client-server farebbe); ha senso elaborare le cose sul client o sul server?

Considerazioni sulle prestazioni

Si deve prendere in considerazione la potenza di elaborazione, la latenza di rete, larghezza di banda, memoria e limitate capacità di magazzinaggio. A seconda dell'applicazione, è possibile scegliere diversi compromessi.

Un fat client di solito permetterà di elaborare più sul client e scaricare il server, serializzare payload dei messaggi più efficaci, e ridurre al minimo andata e ritorno, il tutto a costo di potenza di elaborazione, l'efficienza della memoria, e, eventualmente, lo spazio di archiviazione.

Considerazioni sulla sicurezza

Security è transitorio, a prescindere dal modello utilizzato, ciascuna parte (non solo il server) dovranno sempre verificare e, eventualmente, disinfettare i dati che riceve dagli altri in una certa misura. Per molte applicazioni Web, ciò significa convalidare entità con logica aziendale, ma non sempre. Questo dipende da cosa sono i dati e da chi ha autorità su di esso (e non è sempre il server).

Poiché il browser Web già verifica molte informazioni, le considerazioni sul lato client sono meno, ma non dovrebbero essere dimenticate (specialmente in un client che esegue XHR o utilizza WebSockets, dove c'è meno hand-holding).

A volte, ciò significa che effettivamente sia il server che il client convalideranno gli stessi dati. Questo va bene. Se sviluppi software su entrambi i lati, puoi estrarre il codice di convalida su un modulo utilizzato sia dal client sia dal server (come tutti questi moduli "comuni" nei pacchetti software tradizionali). Poiché la scelta della lingua è limitata sul lato client in un ambiente Web, potrebbe essere necessario scendere a un compromesso. Detto questo, è possibile eseguire Javascript sul server, o compilare molte lingue in Javascript usando cose come Emscripten (vedi anche amd.js), o persino eseguire codice nativo in un futuro incerto usando cose come NaCl/PNaCl.

Conclusione

trovo che aiuta a pensare a client di applicazioni Web come 'immediatamente installato', 'zero conf' e clienti 'continuamente aggiornata-'. Non usiamo questa terminologia per il web perché queste proprietà erano sempre intrinseche al classico software basato sul web, ma non erano per il classico software nativo. Allo stesso modo, non utilizziamo termini come "Applicazioni a pagina singola" quando sviluppiamo software nativo perché non è mai stato necessario riavviare l'intera applicazione ogni volta che era necessario passare a una nuova schermata con un software classico.

Abbracciare la convergenza e mantenere una mente aperta; persone provenienti da diverse comunità impareranno molto l'una dall'altra nei prossimi anni.

Answer 8

La logica di business dovrebbe essere il più indipendente possibile dal consumatore. Se progettato correttamente, il codice client e server dovrebbe essere in grado di utilizzare la logica aziendale in modo riusabile (presupponendo che sia client che server possano utilizzare javascript).

Il consumo della logica aziendale da un client (browser, ecc.) Può impedire inutili accessi al server, presupponendo che un utente malintenzionato non elimini l'interfaccia utente per raggiungere gli endpoint. Questa stessa logica aziendale può quindi essere utilizzata dal tuo server come ultima linea di difesa.

Inoltre, se progettato correttamente, è possibile estendere la logica aziendale per includere una logica del flusso di lavoro più complessa che deve essere eseguita correttamente, eseguita all'interno di un contesto di transazione, ecc .; generalmente cose che sarebbero difficili da facilitare tramite il cliente.

Ci sono molti design patterns su cui potete fare affidamento per aiutarvi a progettare la logica di business riutilizzabile.

Sono disponibili anche micro-framework, come peasy-js, che consentono di creare rapidamente una logica aziendale facilmente riutilizzabile, estensibile, gestibile e verificabile.