1

まったく新しい Web サイトを作成し、すべてをゼロから作成します。主にフロントエンド部分です。スケーラブルなフロントエンド アーキテクチャを構築するためのリソースがあるかどうかを知りたいのですが、この種の経験はこれまでなかったからです。どんな提案、アイデア、または本の推薦も大歓迎です！

4

1 に答える 1

2

ご質問のすべての部分が不明であるため、お答えするのは困難です。私の知る限り、「スケーラブルなフロントエンド アーキテクチャ」などの定義はありません。スケーラブルとフロントエンドはどちらも非常に幅広いトピックなので、推測するしかありません...

あなたの用語では、フロントエンドは単一ページの JavaScript アプリケーションを意味し、スケーラブルな部分は機能的なスケーラビリティを意味すると想定しています(サーバー側のコンテキストで通常使用されるスケーラビリティの負荷ではありません)。これらの制約があるため、REST アーキテクチャが私が知っている中で最も適していると思います。

  • REST アーキテクチャによって、REST サービスと REST クライアントが存在します。どちらもアプリケーションです。フロントエンド アプリケーションとしてブラウザで REST クライアントを実行し、バックエンド アプリケーションとしてサーバーで REST サービスを実行できます。REST は HTTP 1.1 プロトコル用に設計されているため、ご覧のとおり、HTTP クライアントとサーバーの通常のコンテキストに簡単に適合できます。

  • 通常の Web サービスはクライアントにデータのみを提供し (JSON 形式など)、クライアントはそのデータの処理方法を認識している必要があります。そのため、クライアントにはビジネス ロジックのフラグメントが含まれている必要があります。サービスにはビジネス ロジックも含まれます。これは、要求の有効性をチェックするための唯一の安全な環境であり、共通の永続ストレージ (データベース) にアクセスできるのはサービスだけであるためです。その場合、サービスとクライアントの両方に同じコード フラグメントが含まれているため、Web アプリケーションのコードは DRY ではありません。非 DRY コードの保守が難しいことは既にご存じだと思います... REST アーキテクチャにより、サービスはデータだけでなく、抽象コントローラー (リンクとフォーム) の表現をクライアントに送信します。これは、任意のハイパーメディア形式を送信することで実行できます。HTTP 通信も同じことを考えると、コントローラーとデータ表現を HTML 形式で送信します。HTML をメッセージ形式として使用することもできますが、HTML 形式のデータをシリアル化する方法が推奨されておらず、解析が困難で遅いため、お勧めできません。XML と JSON は異なり、データのシリアル化用に設計されていますが、コントローラーの記述がありません。現在、ATOM+XML、HAL+XML、HAL+JSON、JSON-LD、サイレン (JSON)、コレクション+JSON など、XML と JSON で構築された新しいハイパーメディア形式が多数あります。しかし、それらにはコントローラーの説明がありません。現在、ATOM+XML、HAL+XML、HAL+JSON、JSON-LD、サイレン (JSON)、コレクション+JSON など、XML と JSON で構築された新しいハイパーメディア形式が多数あります。しかし、それらにはコントローラーの説明がありません。現在、ATOM+XML、HAL+XML、HAL+JSON、JSON-LD、サイレン (JSON)、コレクション+JSON など、XML と JSON で構築された新しいハイパーメディア形式が多数あります。

  • したがって、REST クライアントは、REST サービスからハイパーメディア形式でデータとコントローラー表現を取得します。たとえば、プロファイル ページでは、名前、生年月日などをデータとして取得し、編集フォーム、削除リンクなどをコントローラーとして取得します。現在、コントローラーの記述方法に関する標準/推奨事項はほとんどありません。私が言及したメディア タイプを学習したり、独自のメディア タイプを作成したりできます。それほど難しいことではありません... 重要なことは、REST クライアントがコントローラーを取得するまで、正確なコントローラーについて何も認識してはならないということです。サービスから取得したコントローラーを表示する方法についてのみ知ることができます。たとえば、登録フォームでは、URL、メソッド、入力フィールドの名前などを知る必要はありませんが、現在のハイパーメディア形式で記述された登録フォームを表示する方法を知っている必要があります。ブラウザも同じことをします。フォームを HTML FORM 要素として取得し、記入済みのフォームをサーバーに送り返すときに何が起こるかについて何も知らないにもかかわらず、フォームを非常に適切に表示します。したがって、ブラウザーは、表示している Web アプリケーションのビジネス ロジックについて何も知りません。REST クライアントは REST サービスでも同じことを行います。REST サービスのビジネス ロジックについては何も知らず、REST サービスが送り返すハイパーメディアを表示する方法と、サービスにリクエストを送信する方法を知っているだけです。これは簡単に理解できるアプローチだと思います... この設計アプローチのおかげで、REST クライアントと REST サービスは疎結合で、エラー耐性があり、保守が容易です。たとえば、新しいリンクなどの新しい機能を REST サービスに追加しても、REST クライアントはリンクを処理する準備が整っているため、通常は影響を受けません。

REST アーキテクチャの理論を理解することはかなり簡単だと思いますが、ノウハウははるかに難しいです。最近ではRESTアーキテクチャが誇大宣伝されているため、通常のWebサービスをRESTサービスと呼ぶことが多いため、多くの混乱が生じます。誰もがそれをやりたいと思っていますが、正しく実行できる人はほとんどいません...

于 2014-02-25T00:44:58.387 に答える