フロントエンドからバックエンドまでC#を使いたい

.NET 5 では、コアモジュールのパフォーマンス向上、言語面の進化に加え、ASP.NET Coreも進歩しました。この記事ではASP.NET Coreの進歩に着目します。
私たちが ASP.NET Core 5 を使わない理由はあるでしょうか。
おそらく「C#のエンジニアが揃ったチームの新規開発」のシナリオにおいてそれはほとんどありません。積極的に使いたい理由を6つ取り上げます。

使いたい理由1 : 最新のC#9をサポートしている

C#9の record をサポートしています。recordはclassの拡張なので動いて当然といえば当然と思えますが、こうした言語の拡張がスムーズに取り込まれていくことはとても重要です。そしてこれも.NET / C#の魅力です。
C#で近年強化された何を使うことができるでしょうか。
例えば、パターンマッチングを駆使すればWPFのDataTemplateのようなものもきれいに記述できるかもしれません。

使いたい理由2 : トップレベルの速度を実現している

ASP.NET Core3.1からさらなる最適化が施された結果、HTTP/2とgRPCについては他の言語/プラットフォームと比べてもトップレベルの速度になりました。以下のようなベンチマークが公表されています。

gRPC and .NET 5 are fast

In a community run benchmark of different gRPC server implementations, .NET gets the highest requests per second after Rust, and is just ahead of C++ and Go.

This result builds on top of the work done in .NET 5. Our benchmarks show .NET 5 server performance is 60% faster than .NET Core 3.1. .NET 5 client performance is 230% faster than .NET Core 3.1.

Stephen Toub discusses dotnet/runtime changes in his Performance Improvements in .NET 5 blog post. Check it out to read about improvements in HttpClient and HTTP/2.

https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5/ から引用

gRPCをC#ネイティブ実装に置き換えた結果、複数のプラットフォームでのベンチマーク結果が1位と僅差の2位に入りました。
「通信が速い」「遅延が少ない」というのは、選定するためのシンプルにして強力な動機となりえます。
これは小さな最適化アプローチの積み重ねが効いた結果と言えそうです。

• • .NET5自体の最適化の恩恵
  • JSONのシリアライズ/デシリアライズ
    • ほとんどのシナリオで2倍以上高速になったとのことです。
  • HTTP/2のための最適化
    • ストリームをプールすることで、リクエスト毎の割り当てが半減します。これにより、GCの時間が節約されパフォーマンスが向上します。
    • いろいろなものを再利用します。例えばPipe、ヘッダー文字列、小さなリクエストに対して使うオブジェクトなどです。
    • メモリ等の割り当てを削減します。(こちらは非常に多岐に渡るため割愛しますが、小さな節約もGCの時間の節約につながります)

これに合わせてBlazor WebAssemblyも高速化しました。これは2020年の5月(ASP.NET Core 3.1より後)にリリースされたばかりですが、すでにパフォーマンス改善のためのさまざまな改良がなされています。曰く「ほとんどのシナリオで2-3倍以上高速」とのことです。

• • Grid(表)の描画などのパフォーマンス向上
  • プリレンダリング機能
  • IL(中間言語)トリミング機能
    • アプリケーションから到達しないILをビルド中にトリミングして、アプリケーションの実質の起動時間を短縮することができます。このために大変な努力をしていた人たちにとって、これは朗報です。
  • Blazorコンポーネントを仮想化する Virtualize コンポーネントの導入
    • これは大量のリストなどの表示とロードを必要な範囲のみ読み込むようにしてレンダリングコストを低減することができます。

使いたい理由3 : 新しいコンポーネントと新しいサポート

単純なパフォーマンス向上に加え、コンポーネントの拡張や追加があります。

• • ファイル入力コントロール(InputFileコンポーネントの追加による)
  • ラジオボタン(InputRadio / InputRadioGroup)
  • ontoggleイベント対応
  • UIフォーカスの設定
  • IAsyncDisposable(非同期破棄)をサポート
  • カスタム検証属性
  • UTC DateTimeのバインディング

使いたい理由4 : 開発支援機能

• • dotnet watch での自動更新
    • ソースコードが更新されると自動的にビルドしブラウザがリフレッシュしてくれます。
      つまり、Node.js＋Reactなどで開発しているときにできたことがC#でもできるようになります。
  • 互換性検証機能
    • Blazor WebAssembly がサポートしない.NET 5 の機能を警告として出力します。
  • WebAssemblyデバッガーの連携強化

使いたい理由5 : OpenAPI仕様がデフォルトサポートになった

新しいプロジェクトを作るとき、OpenAPIのドキュメント出力としてSwaggerUIがランタイムビルドされるようになりました。これがデフォルトになったのは実はとてもありがたいことです。APIを持つプロジェクトではドキュメントとテストを簡略化することができます。
もちろん、この機能は簡単に無効化することもできます。

使いたい理由6 : もうデプロイできる

.NET 5 がリリースされたその日、すでにAzure App Serviceには.NET 5 のWebアプリケーションをデプロイできるようになっていました。
General settings -> Stack Settings -> .NET Framework version -> .NET 5

簡単ですね！

謝辞

ASP.NET Core 5 のリリースはとても素晴らしい内容でした。
それは「Blazor WebAssemblyが実用レベルに到達するために必要」だと思っていた機能の多くが織り込まれただけでなく、パフォーマンス向上のための粘り強い努力を感じました。
きっとエンドユーザーにもエンジニアにも多くの利益をもたらすことでしょう。
これらに尽力をしてくださったすべてのエンジニアと関係者の皆様に感謝いたします。