実践的な Blazor 決定ガイド
Blazor: サーバー、WebAssembly、またはハイブリッド?
Blazor は、どの作業がサーバー上に残り、どの作業がブラウザーに移動するか、どの URL が実際の HTML リンクとして存在する必要があるかがわかっている場合に役立ちます。
このガイドではパンフレット版は省略しています。ここでは、サーバー メモリ、ライブ接続、レイテンシー、ペイロード サイズ、SEO、多言語ルーティングなど、後でチームを驚かせるトレードオフに焦点を当てています。
レンダリングモードを選択する前に
ブレイザーとは実際には何ですか Blazor
Blazor は、.NET Web アプリ用の Microsoft のコンポーネント フレームワークです。 Razor コンポーネントから UI を構築し、ほとんどの対話ロジックを C# で記述し、ASP.NET Core にそれらのコンポーネントをサーバー上、WebAssembly、またはネイティブ アプリ シェル内でレンダリングさせます。
これは古い ASP.NET のアイデアから生まれました。 Web フォームは、サーバー コントロールの背後に Web を隠そうとしました。 MVC と Razor Pages により、リクエストとレスポンスの HTML がよりクリーンになりました。 Blazor は再利用可能な対話型コンポーネントを追加しますが、単純なコンテンツ ページやフォームに関して MVC や Razor ページが廃止されるわけではありません。
Web フォーム、MVC、Razor Pages によってさまざまな問題が解決されました
Web フォームは生産的でしたが、重くてステートフルでした。 MVC と Razor Pages により、よりクリーンな HTML とよりシンプルなリクエスト処理が実現しました。ページが主にデータを読み取り、フォームを投稿し、HTML を返す場合には、依然として良好です。
コンポーネントは UI ロジックをマークアップの近くに保ちます
Razor コンポーネントには、マークアップ、パラメーター、イベント、検証、挿入されたサービス、ローカル状態を含めることができます。これは、完全にリロードせずにページが変更されるダッシュボード、エディター、ウィザード、グリッド、およびツールに役立ちます。
最新の .NET ではレンダリング モードを混在させることができます
新しい Blazor アプリでは、サーバーでレンダリングされた静的な HTML と対話型コンポーネントを組み合わせることができます。あるページにはクロール可能なコンテンツが必要である一方、別のページにはライブ コンポーネントが必要な場合があるため、これは重要です。
目次
ここから始めましょう
便利なショートバージョン
Blazor は 1 つのアーキテクチャではありません。これは、複数のレンダリング モードを備えた 1 つのコンポーネント モデルです。正しい選択は、構文よりも、状態、遅延、メモリ、およびクロール可能なリンクが存在する場所に依存します。
Blazor サーバーはステートフルです
最初のロードでは速く感じるかもしれませんが、サーバーはライブ回線を維持します。トラフィックが増加する前に、メモリ、再接続動作、スケールアウトを計画します。
WebAssembly は前払いです
ライブサーバー回線は削除されますが、最初のアクセス時にランタイムとアプリがダウンロードされます。キャッシュ、トリミング、プリレンダリングが重要です。
ハイブリッドは製品の決定です
アプリが本当にデスクトップまたはモバイル シェルを必要とする場合は、ハイブリッドを使用します。パブリック コンテンツの場合は、Web レンダリングと実際の URL を使用します。
Blazorサーバー
Blazor サーバーはクリック間で作業を維持します
Blazor サーバーは、通常のステートレスな要求/応答ページではありません。接続されたブラウザ タブは回線を取得します。サーバーは、ユーザーが接続している間、および多くの場合、切断後の短い再接続ウィンドウの間、コンポーネントの状態とその回線の範囲指定されたサービスを保持します。
アクティブ回路によりメモリが増加
接続された各タブには回路があります。コンポーネントの状態、スコープ指定されたサービス、検証状態、および保留中の UI 作業は、回線が終了するまでメモリ内に残る可能性があります。負荷テストでは、1 秒あたりのリクエストだけでなく、アクティブなユーザーもカウントする必要があります。
レイテンシが UI の一部になる
ボタンのクリック、入力イベント、またはグリッドのインタラクションは、サーバーに送られて戻ってくる可能性があります。視聴者が複数の地域にまたがる場合は、ユーザーの近くでホストし、おしゃべりなコンポーネントを避けます。
スケールアウトには計画が必要
複数のアプリ インスタンスには、多くの場合、スティッキー セッション、SignalR バックプレーン、Azure SignalR Service、または慎重な状態設計が必要です。そうしないと、再接続が行われ、ライブ回線が間違ったインスタンスに到達する可能性があります。
適切: 制御されたユーザー
Blazor Server は、ユーザー、待機時間、ホスティング容量がわかっている認証済みツール、管理画面、ダッシュボード、内部アプリに最適です。
Blazor WebAssembly
WebAssembly はコストを最初のロードに移動します
Blazor WebAssembly はサーバー回線を削除しますが、コストは削除されません。エクスペリエンスが高速であると感じる前に、ブラウザーは .NET ランタイム、アセンブリ、ローカリゼーション リソース、およびアプリ アセットをダウンロードする必要があります。キャッシュが役立つため、繰り返しアクセスすると良い場合があります。初めての訪問には注意が必要です。
最初の負担は税金です
ブラウザーは、.NET ランタイム、アプリ アセンブリ、リソース、および静的資産をダウンロードします。トリミングが役に立ちます。事前コンパイルにより CPU に負担のかかる作業が改善されますが、ダウンロード サイズが増加することがよくあります。
シークレットはクライアント内に存在できません
WebAssembly アプリはユーザーのブラウザーで実行されます。他のパブリック フロントエンドと同様に扱います。サーバー上で秘密を保持し、API を保護し、クライアント コードが検査できることを想定します。
SEOにはレンダリングされたコンテンツが必要です
公開記事、製品ページ、およびランディング ページについては、WebAssembly の起動後にのみ役立つ空のシェルに依存しないでください。サーバー側レンダリング、プリレンダリング、静的レンダリング、または別のコンテンツ パスを使用します。
最適: オフラインまたはクライアント負荷の高いアプリ
WebAssembly は、ユーザーが頻繁に戻ってくる場合、オフライン動作が必要な場合、またはサーバーのラウンドトリップが悪化するような重いクライアント側の作業を行う場合にうまく機能します。
ハイブリッドと WebView
ハイブリッドはアプリ向けであり、公開ランディング ページ向けではありません
Blazor Hybrid は、.NET チームがデスクトップまたはモバイル アプリ内のコンポーネントを再利用したい場合に役立ちます。 WebView を介してネイティブ シェルで実行されるため、ローカル ファイル、デバイス API、およびエンタープライズ展開に近い状態で使用できます。これは SEO を重視した Web サイトにとって近道ではありません。
- ローカル ファイル、デバイス API、デスクトップ展開、またはモバイル パッケージングにアクセスする必要がある場合は、ハイブリッドを使用します。
- Web コンポーネントを再利用するためだけにハイブリッドを選択しないでください。ネイティブ シェルにより、更新、保存、署名、およびサポート作業が追加されます。
- SEO と共有可能なパブリック URL の場合、通常、ハイブリッドは間違った表面です。
多言語ルーティング
文化を意識したリンクは本物のリンクでなければなりません
多言語 Blazor サイトでは、ページが対話型になった後、クリック ハンドラーまたは JavaScript のみで言語ナビゲーションを構築しないでください。検索エンジンとユーザーは、安定した href 値、正規 URL、hreflang データを含む、初期 HTML 内の実際のアンカー タグを必要とします。
- スラッシュ カルチャー スラッシュ パスのような手動で作成された文字列の代わりに、中央のページ リンクとヘルパーを使用します。
- 最初の HTML レンダリング中に、href 値を含むアンカー タグとして言語リンクをレンダリングします。
- 正規 URL、hreflang URL、および表示言語ナビゲーションの同期を維持します。
- onclick ハンドラー、遅延した JavaScript、または対話型のみの Blazor 状態の背後に重要なリンクを隠すことは避けてください。
選択ガイド
受け入れるボトルネックに応じて選択してください
すべてのレンダリング モードは、圧力を異なる場所に移動します。自分が測定し、ホストし、チームに説明できるプレッシャーを選択してください。
最初のロードと .NET バックエンドの統合が最も重要な場合
サーバー メモリ、ライブ接続、および地域待機時間が許容できる運用コストである、制御された認証済みアプリには Blazor サーバーを選択します。
クライアントの作業とオフラインでの行動が最も重要な場合
繰り返しのアクセス、キャッシュ、オフライン使用、またはローカル CPU 作業が最小の最初の読み込みよりも重要な場合は、WebAssembly を選択してください。
製品が実際にネイティブ アプリである場合
アプリケーションがデスクトップまたはモバイルに属し、パブリック Web へのアクセスよりもローカル統合が必要な場合は、ハイブリッドを選択します。
サイトのほとんどがドキュメントとフォームの場合
従来の ASP.NET Core MVC または Razor ページは、多くの場合、コンテンツの多いサイト、公開ドキュメント、および対話機能が制限されたフォームにとってよりシンプルです。
参照セクション
これを実際に構築するときは、次にこれらを読んでください
これらの参照は、運用環境で Blazor ページの信頼性を高める部分 (メタデータ、言語リンク、ホスティング、再利用可能な UI) をカバーしているため、アーキテクチャの決定後に役立ちます。
これは、すべてのページで一貫したタイトル、説明、Open Graph、正規、および JSON-LD 出力が必要な場合に使用します。
SEO対応ロケールリンク多言語ルーティングに実際のクロール可能なリンク、安定したカルチャ パス、および正しい hreflang 出力が必要な場合にこれを使用します。
UpCloudでBlazorをホストBlazor Server アプリで小規模な VPS、Nginx、TLS、systemd、ログ、バックアップ、反復可能なデプロイが必要な場合は、これを使用します。
TablerForNet値がマーケティング ページではなく、管理インターフェイス、データ テーブル、フォーム、ダッシュボード画面である場合にこれを使用します。
Blazor次の実装の詳細を選択する前に、関連するガイドを 1 か所にまとめておきたい場合は、Blazor ハブを使用します。
よくある質問
Blazor Server が MVC よりも多くのメモリを必要とするのはなぜですか?
MVC はリクエストを終了し、ほとんどのリクエスト状態を解放できます。 Blazor サーバーは、接続されているブラウザー タブごとに回路を保持するため、コンポーネントの状態とスコープ指定されたサービスはクリックの間も有効な状態を維持できます。
複数のアプリ インスタンスで Blazor サーバーを実行できますか?
はい、ただし慎重に計画してください。ライブ回線と SignalR 接続には、安定したルーティング、バックプレーンまたはマネージド SignalR サービス、および存続するアプリケーションの状態が正しく再接続される必要があります。
Blazor WebAssembly は SEO に適していますか?
はい、ただし、空のシェルを出荷して、クローラーが待機することを期待するわけではありません。パブリック ページには、最初の応答前または応答中に、レンダリングされた HTML、メタデータ、正規リンク、および構造化データが必要です。
多言語の Blazor リンクはどのように構築する必要がありますか?
中央のルート定義を使用し、各カルチャの実際のアンカー タグをレンダリングします。表示されるリンク、正規 URL、hreflang データを常に揃えて、ユーザーとクローラーが同じ言語構造を参照できるようにします。