ビジネスロジック：クライアント側とサーバー側
3〜5年前（多かれ少なかれ）にサーバー側のn層アプリケーションがあり、UIのjavascript/html/CSSがWeb開発の基本的なアプローチだったとします。
今日では、従来のWeb開発のパラダイムが大きく変化していることがわかります。毎日、従来の方法でサーバー側を持たないアプリケーションがますます見られました。いくつかのサービス（データサービス、認証サービスなど）を消費するだけですが、ビジネスロジックはクライアント側に配置されます。また、すでに多くのJavaScriptフレームワークが、このようなモデル（Angular、Backboneなど）に従って開発を簡素化するために作成しています。
新しいモデルと従来のアプローチの主な利点と欠点は何ですか？
このアプローチにはいくつかの利点があります：-
- 応答性。ビジネスロジックはファットクライアントにあるため、すべての対話のためにネットワーク上の往復を待つ必要はありません。
- 洗練された-クライアントにすべての制御とより高いレベルのロジックがあることで、リッチなユーザーインターフェイス（このサイトやGmailなど）が可能になります。
- スケーラビリティ。このすべての処理は、電気を使用してデバイス上で行われます。ユーザー数が多い場合は、サーバー側の処理を大幅に節約できます。
ただし、いくつかの欠点もあります。
- クライアント環境を制御できない。クライアントがどのOSのどのブラウザを使用しているか、どの画面サイズと処理能力を使用しているかがわかりません。アプリケーションがすべてのクライアントで機能するとは限りません。
- 不均一な応答。大規模なクライアントライブラリは時々ダウンロードしてアップグレードする必要がありますが、ダウンロードは比較的遅くなります。ダウンロードが完了すると、ユーザーの応答は非常に遅くなります。
- Javascript-好きでも嫌いでも、あなたの主要な開発言語として立ち往生しています。コードが公開され、一部の企業が嫌います（おそらく、コードの品質に困惑していますか？）。
- セキュリティ-サーバー側のコードは主にデータベースサービスになり、そのAPIはJavascriptを勉強している人なら誰でも利用できるので、これらのサービスのセキュリティ保護には特別な注意が必要です。
@James Andersonの発言に加えて、共有データベーステーブルを使用するシステムで作業している場合は、サーバーおよび使用するすべてのタイプのクライアントでビジネスルールが繰り返されないようにする必要があります。場合によっては検証が必要な場合もありますが、可能であれば他のビジネスルールを繰り返さないでください。同じルールを別の言語で複製しようとすると、エラーが発生しやすくなります。また、検証を実行するために、いくつかのデータを抽出し、このデータをクライアントにプルする必要がある場合もあります。これは応答性に反します。
INMO、懸念事項の分離は、応答性が重要な問題ではない場合、設計の優先事項と見なされます。
私が取り上げることを避けた1つの主題は、「JSをオフにするクライアントをどうするか」です...
ここでは2種類のロジックについて話していると思います。
アプリケーションロジックおよびビジネスロジック。
アプリケーションロジックにはユースケースが含まれています。ビジネスロジックにはビジネスルールが含まれています。アプリケーションロジック（およびプレゼンテーションロジック）は、クライアント側に実装できます。サーバー側のみのビジネスロジック。
"あなたに知られていない、あなたの最も恐れられているビジネスの敵は、あなたが開発に関与していなかったまったく新しいソフトウェアの本体を注意深く構築しました。"
このソフトウェア本体は、完全にクライアントサイドで動作します（もちろん）は、敵が注意深く分析したサーバーサイドのコードと完全に相互作用するように設計されています。 your "クライアント側コード"を正確に模倣しましたが、実際には完全に不正なものでした。
しかし、あなたの敵は、サーバー側のコードが常に想定であり、「友達と話している」という事実を十分に利用しました。したがって、それはtrustedその「友達ではなかった友達」であり、実際には識別できませんでした（そして、そうすることを決して考えていませんでした）。
実際のインターネットへようこそ。 *「信頼...しかし確認してください。」