Quand est-il approprié de faire des calculs en front-end?
Mon équipe est en train de développer 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 calculs 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. jQuery pure et simple -des opérations, je veux dire.
Quelle serait donc 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 au back-end, les valider là-bas, refaire les calculs et seulement si les résultats sont valides et égaux, les afficher à l'utilisateur?
4) Autre chose?
Remarque: Nous effectuons une validation de base dans Java mais la majeure partie est toujours dans le back-end comme toutes les autres logiques métier.
L'augmentation des données qui seraient envoyées en recalculant tout dans un back-end ne serait pas un problème (petite taille XML; les serveurs et la bande passante résisteraient à la quantité accrue d'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érerait que vous effectuiez des calculs dans le front-end - à la fois parce que l'ordinateur de l'utilisateur utilise plus d'énergie et votre serveur utilise moins, et parce que l'utilisateur voit des commentaires plus rapides, ce qui améliore l'expérience utilisateur.
La sécurité exige que toute opération de changement d'état ne peut 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 depuis votre serveur Java), alors répéter le calcul peut être une bonne solution. Si les données impliquées sont tous 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é par des goulots d'étranglement complètement différents de sorte qu'un délai d'aller-retour n'est pas perceptible, alors les considérations UX ne sont pas décisives, etc. Par conséquent, vous devez considérer la force de chacune de ces pressions 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 front-end, 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
- Demander à la couche métier de lever des exceptions lorsque les règles métier ne sont pas respectées (soit parce que la base de données a renvoyé une erreur, soit parce que la couche métier elle-même a validé les données)
- Si et seulement si le temps de réponse est inacceptable, faites des validations ou un prétraitement 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)