参考記事
Blazorとは
- 様々な方法でホストできるWeb UIコンポーネント(Razorコンポーネント)を構築するためのWebフレームワーク
- Razorコンポーネントはサーバー側ではASP.NET Coreで実行できるのに対し、クライアント側ではWebAssemblyベースの.NETランタイム上のブラウザ(Blazor WebAssembly、Blazor WASM)で実行できる
- ネイティブモバイルアプリやデスクトップアプリでRazorコンポーネントをホストすることもでき、ホスティングモデルが何であっても、Razorコンポーネントを構築する方法は同じ(ソースの流用が可能)
- WebAssemblyはJavaScriptとは異なり、CPU上でネイティブに近い速度で実行されるコンパイル済みソフトウェア
Blazor Server
- Blazor Serverホスティングモデルを使用すると、コンポーネントはASP.NET Coreアプリ内からサーバー上で実行される。
- UIの更新、イベント処理、JavaScriptの呼びだしは、WebSocketプロトコルを使用して、SignalR接続経由で処理される
- Blazor Serverホスティングモデルの利点
- ダウンロードサイズがBlazor WebAssemblyホスティングモデルの使用時よりも小さく、アプリの読み込み時間が大幅に短縮される
- このアプリでは、.NET Core APIの使用を含め、サーバーの機能を最大限に活用できる
- サーバー上の.NET Coreはアプリの実行に使用されるため、デバッグなどの既存の.NETツールは規定どおりに動作する
- シンクライアントシステムがサポートされている。たとえば、Blazor Serverは、WebAssemblyがサポートされていないブラウザやリソースが制限されたデバイスで動作
- アプリのコンポーネントコードを含め、アプリの.NET/C# コードベースがクライアントに提供されない
- Blazor Serverホスティングモデルの制限
- 遅延時間が長くなる。すべてのユーザーの操作にネットワークホップが関与する
- オフラインサポートがない。クライアント接続が失敗した場合、対話機能は失敗する
- 多くのユーザーがアプリを拡張するには、複数のクライアント接続とクライアントの状態を処理するためのサーバーリソースが必要
Blazor WebAssembly
- Blazor WebAssemblyホスティングモデルは、クライアント側のWebAssemblyベースの.NETランタイム上のブラウザでコンポーネントを実行する
- Razorコンポーネント、その依存関係、.NETランタイムは、ブラウザにダウンロードされる。
- コンポーネントはブラウザUIスレッド上で直接実行される
- UIの更新とイベントの処理は、同じプロセス内で行われる。
- リソースは、静的コンテンツをクライアントに提供できるWebサーバーまたはサービスに静的ファイルとしてデプロイされる
- ホストされたクライアントアプリは、Web API、gRPC-web、SignalRなどのさまざまなメッセージングフレームワークとプロトコルを経由して、ネットワーク経由でバックエンドサーバーアプリとやり取りできる
- Blazor WebAssemblyホスティングモデルの利点
- スタンドアロンBlazor WebAssemblyアプリの場合、アプリがサーバーからダウンロードされた後、.NETサーバー側の依存関係がないため、サーバーがオフラインになった場合でも、アプリの機能が存続する
- クライアントのリソースと機能が完全に活用される
- 作業がサーバーからクライアントにオフロードされる
- スタンドアロンBlazor WebAssemblyアプリの場合、アプリをホストするためにASP.NET Core Webサーバーが必要ない
- Content Delivery Network(CDN)からアプリを提供するなどのサーバーレス展開シナリオが可能
- Blazor WebAssemblyの制限
- Razorコンポーネントがブラウザの機能に制限される
- サポートされているクライアントハードウェアおよびソフトウェアが必要
- ダウンロードサイズが大きくなり、コンポーネントの読み込みにかかる時間が長くなる
- クライアントに送信されるコードを、ユーザーによる検査や改ざんから保護することはできない
- Blazorでは、Ahead-Of-Time(AOT)コンパイルがサポートされており、.NETのコードをWebAssemblyに直接コンパイルできる