クライアント側またはサーバー側の処理を重視する間の長所/短所

多くの処理サーバー側でWebアプリを作成するのはなぜですか？

私にとって、クライアント側でプログラムを作成することは、最小限の処理でクライアントにデータを送信するだけでよいため、サーバーの負荷を可能な限り軽減できるため、大きな利点です。

サーバー側で記述し、クライアント側をビューとしてのみ扱う以外に、web-appsの記述はほとんどありません。なぜこれをしたいのですか？私が見る唯一の利点は、私が好きな言語で書くことができることです（http://www.paulgraham.com/avg.html）。

2つの大きな問題があります。

1. 1つ目は簡単です。通常、クライアント側でどのようなリソースが利用できるかわかりません。何かを処理するのに1.5GBが必要な場合、未知のクライアントプラットフォーム上の未知のクライアントブラウザ（IE、Safari、Opera、Firefoxなど）にそれを本当にプッシュできますか？あなたがそれを圧倒するとき、クライアントは彼のシステムドッギングに感謝しますか？

2. 2つ目はより建築的です。外の世界に公開したいレイヤーは何ですか？ほとんどの人は、データレイヤーを公開するのは非常にリスクが高いことに同意するでしょう。サービス層はどうですか？本当にそのロジックを世に送り出したいですか？その場合、エントリポイントもデータレイヤーに公開していますか？サービスレイヤーサーバー側を維持する場合、何が残っていますか？UI、そうですか？サーバー上にどれだけ存在し、クライアント上にどれだけ存在するかについての考慮事項については、理由1を参照してください。

何よりもまずセキュリティです。すべてのロジックをクライアントにプッシュすると、ハッカーやエクスプロイトにとって公平なゲームになります。

価値が認識されているもの、特に金銭的な価値は5分間持続せず、ゲーム、ハッキング、または悪用され、システムがかなりひどく破壊されます。たとえそれが金銭的価値がほとんどない場合でも、退屈しているためにシステムを破壊するためだけにハッキングする人々のクラスがあります。

クライアント側とサーバー側

クライアント側の処理は、ページベースのアプローチやSOAPとは対照的に、MVCと同様に、より一般的なREST標準に準拠しています。これらのトレンドが出現し、AJAXとHtml-RIAに焦点を当てたクライアント側のスクリプティングは増加しており、より人気があります。ただし、セキュリティ上の懸念とクライアント機能により、クライアント側のスクリプトには特定のニッチがあり、すべてに使用するべきではありません。

考慮事項：

モバイル

ターゲットオーディエンスの大部分がモバイルユーザーである場合、重い処理はサーバーに任せる必要があります。

クロスブラウザの一貫性

Web標準は大きな進歩を遂げており、これはそれほど大きな懸念ではないかもしれませんが、すべてのWeb開発者はIE 6、7、および8、そして時にはSafariがクライアント側でおかしな動作をすることを知っています-特定の機能は未実装の標準によるセキュリティ制限など。また、エンドユーザーがブラウザに特定の制限を設定したり、クライアント側の処理を完全にオフにしたりすることもできることに注意してください（javascriptはありません！）。一貫性が100％のユーザーの要件である場合（特に非正統的なことをしている場合）、サーバー側が最も重要です。

セキュリティ

セキュリティで保護するデータ操作は、サーバーで実行する必要があります。クライアント側で処理されるデータは、操作のために完全に開かれています。たとえば、一部の情報を処理してシステムにポストバックするjavascript関数がある場合、例示的なバックエンドセキュリティがある場合でも、ポストバックされる直前に結果を操作するのは非常に簡単です

UI / UX

クライアント側の処理は、ユーザーインターフェイスとリッチインターネットアプリケーション（RIA）の作成のために残されています。これは、ページ全体を再ロードする代わりに、アニメーション、エフェクト、ユーザーインタラクションの作成、およびAJAX呼び出しによるコンテンツの動的なロードに使用されます。

主に努力の重複です。ほとんどの場合、クライアントからのデータはすべてサーバーレベルでチェックおよび処理されます。

サーバーは、リッチ/ロバストなクライアントがデータを送信したと想定できないため、データが送信されると、サーバーはそれを検証して処理する必要があります。そこに置くのは理にかなっています。

ただし、UIの操作性を向上させるために、クライアントレベルでいくつかのロジックを実行できると考えています。

あなたは正しい、完全でないか間違っている場合にサーバーにデータを送信する理由。必須フィールドや、適切にフォーマットされた電話番号やメールアドレスを簡単に確認できます。フォームを送信してから5秒間待ってから、フィールドへの入力を忘れたことを通知するのは好きではありません。この種の処理は、クライアント上で実行し、それが正しいことを確認し、ユーザーへの高速応答のためにクライアント側のロジックを使用します。あなたが指摘したように、ボーナスの副作用は、サーバーがより少ない悪いデータ要求に対処しなければならないということです。しかし、サーバーも検証する必要があるため、ロジックを複製しています。しかし、ユーザーはより幸せになります。

ここに細かい線があります。単純な検証ロジックはOK、コアビジネスロジックはOKではありません。

1. まず、Webアプリケーションのアーキテクチャを理解する必要があります。ほとんどの場合、すべてが3層です。

   a）クライアント/プレゼンテーション-HTMLおよびJavascript。ActiveX/ Flash / Java Applets / Silverlightが含まれる場合があります。手足に出て、バックエンドサーバーと通信するネイティブモバイルアプリケーションを追加します。基本的に、このレイヤーの役割は、システムのユーザーと対話するためのインターフェースを提供することです。

   b）ビジネスロジック-クライアントからのデータが収集、処理、保存され、クライアントからのデータ要求が処理されてクライアントに返送されるPHP / RoR / Java

   c）バックエンドデータストア-システム情報の永続的なストレージを提供します

2. すべてのレイヤーで、どこで検証を行いますか。どうして？

   a）クライアント側-ユーザーが正しいデータ、必須フィールドなどを入力することを確認します

   b）ビジネスロジック-クライアントデータのフィルタリング、サニタイズ、検証。より複雑なビジネスルールを実行して、データがストレージに適した形式であることを確認します。異なるクライアントが存在する可能性があるため、フロントエンドで行われた検証の一部がここで繰り返されます。たとえば、ブラウザではJavascriptを無効にできます。また、たとえばAPIを介してさまざまなソースからデータを受け入れる場合があるため、すべて検証する必要があります。

   c）バックエンドデータストア-制約により、データが保存および後で取得できるように整形されます。

検証作業をどこに集中し、各レイヤーを使用して最適な検証を実行し、それを処理できるレイヤーにはより複雑なルールを残します

大きな部分は、処理をデータに近づけることです。数百GBのデータがある場合は、明らかにそれをクライアントに出荷しません。データアクセス速度の向上により、これは問題になりつつありますが、ビッグデータサイトがある場合は、サーバーを出荷する前にできるだけ多くのフィルタリングと絞り込みを行う必要があります。

クライアント側で（たとえば、JavaScriptを使用して）完全に動作を作成すると、SEOが問題になる可能性があります。

サーバー側に多く保持するWebsolutionsは、特定のURL（通常はRESTful）に投稿された特定のコンテンツを、検索エンジンに表示される方法でより簡単に保持できます。

これは、訪問者が特定のページをブックマークできることも意味します。Facebookで試しましたか？

このような問題は解決できますが、通常はサーバー上で多くの処理を行うアプリケーション（RAILS、WordPressなど）に組み込まれていますが、REACTでビルドする場合は、フープをジャンプする必要があります。

その理由は安定性です。

サーバー側では、安定したコンポーネントを選択できます。通常、これは、JavaとFreeMarkerなどの非常に慎重に選択された多数のライブラリを選択することを意味します。言うまでもなく、Javaの標準ライブラリ以外のすべてのライブラリは使い捨てとして扱われるため、私は自作のラッパーを介して外部ライブラリにアクセスします。つまり、必要に応じて、あるライブラリから別のライブラリに簡単に変更できます。

Javaを新しいバージョンに更新するときは常に、Javaはメジャーバージョンの更新でも非常に安定したコンポーネントであるため、通常はうまく機能します。また、私が持っているすべてのサーバーは同じJavaバージョンを実行しています。すべてのクライアントが同じJavaScript実装を実行しているわけではありません。

クライアント側では、安定したコンポーネントを選択できません。ブラウザのメーカーは、私が特に好きではないが、使用を余儀なくされている言語であるJavaScriptを選択するように強制します。（そして、JavaScriptにコンパイルされた言語について教えてはいけません、それらは恐ろしいです！）すべてのブラウザーのJavaScript実装は異なります。これは、サポートされているすべてのブラウザーバージョンで製品をテストすることは完全に困難であることを意味します。

私の解決策は？サーバー側でできる限り多くの処理を実行します。クライアント側は、サーバーにデータを送信し、JSONおよびHTMLフラグメントの形式でサーバーからデータを受信する軽量のラッパーです。XMLを避けます。代わりにJSONを使用してください。

クライアント側のテンプレート作成は行いません。サーバー上のコンテンツをHTMLフラグメントにレンダリングしてから、.innerHTML属性を使用してクライアント側のさまざまなプレースホルダー要素に割り当てます。これにより、2つのテンプレートエンジン（JavaエンジンとJavaScriptエンジン）が必要ないため、テクノロジースタックが可能な限りシンプルになります。

欠点は明らかに光速の遅延です。大陸間で0.5秒の待ち時間は珍しくありません。

最近のクライアントはスマートフォンかもしれないと考えてください。スマートフォンのバッテリー寿命は限られているため、大量の計算を行う場合は、サーバーにオフロードすることをお勧めします。ただし、無線アクセスを回避できるため、クライアント側で簡単なことを行うとエネルギー効率が向上します。しかし、主な議論である安定性は、単純な計算であってもサーバーにオフロードすることが実際に理にかなっていることを意味する場合があります。

補遺として、いくつかの回答ですでに見たように、セキュリティも向上します。アプリケーションロジックがすべてクライアント側にある場合、誰かが、たとえば、オンラインWebショップから購入するものに価格を設定できます。