数あるフロントエンドフレームワークの中でBlazor WebAssemblyを選択する理由
先日の.NET Conf 2022 Recap EventでフロンドエンドフレームワークにはReactやVueなど様々なフレームワークがある中であえてBlazor WebAssemblyを選択する理由は何ですかというような質問がありました。
それに自分なりの回答を考えてみた。
もちろん、回答に合ったようにチームのスキルベースとしてC#とかBlazorのスキルを持っていてJavaScriptのそれよりも上であるためにBlazor WebAssemblyを選択するというのも一つの答えだろう。
私からの回答として2つ上げておきたい。
1つは、Blazor WebAssemblyテンプレートにあるASP.NET Core Hostedのオプションの存在である。
これを指定した場合、通常のClientプロジェクトに加え、ServerプロジェクトとSharedプロジェクトが作られる。
ClientプロジェクトはBlazor WebAssemblyのプロジェクトなので説明不要と思われる。
ServerプロジェクトはASP.NET Core Web APIプロジェクトとして作成される。
そして、Sharedプロジェクトは両者の共通オブジェクト定義のプロジェクトである。わかりやすくいうとWebAPIでやりとりするJSONの型定義がここでしておき、Clientプロジェクト、Serverプロジェクト双方から参照されているので、Clientプロジェクトではデシリアライズ時の型指定を、Serverプロジェクトではシリアライズの型定義をSharedプロジェクトのクラスを使ってあげることで、OpenAPIでありがちなサーバ側とクライアント側での定義が違うためにうまくいないということが発生しにくくなるというメリットがあります。
2つめに、クライアント側、サーバ側双方ともにC#とすることができるので、昼間に紹介されていたMessagePackなどの高速シリアライザーを採用することができます。
同じ言語が動作する環境であるのでオーバヘッドの大きいテキストシリアライザーに縛られる必要もないわけです。
Blazor WebAssembly ASP.NET Core HostedなプロジェクトでMessagePackを入れてみる
通常、SPAなWebシステムのバックエンドとフロントエンドのやりとりはWebAPIを介して行われるのが通常である。
すなわち、バックエンドとフロントエンドとのやりとりはJSONあるいはXMLのテキストをHTTPでやりとりする。
しかしながら、C#の世界には非常に高速なシリアライザであるMessagePack for C#というものが存在する。
クライアント・サーバともにC#である場合にはとても有用な選択肢である。そして、ASP.NET Core Web API + Blazor WebAssemblyのシステムもそれの適用範囲といえる。
シリアライズ・デシリアライズよりも遙かに遅いデータベースとかネットワークとかいうものも存在するがここは余り考えないことにしてこれを置き換えることでどれだけ体験が良くなるか試すこととした。
まずは、本当に動くかどうか？というわけで基本のテンプレートで試してみる。
MessagePackおよびMessagePackAnalyzerをClient、Server、Sharedの各プロジェクトにNugetしておく。
まず、SharedプロジェクトにあるWeatherForcastクラスに属性をつけます。
コントローラを以下のように変更します。
最後に、画面側を以下のようにしました。
Try-catchはデバッグ用に入れたもので例外を握りつぶしてしまってるので外した方がよいでしょう。
これでいつものように見慣れた画面が見えました。
DevToolsを開いてネットワークを確認してみるとWeatherForcastにアクセスしていることが分かります。そして、バイナリデータで送られてきているようです。
このことから、JSONではなくMessagePackに動作が切り替わって動作していると分かると思います。
.NET ラボ勉強会2023年1月の登壇にてMessagePackにしてパフォーマンス面でどうであったかしゃべりたいと思います。
新しいMicrosoft Learn
いままで、docs.microsoft.comとして存在していたいわゆるテクニカルドキュメントやMicrosoft Learnなどが存在していたサイトが新しく生まれ変わりlearn.microsoft.comとなりました。
従来のURLにリンクしていたものは自動的にリダイレクトされるようです。
さて、リニューアルしたからには何らかの意図がありこれを読み解かなければなりません。
URLが示すとおりlearn.microsoft.comで提供されるすべてのコンテンツはすべて学習のために存在するという意図があるようです。
- テクニカルドキュメント
- Learn
- スキルチャレンジ
- Q&A
- コードサンプル
- ショーとイベント
といったようなコンテンツがありこれらはあらゆるスキルアップの機会や組織の新たなニーズに対応するためにスキルアップする場合にでも必要なリソースを探索できるように設計されているとされています。
つまり、いままで学習コンテンツといえば今まではいわゆるMicrosoft LearnのコンテンツやAZシリーズなどの認定資格のコンテンツのことと思ってきました。
しかし、これからはMicrosoftとしてはテクニカルドキュメントを含むlearn.microsoft.com配下すべてのコンテンツが学習コンテンツだという位置づけだという解釈となります。
確かに、指摘されてみればテクニカルドキュメントだとかAPIリファレンスなどから学ぶことは少なくありません。振り返ってみれば最大の言語・コンピュータの学習リソースはリファレンスマニュアルと呼ばれるものでした。
リファレンスマニュアルに記述されていることをもとに実機で仮説検証から実証していくことも少なくありません。ということで今回の改訂については数日たって大いに納得しつつあります。
願わくば、いわゆるテクニカルドキュメントの部分とLearnコンテンツの結びつきをもっと強化して欲しいところと、今回のURLの変更の影響からか翻訳されてないドキュメントが増えているように感じてますので機械翻訳でも早急に進めてもらえると助かるなと。
Windows Updateでの.NETランタイムおよびSDKの更新について
Windows Updateによって.NET 6のランタイムおよびSDKの更新がどのような挙動となるか試してみた。
検証環境：Hyper-V上にWindows 11を新規インストール
VS Codeをインストール
.NET 6 SDK 6.0.100をインストール
この時点で、VS Codeのターミナルから.NET SDKおよび.NETランタイムのバージョンを表示させてみたところ以下の通り
当然ですが、.NET SDKが6.0.100、ランタイムが6.0.0となっています。
その後、Windows Updateを実施します。
このとき、上記のように「その他のMicrosoft 製品の更新プログラムを受け取る」をオンにしておきます。
すると、.NET Security Updateを含むアップデートが適用されます。
Windows Updateがすべて適用されたあと同様にSDKおよびランタイムバージョンの確認をしてみます。
すると、SDKバージョンは6.0.109 ランタイムバージョンは6.0.9となっています。
現時点での最新のSDKバージョンは6.0.401ですが同様に9月13日リリースバージョンとして6.0.109も並列して存在しています。
中身を見るとVisual StudioのサポートバージョンがV17.0とVS2022の初期バージョンのものになっていることから.NET6の初期バージョンに対して機能リリースが入っていない純粋なセキュリティアップデートのみのバージョンとなっているようです。
