Wann ist es angebracht, Berechnungen im Frontend durchzuführen?

Mein Team entwickelt eine WEB-basierte Finanzanwendung und es gab ein paar Auseinandersetzungen mit einem Kollegen, wo die Berechnungen aufbewahrt werden sollten - rein im Back-End oder auch im Front-End?

Kurze Erklärung: Wir verwenden Java (ZK, Spring) für das Front-End und Progress 4gl für das Back-End. Berechnungen, die einige Hardcore-Mathematik- und -Daten aus der Datenbank beinhalten, werden im Back-End aufbewahrt, sodass ich nicht über sie spreche. Ich spreche von der Situation, in der der Benutzer den Wert X eingibt, dieser dann zum Wert Y addiert (auf dem Bildschirm angezeigt) und das Ergebnis im Feld Z angezeigt wird. Reine und einfache jQuery-ish-Operationen, meine ich.

Was wäre hier die beste Vorgehensweise:

1) Fügen Sie mit JavaScript Werte hinzu, die vom Wechseln zum Back-End und zurück gespeichert werden, und validieren Sie sie dann am Back-End "beim Speichern"?

2) Bewahren Sie die gesamte Geschäftslogik an derselben Stelle auf. Stellen Sie daher die Werte in das Back-End und führen Sie die Berechnungen dort durch.

3) Führen Sie die Berechnungen im Frontend durch; Daten dann an das Backend senden, dort validieren, die Berechnungen erneut durchführen und dem Benutzer nur dann anzeigen, wenn die Ergebnisse gültig und gleich sind?

4) Noch etwas?

Hinweis: Wir führen einige grundlegende Überprüfungen in Java durch, die meisten befinden sich jedoch wie alle anderen Geschäftslogiken im Back-End.

Die Zunahme der Daten, die durch Neuberechnung aller Daten in einem Back-End gesendet würden, wäre kein Problem (geringe XML-Größe; Server und Bandbreite würden dem erhöhten Arbeitsaufwand der Benutzer standhalten).

Wie immer beinhalten solche Entscheidungen einen Kompromiss zwischen verschiedenen Zielen, von denen einige miteinander in Konflikt stehen.

• Die Effizienz lässt darauf schließen, dass Sie Berechnungen im Front-End durchführen - sowohl, weil der Computer des Benutzers mehr Strom verbraucht und Ihr Server weniger, als auch, weil der Benutzer ein schnelleres Feedback sieht, was die Benutzererfahrung verbessert.

• Die Sicherheit erfordert, dass Vorgänge, bei denen sich der Status ändert, nicht darauf beruhen können, dass Daten auf dem Clientcomputer überprüft oder berechnet werden, da der Clientcomputer möglicherweise von einem böswilligen Angreifer kontrolliert wird. Daher Sie müssen etwas validieren , die von nicht vertrauenswürdigen Quellen - Server-Seite kommt.

• Die Effizienz und Wartbarkeit der Programmierung legt nahe, dass Sie aufgrund des verschwendeten Aufwands nicht zweimal dieselbe Berechnung durchführen sollten.

Oberflächlich klingt dies so, als ob alles serverseitig erledigt werden muss, aber das ist nicht immer der Fall. Wenn Sie den duplizierten Code problemlos verwalten können (z. B. indem Sie einen JavaScript-Validator automatisch aus Ihrem serverseitigen Java-Validator generieren), ist es eine gute Lösung, die Berechnung zu wiederholen. Wenn alle betroffenen Daten unwichtig sind, z. B. wenn der Benutzer nur sich selbst betrügen kann und Sie nicht, wenn er Werte manipuliert, ist keine serverseitige Validierung erforderlich. Wenn Ihre Reaktionszeit von völlig verschiedenen Engpässe dominiert wird , so dass eine Umlaufverzögerung nicht wahrnehmbar ist, dann sind UX Überlegungen nicht entscheidend, usw. Deshalb müssen Sie überlegen , wie stark jeder dieser Druck in Ihrer Situation ist, und entsprechend entscheiden .

Es gibt gute Gründe, Berechnungen im Backend durchzuführen

• Geschäftslogik gehört nicht in die Präsentationsebene
• Die Geschäftslogik in JavaScript ist eine Bedrohung
• Sie gehen davon aus, dass es eine One-Front-End-> One-Back-End-Beziehung gibt, die nicht immer zutrifft . Bei Back-Ends sollte davon ausgegangen werden, dass sie in der Lage sind oder mehr als eine Front-End-Anwendung bedienen. Sie können also nichts davon annehmen.
• Wenn Berechnungen eine große Datenmenge verwenden, wäre es nicht effizient, sie im Front-End zu speichern
• Wenn die Datenbank für Berechnungen verwendet wird, können Sie sie im Front-End nicht replizieren

Meine Empfehlung

• Lassen Sie die Datenbank so viele Geschäftsregeln wie möglich im Modell durchsetzen, einschließlich Fremdschlüssel, Primärschlüssel, Prüfbedingungen und Trigger
• Die Business-Schicht soll Ausnahmen auslösen, wenn Geschäftsregeln nicht erfüllt sind (entweder weil die Datenbank einen Fehler zurückgegeben hat oder weil die Business-Schicht selbst die Daten validiert hat).
• Wenn und nur wenn die Antwortzeit nicht akzeptabel ist, führen Sie Überprüfungen oder Vorverarbeitungen mit Ajax durch (die Arbeit wird nicht wirklich in JavaScript ausgeführt, sondern im Backend, ohne dass die Seite neu geladen werden muss).
• Sie können eine einfache Validierung in JavaScript durchführen, indem Sie beispielsweise einen leeren Wert oder Werte, die zu lang sind oder außerhalb des Bereichs liegen, nicht zulassen (für letzteren möchten Sie möglicherweise die Bereiche im Back-End generieren).