筆者のウェブサイトに対する認識は、フロントエンド、バックエンド、データベースです。ユーザーがブラウザのページでボタンを押したり、フォームを送信したりすると、フロントエンドのイベントがトリガーされ、収集された条件をバックエンドに送信します。バックエンドは条件を受け取り、データベースで処理・判断を行い、ユーザーが求めるデータを取得した後、ページとデータをフロントエンドに返し、フロントエンドは対応するデータをページに表示します。これが最も原始的なフロントエンドとバックエンドのやり取りです。
その後、ページを毎回リフレッシュするのが面倒だという声から、非同期で実行できるAjax技術が発展しました。あるイベントAが完了していなくても、他のイベントB、CはAの完了を待たずに自身の処理を進めます。これにより、ユーザーがフォームを送信した際に、ページがぐるぐる回ってリフレッシュを待つことなく、ユーザーは先にページを見ることができ、他の処理はユーザーの見えないところで続行されます。これによりユーザー体験が大幅に向上しました。
動的ウェブページの仕様はJSに統一され、後に強い型付けのTypeScript（Angular、React、Vueなどのフロントエンドフレームワークで使用される言語）が登場しても、最終的にはブラウザが認識するJSにコンパイルする必要があり、TypeScriptもJSに基づいています。そのため、バックエンドエンジニアが自分でウェブサイトを作成する場合、避けられずにJSと付き合わなければならず、強い型付けに慣れている人にとっては、新しい開拓を余儀なくされます。会社の規律が緩く、任意の型を好む同僚がいる場合、変数がnumberとして使われたり、次にstringとして使われたりすることがあり、気が狂いそうになります。そんな中、幸いにもBlazorが登場しました。
BlazorはBrowserとRazorの合成語で、ブラウザ上で実行されるRazorコンポーネントを意味します。
Blazorには2つのモードがあります。WebAssembly HostingとServer Hostingです。簡単に言えば、Client sideとServer sideです。それぞれに長所と短所があります。ただし、続ける前にWebAssemblyとは何かを説明する必要があります。
WebAssembly（略称Wasm）は、バイナリ表現言語です。任意のプログラミング言語を特定のコンパイルを通じてWasmに変換できます。Wasmの利点は、プログラム全体をサーバー不要でブラウザに転送できることです。バイナリであり既にコンパイルされているため、JSよりも高速にページをレンダリングでき、ファイルサイズも小さくなります。
Blazor WebAssemblyは、コンパイルされたdllファイルと.NETランタイムをまとめてユーザーのブラウザに送信するため、最初の接続時に時間がかかります。Blazor Serverは、サーバーとブラウザの間にSignalR接続を確立します。ブラウザでイベントがトリガーされると、サーバーが処理後にページ全体をリフレッシュ（すべてのHTML要素をフロントエンドに送信）するのではなく、SignalRを介して変更された要素（例：div）のみをブラウザに送信します。これは、BlazorもAngularと同様にSPA（Single Page Application）モードを使用しており、最初から最後まで1つのページしかなく、その上に異なる機能のコンポーネントが配置されており、イベントがトリガーされると関連コンポーネントのみが更新されるためです。
Blazor WebAssembly
利点：
- ファイルがブラウザ上にあるため、Blazor Serverよりも高速。
- サーバーが不要。
- 常にサーバーと接続する必要がない。
- クライアント側のブラウザが十分に活用され、サーバーの負荷が軽減される。
- 任意のサーバー（クラウド、Microsoft Azure、さらにはCDN（Content Delivery Network、データをユーザーの地理的に近い場所に一時的に保存する仕組み。例えば、米国にあるサーバーのウェブサイトにログインする場合、台湾にあるサーバーのウェブサイトよりも速度が遅くなるが、CDNは台湾に近い地域（香港やシンガポールなど）のサーバーにデータを一時保存し、ユーザーの接続速度を向上させる））にホスティングできる。
欠点：
- 初回読み込みに時間がかかる（ブラウザが.NETランタイムなどのコンポーネントをダウンロードするため）。注：アイアンマン大会の前に筆者が新しいBlazor WebAssemblyプロジェクトを作成したところ、コンポーネントのダウンロードは行われていませんでした。Microsoft公式の画像にもダウンロードの表示はありませんでした。新しいバージョンで変更された可能性があります。
- ブラウザの処理能力に制限される。
- クライアント側のソフトウェアとハードウェアの両方が重要。
Blazor Server
利点：
- 読み込み速度が速い。
- サーバーの能力を最大限に活用できる。
- 任意のクライアントでこのソフトウェアを使用するために必要なのはブラウザのみ。
- ソースコードがクライアント側に転送されないため、より安全。
欠点：
- サーバーが必要。
- サーバーとの接続を維持する必要がある。
- データの往復により、遅延感が強くなる。
- 演算能力の向上が難しい。1つのサーバーが処理できるクライアント数には限りがあるため。Microsoftのデータによれば、シングルコアで3.5GBメモリのBlazor Serverは5000接続、4コアで14GBメモリのBlazor Serverは20000接続を処理できる。
Blazor WebAssemblyとBlazor Serverの長所と短所を列挙すると、どちらのモードも完璧ではなく、最適なものだけが存在することがわかります。もし既にPHP、Node、Railsなどの他のプログラミング言語のサーバーがあり、常にサーバーと接続する必要がないクライアント側プログラムをユーザーに提供したい場合、Blazor WebAssemblyは良い選択です。また、Blazor WebAssemblyはPWA（Progressive Web App）機能を備えており、ウェブサイトとして開発されていながら、ユーザーがソフトウェアをダウンロードするようにデスクトップやスマートフォンにダウンロードできます。有名な例として、Twitter、Pinterest、Starbucksが挙げられます。PCでTwitterのウェブサイトを開くと、URLバーの右端にダウンロードボタンが表示されます。一方、サーバーとの頻繁な接続が必要な（例えばデータの追加、変更、削除など）ウェブサイトをゼロから生成する場合には、Blazor Serverが適しています。
ただし、BlazorはMicrosoftの新製品であり、筆者もASP.NET CoreとBlazorを組み合わせて使用したことしかありません。Blazor WebAssemblyをPHPなどの非Microsoft言語で開発されたバックエンドと統合する場合、注意すべき点があるかもしれません。関連するニーズがある場合は、多方面から検討する必要があります。
長々と説明しましたが、筆者が初めて触れたときと同じように、まだ理解できない方も多いでしょう。明日は両方のプロジェクトを作成し、どのような違いがあるかを見ていただきます。
- 引用: What is Blazor
- 引用: ASP NET Core blazor hosting models
- 引用: The Differences Between Blazor WebAssembly And Blazor Server
- 引用: 了解 WebAssembly 的基础使用方法
- 引用: WebAssembly design
- 引用: WHAT IS A CDN & WHERE DOES IT SHINE?
- 引用: Twitter
注：本記事のコードは .NET 6 + Visual Studio 2022 でリファクタリングされています。元の記事のリンクをクリックしてリファクタリング後のコードと比較学習できます。ご覧いただきありがとうございます。原作者をサポートします。
- 本記事のMarkdown：クリックして閲覧