高速Webアプリを実現する、Blazor WebAssembly
前述の通り、Blazorには、2つの動作モデルがあります。SPAを開発するという目的は共通ですが、ホスティングの形態がそれぞれ異なります。まずは、Blazor WebAssemblyを紹介します。Blazor WebAssemblyの動作モデルを図1に示します。
Blazor WebAssemblyのアプリケーションは、基本的にクライアント側でWebAssemblyという技術に基づき動作します。WebAssemblyにより、C#で記述されたクライアントサイドのためのコードをWebブラウザ上で高速に実行できます。
クライアントサイドで完結するアプリケーションを開発することもできますし、必要に応じてサーバーサイドのAPIを呼び出して利用するといったスタイルのアプリケーションの開発も可能です。クライアントサイドのみの実装なので、極論すればサーバーサイドの実装は何でもよいということです。
ただし、アプリケーション自体はサーバーにあり、クライアントサイドにおけるアプリケーションの動作にはアプリケーション以外に関連するライブラリなども必要になるので、読み込みには時間がかかるというデメリットもあります。しかし、キャッシュの働きにより時間のかかる読み込みも初回だけなので、大きな問題ではないという考え方もあります。
開発をサーバーサイドに集中できる、Blazor Server
次に、Blazor Serverを紹介します。Blazor Serverの動作モデルを図2に示します。
Blazor Serverのアプリケーションは、その名称の通り基本的にサーバー側で動作します。クライアントにおけるUIコンポーネントの操作は逐次サーバーに伝えられて、サーバー側で必要な処理を行った後のレンダリング結果に基づき、クライアントのUI(DOM)を更新します。このとき、クライアントとサーバーの間はSignalRというリアルタイム通信のためのチャネルで常時接続されていて、相互の変更をもう一方に即座に反映できるようになっています。このため、クライアントとサーバーの間には常にネットワーク接続が必要となります。
Blazor Serverでは、アプリケーションの開発をサーバーサイドに集中できるので、Entity Frameworkの利用などRazor Pagesなどの延長線上での開発が行えるというメリットがあります。また、クライアントサイドにおいてはイベントの送信やDOMの更新などの最低限のJavaScriptコードが必要となるのみなので、アプリケーションの読み込みが高速に行えるなどのメリットもあります。
ただし、前述のようにSignalRを使ってクライアントとサーバー間が常時通信を行っているので、ネットワーク環境が常に利用可能でないとならないなどの制約もあり、これがデメリットとなる場合もあります。なお、SignalRについては本連載の後続の回で紹介する予定です。
Web技術でクロスプラットフォーム開発を実現!.NET MAUI Blazor
最後に、.NET 6から提供が始まった.NET MAUI Blazorを紹介します。.NET MAUI Blazorは、.NET MAUIアプリケーションを、Blazor技術を用いて開発できるフレームワークです。.NET MAUIとは、.NET Multi-platform Application UIの略で、クロスプラットフォームにてアプリケーション開発を行うためのフレームワークです。
単一のプロジェクトで、macOS、Windows、iOS、Android OSなどのネイティブアプリケーションを生成できます。.NET MAUI Blazorは、この.NET MAUIをBlazorの技術を用いて開発できるようにしたものです。つまり、Web技術でクロスプラットフォームのアプリケーション開発が行えるようになるわけです。