Quando é apropriado fazer cálculos no front-end?

Minha equipe está desenvolvendo um aplicativo financeiro baseado na WEB e houve uma discussão com um colega sobre como manter os cálculos - puramente no back-end ou também no front-end?

Breve explicação: Estamos usando Java (ZK, Spring) para front-end e Progress 4gl para back-end. Os cálculos que envolvem alguns dados e matemática hardcore do banco de dados são mantidos no back-end, então não estou falando sobre eles. Eu estou falando sobre a situação em que o usuário digita o valor X, é então adicionado ao valor Y (mostrado na tela) e o resultado é mostrado no campo Z. Operações puras e simples com jQuery-ish, quero dizer.

Então, qual seria a melhor prática aqui:

1) Adicione valores com JavaScript que evite ir para o back-end e back-end e depois os valide no back-end "ao salvar"?

2) Mantenha toda a lógica de negócios no mesmo local - portanto, traga os valores para o back-end e faça os cálculos lá?

3) Faça os cálculos no front-end; em seguida, envie os dados para o back-end, valide-os lá, faça os cálculos novamente e somente se os resultados forem válidos e iguais, os exiba para o usuário?

4) Algo mais?

Nota: Fazemos alguma validação básica em Java, mas a maioria ainda está no back-end, como todas as outras lógicas de negócios.

O aumento dos dados que seriam enviados recalculando tudo em um back-end não seria um problema (tamanho XML pequeno; servidores e largura de banda suportariam o aumento da quantidade de operações realizadas pelos usuários).

programming-practices web-applications front-end

— IgnasK
fonte

Regra geral: quando usa uma linguagem fortemente tipada.

— Den

O teste de unidade automatizado será mais fácil se toda a lógica estiver no back-end. Se 90% tiver que ser o back-end e 10% puderem estar no back-end, eu colocaria 100% no back-end.

— Ian

@Ian: você também pode fazer testes de unidade automatizados para códigos de front-end se estruturar bem seu código.

— Lie Ryan

Regra prática: sempre que você puder se safar.

— Goldilocks

Regra básica: suponha que o usuário esteja invadindo seu JavaScript e fazendo seus próprios cálculos. Do ponto de vista da segurança, os cálculos devem ser feitos no back-end. Você também pode fazer as duas coisas: o JS pode fornecer um feedback mais rápido, mas os cálculos que realmente contam são feitos no servidor.

Respostas:

Como sempre, essas decisões envolvem uma troca entre objetivos diferentes, alguns dos quais conflitam entre si.

A eficiência sugere que você faça cálculos no front-end - tanto porque o computador do usuário consome mais energia e o servidor quanto menos, e porque o usuário vê um feedback mais rápido, o que melhora a experiência do usuário.
A segurança exige que qualquer operação de alteração de estado não possa confiar nos dados que estão sendo verificados ou computados no computador cliente, porque o computador cliente pode estar sob o controle de um invasor mal-intencionado. Portanto, você deve validar qualquer coisa proveniente de fontes não confiáveis do lado do servidor.
A eficiência e a manutenção da programação sugerem que você não deve fazer o mesmo cálculo duas vezes por causa do esforço desperdiçado.

Superficialmente, isso soa como se tudo tivesse que ser feito no lado do servidor, mas nem sempre é esse o caso. Se você pode manter facilmente o código duplicado (por exemplo, gerando automaticamente um validador javascript a partir do seu validador Java do lado do servidor), a repetição da computação pode ser uma boa solução. Se todos os dados envolvidos não são importantes, por exemplo, se o usuário puder enganar apenas a si próprio e não a você, se manipular valores, a validação no servidor não será necessária. Se o seu tempo de resposta for dominado por gargalos completamente diferentes, de modo que um atraso de ida e volta não seja perceptível, as considerações de UX não serão decisivas etc. Portanto, você deve considerar a força de cada uma dessas pressões na sua situação e decidir de acordo. .

— Kilian Foth
fonte

Eu gostaria de acrescentar que isso

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

não está correto porque [1] a validação no front-end pode fornecer um feedback rápido ao usuário para fazer as correções, se necessário. [2] A validação no back-end não é tão responsiva e, portanto, não fornece ao usuário a melhor oportunidade para fazer correções. O usuário precisaria esperar e refazer mais trabalho. Então, acho que as duas validações não são exatamente iguais.

— InformedA

Isso não é o que eu queria passar - manutenção faz implica "não repetir-se", e de acordo com este princípio a repetição é certamente ruim. Se não houver outras considerações, você não deve fazê-lo. O fato de que é, no entanto, muitas vezes, uma boa idéia é porque não são outras considerações que contradizem este princípio, ou seja, melhor usabilidade através de retorno rápido.

— Kilian Foth

@randomA Você está aplicando mal esse princípio, se quer dizer que algo que precisa ser validado no servidor deve ser calculado apenas no servidor, porque se o "valor validado pelo servidor" (ou qualquer coisa dependente dele) retornado ao cliente for em algum momento enviado de volta ao servidor, você precisará validá-lo novamente de qualquer maneira - inútil. Ou então você precisa de algum sistema de referências seguras, que pode ser ainda mais ineficiente. Eu diria que se você pode fazer um cálculo no cliente, faça-o no cliente , mas também nunca confie no que o cliente diz .

— precisa

@goldilocks O que você disse em negrito também é o que eu concordo, você precisa validar tudo no back-end. O que quero dizer é que: a validação no front-end é mais responsiva, portanto não é a mesma coisa que a validação no back-end.

— InformedA

Existem fortes razões para fazer cálculos no back-end

A lógica de negócios não pertence à camada de apresentação
A lógica de negócios em JavaScript representa uma ameaça
Você supõe que há um relacionamento de front-end -> de um back-end que nem sempre é verdadeiro ; os back-ends devem ser considerados capazes ou atendendo a mais de um aplicativo de front-end; portanto, você não pode assumir nada.
Se os cálculos usarem uma grande quantidade de dados, não seria eficiente mantê-los no front-end
Se os cálculos usarem o banco de dados, você não poderá replicá-lo no front end

Minha recomendação

Faça com que o banco de dados aplique o máximo possível de regras de negócios no modelo, incluindo chaves estrangeiras, chaves primárias, restrições de verificação e gatilhos
A camada de negócios lança exceções quando as regras de negócios não são atendidas (porque o banco de dados retornou um erro ou porque a própria camada de negócios validou os dados)
Se e somente se o tempo de resposta for inaceitável, faça validações ou pré-processamento usando o Ajax (o trabalho não será realmente feito em JavaScript, será feito no back-end sem a necessidade de recarregar a página)
Você pode fazer uma validação simples em JavaScript, como não permitir um valor vazio, ou valores muito longos ou fora do intervalo (para o último, você pode querer gerar os intervalos no back-end)

— Tulains Córdova
fonte

O problema de fazer com que o banco de dados aplique regras de negócios está relatando violações para o front-end! Se o front-end aplicar regras de negócios, ele poderá enviar rapidamente mensagens de erro significativas para o usuário. Se o back-end fizer isso, haverá muito tráfego de mão dupla entre o front e o back-end, pois os erros são relatados um de cada vez.

— James Anderson

@ JamesAnderson Não existe mais "o front-end". Pode haver vários front-ends para o mesmo banco de dados ou vários bancos de dados para vários front-ends. Além disso, ter o back-end impor regras de negócios não significa que o front-end é proibido. Eu destaquei isso no segundo ponto.

— Tulains Córdova