フロントエンドで計算を行うのが適切なのはいつですか？

私のチームはWEBベースの財務アプリケーションを開発していますが、同僚と計算をどこで行うべきかという議論が少しありました。純粋にバックエンドで行うのか、それともフロントエンドで行うのですか？

簡単な説明：フロントエンドにはJava（ZK、Spring）を使用し、バックエンドにはProgress 4glを使用しています。筋金入りの数学とデータベースからのデータを含む計算はバックエンドに保持されるため、私はそれらについて話していません。ユーザーが値Xを入力し、値Yに追加され（画面に表示）、結果がフィールドZに表示される状況について話しています。純粋で単純なjQueryのような操作、つまり。

ここで、ベストプラクティスは次のとおりです。

1）JavaScriptを使用して値を追加し、バックエンドに行ったり戻ったりするのを防ぎ、バックエンドで「保存時」にそれらを検証しますか？

2）すべてのビジネスロジックを同じ場所に保持します。したがって、値をバックエンドにもたらし、そこで計算を行いますか？

3）フロントエンドで計算を行います。次に、データをバックエンドに送信し、そこでデータを検証し、計算を再実行します。結果が有効で等しい場合にのみ、ユーザーに表示しますか？

4）他に何か？

注：Javaでいくつかの基本的な検証を行いますが、ほとんどは他のすべてのビジネスロジックと同様にバックエンドにあります。

バックエンドのすべてを再計算することで送信されるデータの増加は問題になりません（XMLサイズが小さい。サーバーと帯域幅はユーザーの操作量の増加に耐えます）。

programming-practices web-applications front-end

— イグナスK
ソース

経験則：厳密に型指定された言語を使用する場合。

— デン14

すべてのロジックがバックエンドにある場合、自動化された単体テストは簡単になります。90％をバックエンドにする必要があり、10％をバックエンドに含めることができる場合、100％をバックエンドに配置します。

— イアン

@Ian：コードを適切に構成すれば、フロントエンドコードの自動ユニットテストも実行できます。

— ライライアン14

経験則：あなたがそれで逃げることができるときはいつでも。

— goldilocks 14

経験則：ユーザーがJavaScriptをハッキングし、独自の計算を行っていると仮定します。セキュリティの観点から、計算はバックエンドで実行する必要があります。両方を行うこともできます。JSはより迅速なフィードバックを提供できますが、実際にカウントされる計算はサーバーで実行されます。

回答:

いつものように、そのような決定は異なる目標間のトレードオフを伴い、そのいくつかは互いに矛盾します。

効率性は、フロントエンドで計算を実行することを示唆します。これは、ユーザーのコンピューターがより多くの電力を使用し、サーバーがより少ない電力を使用するためと、ユーザーがより高速なフィードバックを見るため、ユーザーエクスペリエンスが向上するためです。
セキュリティは、クライアントコンピューターが悪意のある攻撃者の制御下にある可能性があるため、状態を変更する操作がクライアントコンピューターでチェックまたは計算されるデータに依存できないことを要求します。したがって、サーバー側の信頼できないソースから送信されたものはすべて検証する必要があります。
プログラミングの効率と保守性は、無駄な努力のために同じ計算を2回行うべきではないことを示唆しています。

表面的には、すべてをサーバー側で行う必要があるかのように聞こえますが、常にそうであるとは限りません。複製されたコードを簡単に保守できる場合（たとえば、サーバー側のJavaバリデーターからjavascriptバリデーターを自動生成することにより）、計算を繰り返すことは良い解決策になります。関係するデータがすべて重要でない場合、たとえば、ユーザーが自分自身だけをチートでき、値を操作する場合は自分ではカンニングできない場合、サーバー側の検証は必要ありません。ラウンドトリップ遅延が知覚されないように応答時間が完全に異なるボトルネックに支配されている場合、UXの考慮事項は決定的ではありません。したがって、これらの各圧力が状況にどれだけ強いかを考慮し、それに応じて決定する必要があります。

— キリアン・フォス
ソース

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

[1]フロントエンドでの検証により、必要に応じて修正を行うためにユーザーに迅速なフィードバックを提供できるため、これは正しくないことを追加します。[2]バックエンドでの検証は応答性が低いため、ユーザーに修正を加える最適な機会を提供しません。ユーザーは待機して、さらに作業をやり直す必要があります。したがって、2つの検証はまったく同じではないと思います。

— 情報14

それは私がやりたかったことではありません-保守性は「自分自身を繰り返さない」ことを意味し、この原則によれば、繰り返しは確かに悪いです。他に考慮事項がない場合は、実行しないでください。そこにいるので、それは多くの場合、それにもかかわらず、良いアイデアだという事実がありますつまり、迅速なターンアラウンドによる優れたユーザビリティこの原則に反するその他の考慮事項は、。

— キリアンフォス14

@randomAサーバーで検証する必要があるものをサーバーでのみ計算する必要がある場合、クライアントに返される「サーバー検証値」（またはそれに依存するもの）はサーバーに送り返されたある時点で、とにかく再度検証する必要があります-役に立たない。または、安全な参照のシステムが必要になりますが、これはさらに効率が悪い場合があります。私が言うと思いますが、クライアント上で計算を行うことができれば、クライアント上でそれを行うだけでなく、クライアントがあなたに伝え何を信用しません。

— ゴルディロックス

@goldilocksあなたが太字で言ったことは、私も同意します。バックエンドですべてを検証する必要があります。私のポイントは、フロントエンドでの検証の応答性が高いため、バックエンドでの検証とまったく同じではないということです。

— 情報14

バックエンドで計算を行う強い理由があります

ビジネスロジックはプレゼンテーション層に属していません
JavaScriptのビジネスロジックが脅威をもたらす
常に真実ではない、1つのフロントエンド-> 1つのバックエンドの関係があると仮定します。バックエンドは、複数のフロントエンドアプリケーションに対応できるか、複数のフロントエンドアプリケーションにサービスを提供するものと見なされるため、何も想定できません。
計算で大量のデータを使用する場合、フロントエンドで保持するのは効率的ではありません
計算でデータベースを使用する場合、フロントエンドでそれを複製することはできません

私の推薦

外部キー、主キー、チェック制約、トリガーなど、モデルで可能な限り多くのビジネスルールをデータベースに適用させる
（データベースがエラーを返したため、またはビジネスレイヤー自体がデータを検証したために）ビジネスルールが満たされない場合に、ビジネスレイヤーに例外をスローさせる
応答時間が許容できない場合にのみ、Ajaxを使用して検証または前処理を行います（作業は実際にはJavaScriptでは行われません。ページをリロードすることなくバックエンドで行われます）
空の値、長すぎる、または範囲外の値を許可しないなど、JavaScriptで簡単な検証を行うことができます（後者の場合、バックエンドで範囲を生成することができます）

— トゥレインズコルドヴァ
ソース

データベースにビジネスルールを適用させることに関する問題は、フロントエンドに違反を報告することです！フロントエンドがビジネスルールを実施する場合、意味のあるエラーメッセージをユーザーにすばやくフィードバックできます。バックエンドがそれを行う場合、エラーが一度に1つずつ報告されるため、フロントエンドとバックエンドの間に多くの不格好な双方向トラフィックがあります。

— ジェームズアンダーソン14年

@JamesAnderson「フロントエンド」はなくなりました。同じデータベースに対して複数のフロントエンドが存在することもあれば、複数のフロントエンドに対して複数のデータベースが存在することもあります。また、バックエンドがビジネスルールを強制することは、フロントエンドがそれを行うことを禁止されることを意味しません。2番目の箇条書きでそれを強調しました。

— Tulainsコルドバ