標準CRUDアプリの「従来の」「バックエンド」アーキテクチャの利点は何ですか？
過去数年間で、「クライアント側」のWebアプリケーションが普及しました。最近の一般的なアプローチは、バックエンドをできるだけ薄くして、クライアント側のJavascriptアプリが消費するAPIを公開することです。
私が興味を持っているのは、このアプローチの利点ではありません。これは今日の好ましいアプローチのようであり、その長所はこのサイトで議論されています。
より伝統的なバックエンドベースのアプローチの利点に興味があります。ページのテンプレート化とルーティングがバックエンドで行われ、フロントエンドロジックが薄い場所。
この質問は、強力なアルゴリズムを実行する特殊なビデオ編集ソフトウェアやプログラムではなく、標準の「CRUD」アプリケーションを指していることに注意してください（この種の計算は明らかにバックエンドで行う必要があります）。
「典型的なWebアプリ」のバックエンドアーキテクチャの利点について言及しています。
クライアント側の実行の制約に達するたびに、メリットが現れます。 3つのケースを考えてみましょう。
ビデオ処理アプリケーション。制約は何でしょうか？そうです、クライアントマシンで実行されているブラウザのCPUとメモリの制約。多くのアクションは実行が実質的に不可能であるか、数秒ではなく数時間かかることにすぐに気づくでしょう。
ギガバイトのデータを使用するもの。データベースで何十億ものレコードを検索する場合、サーバーで実行すると数ミリ秒かかることがあります。クライアントが行う場合、インターネットの速度にもよりますが、数秒から数時間かかります。
競合他社から隠したいスマートアルゴリズム。誰でもJavaScriptを読むことができます。ロジックをサーバー側に移動することで、リバースエンジニアリングを困難または不可能にします。
サーバー側にロジックを配置することのもう1つの利点は、もちろん、ランタイム環境を正確に制御できることです。オペレーティングシステム、プログラミング言語、さらには基盤となるハードウェアを選択できます。クライアント側のスクリプトの世界では、このような自由はありません。あなたのコードは、Windows XPとIE7、またはタブレット、スマートフォン、またはテキスト読み上げと音声文字変換インターフェース。
サーバーでのみ実行できるタスクと、クライアントでのみ実行できるタスクがあります。その他の場合、フロントエンドよりもバックエンドに何かを実装することには、合理的に明らかな利点がいくつかあります。
- より良いキャッシュオプション、例えば ワニス および同様のテクノロジー
- 多くの場合、速度-ベンチマークが示すように、典型的なJava/C＃コードはJavaScriptよりも高速です。ただし、ボトルネックがネットワーキングと計算である場合、SPAが勝ちます
- 1つのプラットフォーム向けの開発と、8つ以上の異なるブラウザー向けの開発の比較、したがってメンテナンスの簡素化
- 「ロジックを隠す」と不正行為防止。たとえば、オンラインゲームを構築している場合、クライアントのゲームロジックを変更することで不正行為やハッキングを防ぐために、サーバー上で実行したい部分があります。また、ユーザーからアルゴリズムを隠したい場合は、同じようにします
- 多くの場合、ブラウザの一部の機能の欠如、またはそのような機能の非効率性。たとえば、さまざまなデータ集計関数を使用して大量のデータに関するレポートを作成することは、SQLでは効率的に実行できますが、JavaScriptでは実行できません。