選定基準
選定基準は、チームの技術スタックにほぼ100%依存します。
もし、あなたのチームの技術スタックが、、
-
Asp.Net系のみ => Blazorを選択してください
単純に学習コストの問題です。JavaScript(TypeScript)のSyntaxに慣れるのがかなり大変なようです。また、使い慣れたVisual Studioで開発できるというのもポイントです。
ただし、状況によってはJavaScriptで補完する箇所も出てくるので、バランス感覚が重要です。
調査は骨が折れます。最近のUpdateにエコシステムがついてこれていないように見えます。
-
JavaScript系のみ => JavaScriptを選択してください
Browser上で、Blazorでできないことがあっても、JavaScriptでできないことはないからです。
例えば、モーダルコンポーネントで背面のスクロールを無効にしたい場合、Blazorでは、
bodyエレメントを直接操作できず、JavaScript経由で操作することになります。また、文献含むエコシステムが圧倒的に多いです。だいたい同じ悩みを持った人を見つけることができます。
-
どちらも持っている => JavaScriptを選択してください
エコシステムが圧倒的だからです。メンバーも採用しやすいです。
-
どちらも持っていない => JavaScriptを選択してください
学習コストはかかる前提で、Asp.Netよりは低いと思います。私の好みもありますが、Asp.Netのドキュメントは中々頭に入ってきません。
豊富なエコシステムにより、チュートリアル関連も多いです。
if( Asp.Net && !JavaScript ) decide(Blazor) else decide(JavaScript)ですね。
Blazorを選択した場合、以下に記載の特徴をしっかりと理解しておく必要があります。
私はNext.Jsを主に扱っているのですが、Next.JsのSSR(Server Component)とは全く異なるもので、これらの特徴を理解するのに骨が折れました。
Blazorの特徴
Render mode
BlazorはComponentごとにRendering modeを持つことができ、それぞれ以下のようになっています。特に、Interactive Serverは、デプロイ環境の選定にまで影響します。
-
Static Server
静的なComponentで、
razorファイル内の@code内で設定したボタンクリックイベント等は無効になります。コンパイルエラーにはなりませんが、Browserでページを表示してボタンを押下しても何も反応しません。
ただし、<script></script>で作成したJavaScriptをコールすることは可能です。単純にHtml + JavaScriptの組み合わせでロードされるので当然といえば当然ですね。Formイベントにも対応しており、
EditFormを用いたバリデーション、Submitは可能となっています。明示的に指定しない限り、
Static ServerがデフォルトのRender modeになります。
-
Interactive Server
Dynamic Serverではないことをよく注意してください。従来のSSRのような、ページリクエストに応じて動的にページを生成するものではありません。
このモードで動くComponentは、BrowserサイドからHtmlイベントの通知を受け取り、ServerサイドでUIをレンダリングして、差分更新をBrowserに通知し、それをBrowserが再描画します。
つまり、ServerサイドはStatefullで、相互的な通信を許可する状態でなければいけません。Blazorでは、
SignalRというWebSocketベースのプロトコルで相互通信を実現します。ということは、デプロイ環境でロードバランサーを使うときは、
Stickey Sessionが必須です。更に、ServerサイドもAWS Fargateなどのサーバーレスではダメで、Stateを維持できるServerを配置することが必要になります。ちなみに、ServerサイドのStateは
Circuitと呼ばれ、チュートリアルプログラムレベルでも、1Circuitで400KBほどメモリを占有するらしいです。
Circuitは、Browserのタブごとに生成されるので、例えば、私が5タブで同じアプリケーションを開いていても、5Circuitがしっかり消費されます。
-
Interactive WebAssembly
WebAssemblyを利用したBrowserサイドでの描画になります。Browserでイベント処理が行われ、描画がおこなわれます。一般的なCSRです。
Interactive Serverが特徴的過ぎですね。
-
Interactive Auto
これは、Interactive ServerとInteractive WebAssemblyを自動で設定するもので、状況に応じて選択されます。初回リクエストでは、
Interactive Serverとしてレンダリングが行われますが、2回目以降は、Interactive WebAssemblyとして動作します。これは、キャッシュやBrowserへのRuntime到着などにより左右されます。これも
Interactive Serverが関わってくるので、上述したデプロイ環境の制約を受けてしまいます。
PrerenderingとLifecycleイベント
ここもNext.Js脳では全く理解できなかったところなので、ご紹介します
razorコンポーネントは、レンダリングの度にLifecycleメソッドと呼ばれる様々な一連の処理がServerサイドで走ります。この処理は、Prerenderフェーズでも実行されます。
なんと、Static ServerやInteractive WebAssemblyといったServerサイドが全く関係なさそうなRender Modeでも実行されます。
ちなみに、以下のように記載するとPrerenderを抑制することができます。
@page "/"
@rendermode @(new InteractiveWebAssemblyRenderMode(prerender: false))
<div>Component</div>
@code {}
最後に
Blazorでも、ReactでいうProviderや、Next.jsのLayout、Reduxのような状態管理の仕組みは存在しており、FWの機能を使って便利なことができる点は良いと思います。
Microsoftが激押ししているのも納得のフレームワークですね。
もし時間的な余裕があるのであれば、POCでしっかりめのアプリケーションをBlazorで作ってみることをお勧めします。
※これはAsp.Net Core 8.0時の記事です。