皆さん、こんにちは。砂漠の果ての狼です。
Dotnet9 でオンラインの小さなツールや小ゲームを公開した後、サーバーの負荷がかなり大きくなっていると感じました。25ページを開くと、メモリ使用量は約170MB、CPUは60〜70%を維持しています。どうやらServerはこのようなインタラクションの多いプログラムには本当に向いていないようです（サーバー構成：2コア4GBメモリ）。そこでサイト運営者は急いで Blazor Wasm バージョンのサイトを公開し、皆さんが両モードの違いを直感的に比較・理解できるようにしました。以下、詳しく説明します。
1. Dotnet工具箱の公開について
今後のツールやゲームの拡張のために、サイト運営者は昨年購入したドメイン dotnetools.com を活用することにしました。このドメインは一括で10年間購入しています（サイトが数年で消える心配はありませんが、万が一、サイト運営者がサーバー更新費を払えなくなるなどの不測の事態はあります…）。そして急いで1日以内に Blazor Wasm バージョンのサイトを開発・デプロイし、Dotnet9 ですでに公開しているオンライン小ツールや小ゲームを同期して移行しました。ぜひ体験してみてください：https://dotnetools.com：
2. Dotnet工具箱サイトはオープンソースです
サイトのソースコードの構成は以下の通りで、1つのプロジェクトのみ。素早く公開するために、コードもわかりやすくなっています：
ソースコードのリンクは記事の最後にあります。もうソースコードの場所を聞かないでください…。
3. Blazor ServerがオンラインツールやゲームなどのWebアプリ開発に適さない理由
Blazor ServerがオンラインツールやゲームなどのWebアプリ開発に適さないのは、主にその動作原理と特性による制限や不適合があるためです。
リアルタイム性の制限：Blazor ServerはSignalR技術を使用してサーバーとのリアルタイム通信を実現しますが、すべてのUI更新はサーバーを介して行われるため、ネットワーク遅延が大きい場合、ユーザーは顕著な遅延を感じる可能性があります。これはオンラインツールやゲームなど、リアルタイム応答が必要なアプリでは許容できません。
サーバーリソースの消費：Blazor Serverの動作原理は、アプリ全体をサーバーにデプロイし、各ユーザーが接続と一部のサーバーリソースを占有することです。オンラインツールやゲームなど、多数のユーザーが同時に接続するアプリでは、サーバーリソースの消費が大きくなり、スケーリングやメンテナンスが困難になる可能性があります。
クライアントのパフォーマンス制限：Blazor ServerではUIレンダリングがサーバー側で行われ、更新されたUIがSignalRを介してクライアントにプッシュされます。そのため、クライアントのパフォーマンスがアプリの応答速度やユーザー体験に大きく影響します。複雑なオンラインツールやゲームでは、クライアントのパフォーマンスが要件を満たせない可能性があります。
以上の理由から、Blazor Serverはリアルタイム性の要求が低く、ユーザー数が少なく、サーバーリソースの消費が少ないWebアプリに適しています。オンラインツールやゲームなど、リアルタイム性と多数のユーザー同時接続が必要なアプリには、Blazor WebAssemblyの方が適しています。アプリ全体をクライアントにデプロイできるため、サーバーの負荷を軽減し、より良いユーザー体験を提供できます。
4. Blazor Wasmをツールサイトに選んだ理由
Dotnet9 サイトは引き続きBlazor Serverを採用します。ブログ系サイトではSEOが必要であり、検索エンジンからのトラフィックが必要だからです。
一方、Dotnet工具箱 は主にオンラインの小ツールや小ゲームに焦点を当てているため、Blazor Wasmを選択しました。Blazor WebAssemblyを選ぶ際のメリットとしては、以下のようなエキサイティングな利点が挙げられます：
即時パフォーマンス：Blazor WebAssemblyはWebAssembly（Wasm）技術を利用し、C#コードを効率的なバイナリ形式にコンパイルしてブラウザ上で直接実行できます。つまり、C#で記述したアプリケーションをJavaScriptに変換せずにクライアント側で実行できます。この直接実行能力により、Blazor WebAssemblyはネイティブアプリケーションに近いパフォーマンスを実現し、より速い読み込み速度とスムーズなユーザー体験を提供します。
クロスプラットフォーム：Blazor WebAssemblyはクロスプラットフォームのソリューションであり、Windows、Mac、Linux、モバイルデバイスを含む様々なOSやデバイスで動作します。つまり、同じコードベースを使用して異なるプラットフォーム向けのアプリケーションを構築でき、開発とメンテナンスの作業量を削減できます。
開発効率：Blazor WebAssemblyはC#言語と.NETフレームワークを使用しており、これらは広く使われている開発ツールとエコシステムです。もしすでにC#と.NETに精通していれば、新しい言語やフレームワークを学ぶことなく、すぐにBlazor WebAssemblyを使った開発を開始できます。この開発効率はプロジェクトの開発速度を大幅に加速し、開発者の学習曲線を短縮します。
強力なエコシステム：Blazor WebAssemblyは.NETエコシステムに基づいて構築されているため、.NETの豊富な機能とサードパーティ製ライブラリを活用して強力なアプリケーションを構築できます。Entity Framework、ASP.NET Coreなど、.NETの様々なツールや技術を使用して開発プロセスを簡素化し、アプリケーションの品質と保守性を向上させることができます。
セキュリティ：Blazor WebAssemblyアプリケーションはクライアント側で実行されますが、サンドボックス環境で実行されるため、ネイティブアプリケーションと比較して高いセキュリティを備えています。これにより、セキュリティ上の懸念なくクライアント側で機密性の高い操作を実行できます。また、C#でコードを記述するため、.NETのセキュリティ機能を利用して一般的なセキュリティ脆弱性や攻撃からアプリケーションを保護できます。
以上のように、Blazor WebAssemblyは即時パフォーマンス、クロスプラットフォーム、開発効率、強力なエコシステム、セキュリティなどのエキサイティングな利点を持っています。これらの利点により、Blazor WebAssemblyは魅力的な技術選択肢となり、開発者に高性能でクロスプラットフォームなWebアプリケーションを構築する新しい方法を提供します。
重要: WASMこそがBlazorの未来です。
5. Blazor ServerとBlazor Wasmの詳細比較
Dotnet9 サイトはBlazor Serverを採用しており、オンラインツールやオンラインゲームのページでServerを体験できます。例えば マインスイーパーゲーム 。ゲームページからは Dotnet工具箱 の マインスイーパーゲーム ページにもジャンプできます。こちらはWasmバージョンです。ブラウザのF12で開発者ツールを開き、ネットワークリクエストの状況を確認できます。以下、簡単に確認手順を説明します。
Dotnet9 の マインスイーパーゲーム ページでは、ツールバーをクリックして Dotnet工具箱 の マインスイーパーゲーム ページに移動できます：
Dotnet9 の マインスイーパーゲーム ページのネットワークリクエストを見ると、ほぼ常にリクエストが発生しており、驚くべきもので、異常です：
Dotnet工具箱 の マインスイーパーゲーム ページのネットワークリクエストを見ると、画像リクエストだけで、それ以外のリクエストはありません。これがクライアントサイドの魅力です（WebAssembly）：
Blazor、あるいはBlazor ServerとBlazor Wasmについて、多くの人は聞いたことがあるだけで、関連する概念についてあまり知らないかもしれません。ここではGPTに質問して回答を得ました。前述の段落と似ていますが、ここで比較して簡単に紹介します：
BlazorはWebアプリケーションを構築するためのオープンソースフレームワークで、C#と.NETを使用してクライアントコードを記述できます。Blazorには2つのモードがあります：Blazor ServerとBlazor WebAssembly（Wasm）。以下、これらのモードの詳細な比較です：
アーキテクチャ：
- Blazor Server：Blazor Serverモードでは、アプリケーションのUIレンダリングがサーバー上で行われ、SignalRを介してUI更新がクライアントにプッシュされます。クライアントはサーバーとの永続的な接続を確立してUI更新を受信し、ユーザー操作を処理します。
- Blazor WebAssembly：Blazor Wasmモードでは、アプリケーションのコードと依存関係がWebAssembly形式にコンパイルされ、クライアント上で実行されます。アプリケーションはクライアント上で独立して実行され、サーバーとの永続的な接続を維持する必要はありません。
パフォーマンス：
- Blazor Server：Blazor Serverモードのパフォーマンスはサーバーとネットワークの影響を受けます。UIレンダリングがサーバー上で行われるため、大規模アプリケーションや高負荷シナリオではサーバーに大きな負荷がかかる可能性があります。
- Blazor WebAssembly：Blazor Wasmモードのパフォーマンスは主にクライアントデバイスの影響を受けます。アプリケーションがクライアント上で実行されるため、より良い応答速度と低遅延を実現できます。
信頼性：
- Blazor Server：Blazor Serverモードはサーバーの安定性と可用性に依存します。サーバーに障害が発生したりネットワーク接続が切断されたりすると、アプリケーションは正常に動作しなくなります。
- Blazor WebAssembly：Blazor Wasmモードはクライアント上で独立して実行されるため、サーバーの安定性や可用性に依存しません。サーバーが利用できなくなっても、アプリケーションは引き続き動作できます。
開発体験：
- Blazor Server：Blazor Serverモードの開発体験は従来のサーバーサイド開発に似ており、.NETの完全な機能とエコシステムを活用できます。ただし、UIレンダリングがサーバー上で行われるため、ユーザー操作を処理する際にはサーバーとの通信遅延を考慮する必要があります。
- Blazor WebAssembly：Blazor Wasmモードの開発体験はクライアント開発に似ており、C#と.NETのほとんどの機能を使用できますが、一部の機能は制限される場合があります。アプリケーションがクライアント上で実行されるため、よりネイティブアプリケーションに近いユーザー体験を提供できます。
全体として、Blazor Serverは迅速な開発とデプロイが必要なアプリケーションに適しており、Blazor WebAssemblyはより良いパフォーマンスと独立した動作が必要なアプリケーションに適しています。どちらのモードを選択するかは、アプリケーションの要件と優先順位によります。
6. 最後に
以前の2つの記事で、一部のネットユーザーからサイト運営者にWasmモードを使用することを提案する声がありました。サイト運営者はすでに正常にデプロイして公開しています。皆さんがどんなツールを必要としているか、ぜひコメントで教えてください。サイト運営者は時間があれば追加を検討します。もちろん、ツールやゲームのPRを歓迎しますが、Blazor WASMで開発されたものに限ります。
今日の共有はここまでです。読んでいただき、誠にありがとうございます。
- サイトアドレス：https://dotnetools.com/
- サイトソースコード：https://github.com/dotnet9/Dotnet9
- .NETバージョン： .NET 8.0.0-preview.5.23280.8
- WeChat技術グループ：サイト運営者のWeChat（codewf）を追加し、必ず【入群】の2文字を備考に記入してください
- QQ技術グループ：771992300