クライアント側またはサーバー側の処理を強調することの長所/短所
大量のサーバー側の処理を含むWebアプリを作成する理由は何ですか？
私にとって、クライアント側のプログラムを記述することは、サーバーへの負荷を最小限に抑えることができるため、最小限の処理でクライアントにデータを送信するだけで済むため、大きな利点です。
サーバー側で記述し、クライアント側をビューのみとして扱うこと以外に、Webアプリの記述はほとんどありません。なぜこれをしたいのですか？私が目にする唯一の利点は、好きな言語で書けることです（ http://www.paulgraham.com/avg.html ）。
2つの大きな問題があります。
1つ目は簡単です。通常、クライアント側で使用可能なリソースの種類がわかりません。何かを処理するために1.5GBを必要とする場合、それを未知のクライアントプラットフォーム上の未知のクライアントブラウザ（IE、Safari、Opera、Firefoxなど）に本当にプッシュできますか？あなたがそれを圧倒したとき、クライアントは彼のシステムのドッギングに感謝しますか？
2つ目はよりアーキテクチャ的なものです。どのレイヤーを外の世界に公開したいですか？ほとんどの人は、データ層を公開することは非常に危険であることに同意するでしょう。サービス層はどうですか？あなたは本当にそのロジックをそこに提供したいですか？その場合、エントリポイントをデータレイヤーに公開していますか？サービス層のサーバー側を維持すると、何が残りますか？ UIですね。サーバーにどれだけ存在し、クライアントにどれだけ存在するかについての考慮事項については、理由1を参照してください。
何よりもまずSecurityです。すべてのロジックをクライアントにプッシュします。これは、ハッカーとエクスプロイトにとって公平なゲームです。
知覚された価値のあるものはすべて5分間持続せず、特に金銭的価値はありません。ゲームやハッキング、または悪用され、システムをかなり破壊します。金銭的価値がほとんどないかまったくない場合でも、退屈しているためにシステムを破壊するためだけにハッキングする人々がいます。
クライアント側とサーバー側
クライアント側の処理は、ページベースのアプローチやSOAPとは対照的に、より一般的なREST標準およびMVCに準拠しています。これらのトレンドの出現とAJAXとHtml-RIAに焦点を当てたクライアント側スクリプトは増加し、より人気があります。ただし、セキュリティ上の懸念とクライアント機能のため、クライアント側のスクリプトには特定のニッチがあり、すべてに使用するべきではありません。
考慮事項：
モバイル
ターゲットオーディエンスの大部分がモバイルユーザーである場合、重い処理はサーバーに任せる必要があります。
クロスブラウザーの整合性
Web標準は長い道のりを歩んできており、これはそれほど懸念事項ではないかもしれませんが、すべてのWeb開発者はIE 6,7および8を知っており、Safariはクライアント側でおかしな動作をすることがあります。機能が実行されない可能性があります。これは、セキュリティ上の制限や、標準が実装されていないためです。エンドユーザーがブラウザに特定の制限を設定したり、クライアント側の処理を完全にオフにしたりすることもできることにも注意してください（JavaScriptなし！）。一貫性が100％のユーザーの要件である場合（特に、正統でない何かをしている場合）、サーバー側が最も重要です。
セキュリティ
保護したいデータ操作はすべてサーバー上で行う必要があります。クライアント側で処理されるすべてのデータは、操作のために完全に開かれています。たとえば、システムにポストバックされる情報を処理するJavaScript関数がある場合、バックエンドセキュリティの例を示していても、ポストバックされる直前に結果を操作するのは非常に簡単です。
UI/UX
クライアント側の処理は、ユーザーインターフェイスとリッチインターネットアプリケーション（RIA）の作成に任されています。ページ全体を再ロードする代わりに、アニメーション、エフェクト、ユーザーインタラクションの作成、およびAJAX呼び出しによるコンテンツの動的なロードに使用されます。
主にそれは努力の重複になります。ほとんどの場合、クライアントからのデータはすべてサーバーレベルでチェックおよび処理されます。
サーバーは、リッチ/ロバストクライアントがデータを送信したと想定できないため、データが送信されると、サーバーはそれを検証して処理する必要があります。そこに置くのは理にかなっています。
ただし、UIエクスペリエンスを向上させるために、クライアントレベルで実行できるロジックがあると思います。
あなたは正しいです。完全ではない、または正しくない場合、なぜサーバーにデータを送信してください。必須フィールドや、適切にフォーマットされた電話や電子メールアドレスを簡単に確認できます。フォームを送信して5秒間待って、フィールドに入力するのを忘れたことを知らせるのは好きではありませんでした。この種の処理は、クライアントで実行し、それが正しいことを確認し、クライアント側のロジックを使用してユーザーに迅速に応答します。あなたが指摘したように、ボーナス副作用はあなたのサーバーがより少ない悪いデータ要求を処理しなければならないだろうということでしょう。ただし、サーバーも検証する必要があるため、ロジックを複製しています。しかし、ユーザーは幸せになります。
ここには細い線があります。単純な検証ロジックはOK、コアビジネスロジックはOKではありません。
まず最初に、Webアプリケーションのアーキテクチャを理解する必要があります。
a）クライアント/プレゼンテーション-HTMLおよびJavascript、ActiveX/Flash/Javaアプレット/ Silverlightが含まれる場合があります。すぐに外に出て、バックエンドサーバーと通信するネイティブモバイルアプリケーションを追加します。基本的に、この層の役割は、システムのユーザーがそれと対話するためのインターフェースを提供することです。
b）ビジネスロジック-クライアントからのデータが収集、処理、および保存されるPHP/RoR/Java。データに対するクライアント要求が処理され、クライアントに送り返されます。
c）バックエンドデータストア-システム情報の永続的なストレージを提供します
それで、すべてのレイヤーで、どこで検証を行いますか？どうして？
a）クライアント側-ユーザーが正しいデータ、必須フィールドなどを入力していることを確認します
b）ビジネスロジック-クライアントデータのフィルタリング、サニタイズ、および検証。より複雑なビジネスルールを実行して、データがストレージ用に適切に形成されていることを確認します。フロントエンドで行われる検証の一部はここで繰り返されます。たとえば、異なるブラウザーが存在する可能性があるという事実により、ブラウザーを例に取ると、JavaScriptを無効にすることができます。また、たとえばAPIを介してさまざまなソースからのデータを受け入れる可能性があるため、すべて検証する必要があります。
c）バックエンドデータストア-制約により、データが保存および後で取得できるように適切に形成されます。
したがって、検証作業のどこに重点を置き、各レイヤーを使用して最適な検証を実行し、それを処理できるレイヤーにより複雑なルールを残します
大きな部分は、処理をデータに近づけることです。数百GBのデータがある場合、明らかにそれをクライアントに送信することはありません。データアクセスの速度が上がると、これはそれほど問題になりませんが、ビッグデータサイトがある場合でも、出荷前にサーバーで可能な限り多くのフィルタリングと絞り込みを行う必要があります。
クライアント側で（たとえばJavaScriptで）完全に動作を作成すると、SEOが問題になる可能性があります。
サーバー側に多くを保持するWebソリューションは、特定のコンテンツを特定のURL（通常はRESTful）に投稿した状態を、検索エンジンに表示される方法でより簡単に保持できます。
これは、訪問者が特定のページをブックマークできることも意味します。 Facebookでそれを試しましたか？
この問題は解決できますが、通常はサーバーで多くのことを行うアプリケーション（Rails、WordPressなど））に組み込まれていますが、たとえばREACTでビルドしている場合は、フープをジャンプします。
その理由は 安定。
サーバー側では、安定したコンポーネントを選択できます。通常、これはJavaとFreeMarkerなどの厳選された多数のライブラリを選択することを意味します。言うまでもなく、Javaの標準ライブラリを除くすべてのライブラリは使い捨てとして扱われるため、自作のラッパーです。これは、要件が発生した場合に、あるライブラリから別のライブラリに簡単に変更できることを意味します。
Javaを新しいバージョンに更新するときはいつでも、Javaはメジャーバージョンの更新であっても非常に安定したコンポーネントであるため、通常はうまく機能します。また、すべてのサーバーhaveは同じJavaバージョンを実行しています。すべてのクライアントが同じJavaScript実装を実行しているわけではありません。
クライアント側では、安定したコンポーネントを選択できません。ブラウザメーカーは、私がJavaScriptを選択するように強制します。JavaScriptは、私が特に好きではない言語ですが、私は強制的に使用される言語です。 （そして、JavaScriptにコンパイルされている言語について教えてください、それらは恐ろしいです！）すべてのブラウザーのJavaScript実装は異なります。これは、サポートされているすべてのブラウザーバージョンで製品をテストするのはまったくの地獄であることを意味します。
私の解決策？私はサーバー側でできる限り多くの処理を実行します。クライアント側は、サーバーにデータを送信し、JSONおよびHTMLフラグメントの形式でサーバーからデータを受信する軽量ラッパーにすぎません。 XMLは避けてください。代わりにJSONを使用してください。
クライアント側のテンプレートは行いません。サーバーのコンテンツをHTMLフラグメントにレンダリングし、.innerHTML属性を使用してクライアント側のさまざまなプレースホルダー要素に割り当てます。 2つのテンプレートエンジン（a Java one and a JavaScript one））を必要としないので、これにより、テクノロジスタックをできるだけシンプルに保つことができます。
欠点は明らかに光の速度の遅延です。 0.5秒のレイテンシは、大陸間で珍しくありません。
最近のクライアントはスマートフォンかもしれないと考えてください。スマートフォンのバッテリー寿命は限られているため、重い計算を行っている場合は、サーバーにオフロードすることをお勧めします。ただし、クライアント側で行うと、無線アクセスを回避できるため、単純なものの方がエネルギー効率が高くなります。しかし、主な議論である安定性は、単純な計算でさえサーバーにオフロードすることが実際に意味をなすことを意味する場合があります。
補遺として、すでにいくつかの回答で観察されているように、あなたは得る 安心 同様に。アプリケーションロジックが完全にクライアント側にある場合、誰かが実行できます。彼らがあなたのオンラインウェブショップから購入しようとしているものに価格を設定します。