Quand faut-il pour effectuer des calculs en front-end?

Mon équipe développe une application financière basée sur le WEB et il y a eu une petite dispute avec un collègue pour savoir où garder les calculs - purement en back-end ou en garder aussi en front-end?

Brève explication: nous utilisons Java (ZK, Spring) pour le front-end et Progress 4gl pour le back-end. Les calculs qui impliquent des mathématiques et des données hardcore de la base de données sont conservés en back-end, donc je ne parle pas d'eux. Je parle de la situation où l'utilisateur entre la valeur X, il est ensuite ajouté à la valeur Y (affichée à l'écran) et le résultat est affiché dans le champ Z. Opérations jQuery-ish pures et simples, je veux dire.

Alors, quelle serait la meilleure pratique ici:

1) Ajouter des valeurs avec JavaScript qui évite d'aller au back-end et au back puis les valider au back-end "on save"?

2) Gardez toute la logique métier au même endroit - apportez donc les valeurs au back-end et faites les calculs là-bas?

3) Faites les calculs dans le front-end; puis envoyer des données à l'arrière-plan, les valider là, faire les calculs à nouveau et que si les résultats sont valides et égaux, les afficher à l'utilisateur?

4) Autre chose?

Remarque: Nous effectuons une validation de base en Java, mais la plupart d'entre elles sont toujours dans le back-end comme toutes les autres logiques métier.

Augmentation des données qui seraient envoyés en recalculant tout dans un back-end ne serait pas un problème (petite taille XML, les serveurs et la bande passante résisteraient l'augmentation du montant des opérations effectuées par les utilisateurs).

Comme toujours, ces décisions impliquent un compromis entre différents objectifs, dont certains sont en conflit les uns avec les autres.

• L'efficacité suggère que vous effectuer des calculs dans le front-end - à la fois parce que comme l'ordinateur de l'utilisateur consomme plus d'énergie et utilise votre serveur moins, et parce que l'utilisateur voit un feedback plus rapide, ce qui améliore l'expérience utilisateur.

• La sécurité exige que toute opération de changement d'état ne puisse pas s'appuyer sur des données vérifiées ou calculées sur l'ordinateur client, car l'ordinateur client peut être sous le contrôle d'un attaquant malveillant. Par conséquent, vous devez valider tout ce qui provient de sources non fiables côté serveur.

• L'efficacité et la maintenabilité de la programmation suggèrent que vous ne devriez pas faire deux fois le même calcul à cause de l'effort inutile.

Superficiellement, cela semble que tout doit être fait côté serveur, mais ce n'est pas toujours le cas. Si vous pouvez facilement conserver le code dupliqué (par exemple en générant automatiquement un validateur javascript à partir de votre validateur Java côté serveur), alors répéter le calcul peut être une bonne solution. Si les données impliquées sont toutes sans importance, par exemple si l'utilisateur ne peut tricher que lui-même et pas vous s'il manipule des valeurs, alors la validation côté serveur n'est pas nécessaire. Si votre temps de réponse est dominée par des goulots d' étranglement complètement différents de sorte qu'un retard aller-retour n'est pas perceptible, alors considérations UX ne sont pas déterminantes, etc. Par conséquent , vous devez considérer la force de chacune de ces pressions est dans votre situation, et décider en conséquence .

Il y a de bonnes raisons de faire des calculs dans le backend

• La logique métier n'appartient pas à la couche de présentation
• La logique métier en JavaScript constitue une menace
• Vous supposez qu'il existe une relation un front-end -> un back-end qui n'est pas toujours vraie , les back-ends doivent être considérés comme capables ou servant plus d'une application frontale, vous ne pouvez donc rien supposer.
• Si les calculs utilisent une grande quantité de données, il ne serait pas efficace de les conserver dans le front-end
• Si les calculs utilisent la base de données, vous ne pourrez pas la répliquer dans le frontal

Ma recommandation

• Faire en sorte que la base de données applique autant de règles métier que possible dans le modèle, y compris les clés étrangères, les clés primaires, les contraintes de vérification et les déclencheurs
• Avoir les exceptions de jet de la couche d'affaires lorsque les règles d'affaires ne sont pas respectées (soit parce que la base de données a renvoyé une erreur ou parce que la couche d'entreprise elle-même validé les données)
• Si et seulement si le temps de réponse est inacceptable, faites des validations ou prétraitements en utilisant Ajax (le travail ne sera pas vraiment fait en JavaScript, il se fera en backend sans avoir à recharger la page)
• Vous pouvez faire une validation simple en JavaScript comme ne pas autoriser une valeur vide, ou des valeurs trop longues ou hors plage (pour cette dernière, vous souhaiterez peut-être générer les plages dans le back-end)