Blazor アプリのホスティング モデル

ヒント

このコンテンツは電子ブック、Azure の「ASP.NET Web Forms 開発者向け Blazor」からの抜粋です。これは .NET Docs から閲覧するか、オフラインで読める無料ダウンロードの PDF としても入手できます。

Blazor-for-ASP-NET-Web-Forms-Developers eBook cover thumbnail.

Blazor アプリは、次のいずれかの方法でホストできます。

  • WebAssembly でのブラウザーのクライアント側。
  • ASP.NET Core アプリでのサーバー側。

BlazorWebAssembly アプリ

BlazorWebAssembly アプリは、ブラウザーで、WebAssembly ベースの .NET ランタイム上で直接実行されます。 BlazorWebAssembly アプリは、Angular や React などのフロントエンド JavaScript フレームワークと同様の方法で機能します。 ただし、JavaScript を記述するのではなく、C# を記述します。 .NET ランタイムは、アプリ アセンブリおよび必要な依存関係と共に、アプリと共にダウンロードされます。 ブラウザーのプラグインや拡張機能は必要ありません。

ダウンロードされたアセンブリは、他の .NET アプリで使用するのと同じような、通常の .NET アセンブリです。 ランタイムでは .NET Standard がサポートされているため、BlazorWebAssembly アプリで既存の .NET Standard ライブラリを使用できます。 ただし、これらのアセンブリは引き続きブラウザーのセキュリティ サンドボックスで実行されます。 一部の機能では、PlatformNotSupportedException がスローされる場合があります。たとえば、ファイル システムにアクセスしようとしたり、任意のネットワーク接続を開いたりする場合です。

アプリが読み込まれると、.NET ランタイムが開始され、アプリ アセンブリで参照されます。 アプリのスタートアップ ロジックが実行され、ルート コンポーネントがレンダリングされます。 Blazor によって、コンポーネントからレンダリングされた出力に基づき、UI の更新が計算されます。 その後、DOM の更新が適用されます。

Blazor WebAssembly

BlazorWebAssembly アプリは、純粋にクライアント側で実行されます。 このようなアプリは、GitHub Pages や Azure の静的 Web サイト ホスティングなどの静的サイト ホスティング ソリューションに配置できます。 サーバー上では、.NET はまったく必要ありません。 通常、アプリの一部に対するディープ リンクの設定には、サーバー上のルーティング ソリューションが必要です。 そのルーティング ソリューションによって、アプリのルートに要求がリダイレクトされます。 たとえば、このリダイレクトは、IIS の URL 書き換え規則を使用して処理できます。

Blazor とフルスタック .NET Web 開発のすべての利点を得るには、ASP.NET Core で BlazorWebAssembly アプリをホストします。 クライアントとサーバーの両方で .NET を使用することにより、コードを簡単に共有し、言語、フレームワーク、ツールの 1 つの一貫したセットを使用してアプリを構築できます。 Blazor には、BlazorWebAssembly アプリと ASP.NET Core ホスト プロジェクトの両方を含むソリューションを設定するための便利なテンプレートが用意されています。 ソリューションをビルドすると、Blazor アプリからビルドされた静的ファイルは、フォールバック ルーティングが既に設定された状態で ASP.NET Core アプリによってホストされます。

Blazor Server アプリ

Blazor アーキテクチャに関する議論から、Blazor コンポーネントによってその出力が RenderTree と呼ばれる中間的な抽象化にレンダリングされることを思い出してください。 次に、Blazor フレームワークによって、レンダリングされたものと以前にレンダリングされたものが比較されます。 その相違点は DOM に適用されます。 Blazor コンポーネントは、そのレンダリングされた出力の適用方法からは切り離されます。 そのため、コンポーネント自体は、UI を更新するプロセスと同じプロセスで実行する必要はありません。 それどころか、同じコンピューター上で実行する必要もありません。

Blazor Server アプリでは、コンポーネントはクライアント側のブラウザーではなく、サーバー上で実行されます。 ブラウザー内で発生した UI イベントは、リアルタイム接続を介してサーバーに送信されます。 イベントは、正しいコンポーネント インスタンスにディスパッチされます。 コンポーネントはレンダリングされ、計算された UI の差分がシリアル化されてブラウザーに送信され、そこで DOM に適用されます。

Blazor Server

ASP.NET AJAX と UpdatePanel コントロールを使用したことがある場合、Blazor Server のホスティング モデルにはなじみがあるかもしれません。 UpdatePanel コントロールにより、ページ上のイベントのトリガーに応じて、部分ページ更新の適用が処理されます。 トリガーされると、UpdatePanel によって部分的な更新が要求され、ページを更新する必要なくそれが適用されます。 UI の状態は、ViewState を使用して管理されます。 Blazor Server アプリは、アプリがクライアントとのアクティブな接続を必要とするという点で若干異なります。 また、すべての UI の状態がサーバー上で保持されます。 これらの違いを除けば、2 つのモデルは概念的に似ています。

適切な Blazor ホスティング モデルを選択する方法

Blazor ホスティング モデルに関するドキュメントで説明されているように、異なる Blazor ホスティング モデルには異なるトレードオフがあります。

BlazorWebAssembly ホスティング モデルには、次の利点があります。

  • .NET サーバー側の依存関係がありません。 アプリはクライアントにダウンロードされた後、完全に機能します。
  • クライアントのリソースと機能が完全に活用されます。
  • 作業がサーバーからクライアントにオフロードされます。
  • アプリをホストするために ASP.NET Core Web サーバーが必要ありません。 サーバーレスの展開シナリオが可能です (たとえば、CDN からアプリを提供するなど)。

BlazorWebAssembly ホスティング モデルの欠点は次のとおりです。

  • ブラウザーの機能によってアプリが制限されます。
  • サポートされているクライアント ハードウェアおよびソフトウェア (たとえば、WebAssembly サポート) が必要です。
  • ダウンロード サイズが大きくなり、アプリの読み込みに時間がかかります。
  • .NET ランタイムとツールのサポートが十分ではありません。 たとえば、.NET Standard のサポートとデバッグには制限があります。

逆に、Blazor Server ホスティング モデルには、次のような利点があります。

  • ダウンロード サイズがクライアント側アプリよりもかなり小さく、アプリの読み込み時間が大幅に短縮されます。
  • このアプリでは、.NET と互換性のあるすべての API の使用を含め、サーバーの機能を最大限に活用できます。
  • サーバー上の .NET はアプリの実行に使用されるため、デバッグなどの既存の .NET ツールは想定どおりに動作します。
  • シン クライアントがサポートされています。 たとえば、サーバー側アプリは、WebAssembly がサポートされていないブラウザーや、リソースが制限されたデバイスで動作します。
  • アプリのコンポーネント コードを含め、アプリの .NET/C# コード ベースがクライアントに提供されません。

Blazor Server ホスティング モデルの欠点は次のとおりです。

  • UI の待機時間が長くなります。 すべてのユーザーの操作にネットワーク ホップが関与します。
  • オフライン サポートがありません。 クライアント接続が失敗すると、アプリの動作が停止します。
  • 多くのユーザーがいるアプリで、スケーラビリティが課題になります。 サーバーでは、複数のクライアント接続を管理し、クライアントの状態を処理する必要があります。
  • アプリを提供するのに ASP.NET Core サーバーが必要です。 サーバーレスの展開シナリオは利用できません。 たとえば、CDN からアプリを提供することはできません。

上記のトレードオフの一覧は厄介かもしれませんが、使用するホスティング モデルは後で変更できます。 選択した Blazor ホスティング モデルに関係なく、コンポーネント モデルは "同じ" です。 原則として、いずれのホスティング モデルでも同じコンポーネントを使用できます。 アプリのコードは変わりません。ただし、コンポーネントがホスティング モデルに依存しない状態を維持するために、抽象化を導入することをお勧めします。 この抽象化により、アプリで別のホスティング モデルをより簡単に導入できるようになります。

アプリのデプロイ

ASP.NET Web Forms アプリは、通常、Windows Server コンピューターまたはクラスター上の IIS でホストされます。 Blazor アプリでは、以下を行うこともできます。

  • 静的ファイルまたは ASP.NET Core アプリとして、IIS でホストする。
  • ASP.NET Core の柔軟性を活用して、さまざまなプラットフォームやサーバー インフラストラクチャ上でホストする。 たとえば、Linux で Nginx または Apache を使用して Blazor アプリをホストできます。 Blazor アプリを発行および展開する方法の詳細については、Blazor のホスティングと展開に関するドキュメントを参照してください。

次のセクションでは、BlazorWebAssembly および Blazor Server アプリのプロジェクトの設定方法について説明します。