web-dev-qa-db-ja.com

サーバー側のページレンダリングを使用するとどのような利点がありますか?

私はWebアプリを開発しており、現在、Webサイト全体をhtml/js/cssで記述しており、バックエンドにはいくつかのRESTFULサービスをホストするサーブレットがあります。すべてのプレゼンテーションロジックは、jsonオブジェクトを取得し、javascriptを使用してビューを変更することによって行われます。

アプリケーションは基本的に検索エンジンですが、異なる役割を持つユーザーアカウントがあります。

PlayやSpringなどのいくつかのフレームワークを研究しています。私はWeb開発にかなり慣れていないので、サーバーサイドページのレンダリングを使用するとどのような利点があるのか​​疑問に思いました。

スピードですか?簡単な開発とワークフロー?既存のライブラリへのアクセス?もっと?上記のすべて?

19
user1303881

サーバー側のHTMLレンダリング:

  • 最速のブラウザレンダリング
  • ページキャッシングは、迅速で汚れたパフォーマンスの向上として可能です。
  • 「標準」アプリの場合、多くのUI機能が事前に構築されています
  • コンポーネントは通常コンパイル時の検証の対象となるため、より多くのstableと見なされることがあります
  • バックエンドの専門知識を活用
  • 時には開発が速くなる*

* UI要件がフレームワークに適切に適合する場合。


クライアント側のHTMLレンダリング:

  • 帯域幅の使用量が少ない
  • 初期ページのレンダリングが遅い。最近のデスクトップブラウザでは目立ちません。 IE6-7、または多くのモバイルブラウザー(モバイルWebキットは悪くない)をサポートする必要がある場合、ボトルネックが発生する可能性があります。
  • APIを最初に構築するということは、クライアントがプロプライエタリアプリ、シンクライアント、別のWebサービスなどと同じくらい簡単にできることを意味します。
  • JSの専門知識を活用
  • 時には開発が速くなる**

** UIの大部分がカスタムで、より興味深いやり取りがある場合。また、interpretedコードを使用したブラウザでのコーディングは、コンパイルとサーバーの再起動を待つよりも著しく高速です。


mustache のようなフロントエンド/バックエンドテンプレートシステムを使用した軽いバックエンド実装のハイブリッドモデルを検討することもできます。

16
peteorpeter

サーバーサイドHTML生成:

  • デバッグが簡単です。
  • ブラウザの互換性に問題はありません。
  • 従来のフルページのサーバー側生成では、たとえ不変部分が大きくても、HTMLをキャッシュするのは困難です。 (解決策は、AJAX呼び出しを介してHTMLフラグメントをフェッチすることです);
  • 動的HTMLのキャッシュプロキシとCDNを利用しない。

クライアント側のHTML生成:

  • デバッグが難しい。
  • 廃止されたブラウザに関するいくつかの問題。
  • クライアント側でHTMLテンプレートをキャッシュしても問題ありません。
  • hTMLテンプレートとJSコードのキャッシュプロキシとCDNを利用する。
  • はるかに低いネットワーク使用量。

クライアント側での生成は、モバイルサイトが成功した場合の方法です。明らかに、最新のブラウザー(WebKitベースのブラウザーはモバイル市場の70〜80%を持っています)の方が効率的です。

LinkedInには、例として dust.js を使用したクライアント側アプローチの利点に関する記事があります:"JSPをほこりに残す:LinkedInをdust.jsクライアント側テンプレートに移動する"

3
vartec

要件によって異なります。多くの小さなタスクに依存する、高パフォーマンス、低レイテンシのソリューションが必要な場合は、あなたが説明しているのと同様の構造を採用することができます。ただし、Java、PHP、C#の最も一般的なソリューションは、デフォルトではこれに設定されていません。

ほとんどのWebアプリケーションはデータベースに大きく依存しています。それらのほとんどは非常に多く、少なくとも1回の呼び出しなしではページをレンダリングできません。明らかに、いくつかの理由により、データベースを公開したくない場合:

  • セキュリティ(- Oded 言及として)-あなたは間違いなくネットワークを公開したくないです(---)。理想的には、外部からシステムへの唯一のインターフェースは、サーバーへのhttpsである必要があります。
  • 開発のしやすさ-本当に、reallyreallyJavascriptでSQLを記述したくありません。Webプレゼンテーション用に設計された言語は、RDBではうまく機能しません。たとえば、彼らには状態の概念がありません。

したがって、データベースが必要な場合は、Java、C#、PHPなど、Niceを使用する言語を使用します。ページを生成する最も簡単な方法は、次のとおりです。テンプレート言語(最も有名なのはPHP、しかし、JSPとASPは他の2つの非常に一般的な言語です)ページを構築します。この言語は他のモジュールを呼び出す構築を提供します。PHPページまたは別のPHPファイル、MVCパターンを使用します。JSPでは、スクリプトレットまたはJSP式言語を使用します。これらの他のモジュールは、DBに接続してロジックを実行するという重労働に対応できます。 、およびビューレイヤーに値を返します。最終結果は、サーバーでレンダリングされてクライアントに送信される生成されたHTMLページです。

データベースがページレンダラーと同じネットワーク上にある場合、パフォーマンスも向上します。クライアントは1つの要求を実行するだけでページを受信します。ユーザーが必要とするすべての情報を入手する前に、10〜15のDB要求を実行する必要がある場合があります。クライアントがすべてを実行しなければならない場合、ネットワーク上のミリ秒の待ち時間は数秒から数分になります。

システムが大きくなると、懸念事項とコアコンピテンシーの分離が重要になります。 HTMLは表示に適しています。 JavaScriptは動的コンテンツに適しています。 SQLはデータベースのクエリに最適で、他の言語はビジネスロジックが得意です。開発者としての私たちの仕事は、メンテナンス可能なシステムを構築するために利用可能なすべてのツールを使用することです。開発の容易さは、優れたシステムの巨大な部分です。私の考えでは、パフォーマンスとユーザビリティと同じくらい重要です。優れたシステムは時間とともに進化します。貧弱なシステムは最初からひどく書かれていて、決して改善されませんでした。

1
Michael K

モバイルクライアントは通常、電力、帯域幅、およびメモリに制約があります。サーバーでページをレンダリングする方が良いでしょう。

デスクトップクライアントの場合、js + jsonを送信して、クライアントでページをレンダリングしたり、動的に更新可能にしたりすることを検討できます。

0
9000

サーバーサイドレンダリングの大きな利点の1つは、アクセシビリティです。JavaScriptベースのアプリは、視力のない人にとっては依然として大きな問題です。それと、あなたが仕出したいと思うかもしれない「googlebot」と呼ばれるこの盲人がいます。彼はjavascriptもあまり上手ではありません。

0
Wyatt Barnett