Quando è appropriato fare calcoli in front-end?

Il mio team sta sviluppando un'applicazione finanziaria basata sul WEB e c'era un po 'di discussione con un collega su dove mantenere i calcoli - puramente nel back-end o anche nel front-end?

Breve spiegazione: stiamo usando Java (ZK, Spring) per il front-end e Progress 4gl per il back-end. I calcoli che coinvolgono alcuni dati matematici e dati dal database sono conservati nel back-end, quindi non ne sto parlando. Sto parlando della situazione in cui l'utente immette il valore X, quindi viene aggiunto al valore Y (mostrato nella schermata) e il risultato viene mostrato nel campo Z. Operazioni jQuery pure e semplici, intendo.

Quindi quale sarebbe la migliore pratica qui:

1) Aggiungere valori con JavaScript che salvi dall'andare al back-end e viceversa e quindi convalidarli nel back-end "al salvataggio"?

2) Mantenere tutte le logiche aziendali nello stesso posto - quindi portare i valori al back-end e fare i calcoli lì?

3) Eseguire i calcoli nel front-end; quindi inviare i dati al back-end, convalidarli lì, eseguire nuovamente i calcoli e solo se i risultati sono validi e uguali, mostrarli all'utente?

4) Qualcos'altro?

Nota: eseguiamo alcune convalide di base in Java ma la maggior parte è ancora nel back-end come tutte le altre logiche aziendali.

L'aumento dei dati che verrebbero inviati ricalcolando tutto in un back-end non sarebbe un problema (dimensioni XML ridotte; server e larghezza di banda resisterebbero alla maggiore quantità di operazioni eseguite dagli utenti).

programming-practices web-applications front-end

— IgnasK
fonte

Regola empirica: quando utilizza un linguaggio fortemente tipizzato.

— Den

Il test automatico delle unità sarà più semplice se tutta la logica è nel back-end. Se il 90% deve essere il back-end e il 10% può essere nel back-end, quindi inserirò il 100% nel back-end.

— Ian,

@Ian: puoi eseguire test di unità automatizzati anche per i codici front-end se strutturi bene il tuo codice.

— Lie Ryan

Regola empirica: ogni volta che riesci a cavartela.

— Riccioli d'oro

Regola empirica: supponi che l'utente stia hackerando il tuo JavaScript e stia facendo i propri calcoli. Dal punto di vista della sicurezza, i calcoli devono essere eseguiti sul back-end. Puoi anche fare entrambe le cose: JS può fornire un feedback più rapido, ma i calcoli che contano effettivamente vengono eseguiti sul server.

Risposte:

Come sempre, tali decisioni comportano un compromesso tra obiettivi diversi, alcuni dei quali in conflitto tra loro.

L'efficienza suggerirebbe di eseguire calcoli nel front-end, sia perché in questo modo il computer dell'utente consuma più energia e il server consuma di meno, sia perché l'utente vede un feedback più rapido, il che migliora l'esperienza dell'utente.
La sicurezza richiede che le operazioni che cambiano lo stato non possano basarsi sul controllo o il calcolo dei dati nel computer client, poiché il computer client potrebbe essere sotto il controllo di un utente malintenzionato. Pertanto, è necessario convalidare tutto ciò che proviene da fonti non attendibili lato server.
L'efficienza di programmazione e la manutenibilità suggeriscono che non dovresti fare lo stesso calcolo due volte a causa dello sforzo sprecato.

Superficialmente sembra che tutto debba essere fatto sul lato server, ma non è sempre così. Se riesci a mantenere facilmente il codice duplicato (ad esempio generando automaticamente un validatore javascript dal tuo validatore Java sul lato server), ripetere il calcolo può essere una buona soluzione. Se i dati in questione sono tutti poco importanti, ad esempio se l'utente può imbrogliare solo se stesso e non te se manipola i valori, non è necessaria la convalida sul lato server. Se il tuo tempo di risposta è dominato da strozzature completamente diverse in modo che un ritardo di andata e ritorno non sia percepibile, allora le considerazioni sulla UX non sono decisive, ecc. Quindi devi considerare quanto ciascuna di queste pressioni è forte nella tua situazione e decidere di conseguenza .

— Kilian Foth
fonte

Vorrei aggiungere che

Programming efficiency and maintainability suggests that you shouldn't do the same computation twice because of the wasted effort.

non è corretto perché [1] La convalida in front-end può fornire un rapido feedback all'utente per apportare correzioni se necessario. [2] La convalida nel back-end non è altrettanto reattiva e quindi non offre all'utente la migliore opportunità di apportare correzioni. L'utente dovrebbe attendere e ripetere più lavoro. Quindi penso che le due validazioni non siano esattamente le stesse.

— Informato il

Non è quello che volevo trasmettere - manutenibilità fa implicare "non ripetere te stesso", e in base a questo principio la ripetizione è certamente male. Se non ci fossero altre considerazioni, non dovresti farlo. Il fatto che spesso sia una buona idea è perché ci sono altre considerazioni che contraddicono questo principio, vale a dire una migliore usabilità attraverso una rapida inversione di tendenza.

— Kilian Foth,

@randomA Stai applicando erroneamente quel principio, se intendi che qualcosa che deve essere validato sul server dovrebbe essere calcolato solo sul server, perché se il "valore validato del server" (o qualsiasi cosa dipendente da esso) restituito al client è allora a un certo punto rispedito al server, è necessario convalidarlo di nuovo comunque - inutile. Oppure hai bisogno di un sistema di riferimenti sicuri, che potrebbe essere ancora più inefficiente. Direi che se puoi fare un calcolo sul client, farlo sul client , ma anche non fidarti di ciò che ti dice il cliente .

— Riccioli d'oro

@goldilocks Quello che hai detto in grassetto è anche quello che sono d'accordo, devi convalidare tutto sul back-end. Il mio punto era che: la validazione sul front-end è più reattiva, quindi non del tutto uguale alla validazione sul back-end.

— Informato il

Ci sono forti ragioni per fare calcoli nel backend

La logica aziendale non appartiene al livello di presentazione
La logica aziendale in JavaScript rappresenta una minaccia
Supponi che esista una relazione one-front-end-> one-back-end che non è sempre vera , i back-end dovrebbero essere considerati in grado di servire o servire più di un'applicazione front-end, quindi non puoi assumere nulla.
Se i calcoli utilizzano una grande quantità di dati, non sarebbe efficiente tenerli nel front-end
Se i calcoli utilizzano il database, non sarà possibile replicarlo nel front-end

La mia raccomandazione

Chiedi al database di applicare tutte le regole aziendali possibili nel modello, incluse chiavi esterne, chiavi primarie, vincoli di controllo e trigger
Chiedere al livello aziendale di generare eccezioni quando le regole aziendali non vengono rispettate (o perché il database ha restituito un errore o perché il livello aziendale stesso ha convalidato i dati)
Se e solo se il tempo di risposta è inaccettabile, esegui convalide o preelaborazioni utilizzando Ajax (il lavoro non verrà realmente eseguito in JavaScript, verrà eseguito nel back-end senza dover ricaricare la pagina)
Puoi eseguire una semplice convalida in JavaScript come non consentire un valore vuoto o valori troppo lunghi o fuori intervallo (per quest'ultimo potresti voler generare gli intervalli nel back-end)

— Tulains Córdova
fonte

Il problema di far applicare le regole aziendali al database è la segnalazione di violazioni al front-end! Se il front-end applica regole aziendali, può rapidamente inviare all'utente messaggi di errore significativi. Se il back-end lo fa, c'è un grosso traffico bidirezionale tra front-end e back-end poiché gli errori vengono segnalati uno alla volta.

— James Anderson,

@JamesAnderson Non c'è più "il front-end". Possono esserci più front-end nello stesso database o diversi database in più front-end. Inoltre, avere il back-end per far rispettare le regole aziendali non significa che al front-end è proibito farlo. L'ho sottolineato nel secondo punto.

— Tulains Córdova,