C#におけるgRPCの未来はgrpc-dotnetに属する
更新 2023-10-02: Grpc.Core のメンテナンス期間が再び延長され、少なくとも 2024年10月までとなります。Grpc.Core に関する最新情報は、アナウンス を参照してください。
更新 2022-05-03: Grpc.Core のメンテナンス期間が2023年5月まで延長されました。Grpc.Core の将来に関する詳細は、アナウンス を参照してください。
要約 grpc-dotnet（Grpc.Net.Client および Grpc.AspNetCore.Server NuGet パッケージ）は、現在 .NET/C# の推奨 gRPC 実装です。元の gRPC C# 実装（Grpc.Core NuGet パッケージ）はメンテナンスモードに入り、新機能は提供されず、重要なバグ修正およびセキュリティ修正のみが行われます。最終的には、将来的に Grpc.Core を完全に廃止する予定です。このアナウウンスでは、その理由と計画の詳細を説明します。
2019年9月、gRPC C ネイティブライブラリに基づかない、.NET Core 3 および ASP.NET Core 3 に追加された HTTP/2 プロトコル実装を使用する新しい gRPC C# 実装 の一般提供を発表しました。この実装を「grpc-dotnet」と呼びます。
grpc-dotnet 実装の導入時、両方の gRPC C# 実装（新しい純粋 C# の grpc-dotnet 実装と、C コアネイティブライブラリに基づいた元の gRPC C# 実装）は並存し、ユーザーが最適な実装を選択できるようにすると発表しました。当時、grpc-dotnet は新しく、リリースされたばかりの .NET Core フレームワークを必要としていましたが、元の gRPC C# 実装は長期間安定しており、多くのユーザーが利用し、非常に古い .NET Framework バージョンでも動作しました。そのため、このアプローチは理にかなっていました。物事を落ち着かせる時間が必要だったのです。
それ以降、新しい grpc-dotnet 実装は大きく進歩しました。多くのユーザーに採用され、非常に人気が高まり、多くのアプリケーションで本番環境で使用され、多くの興味深い新機能が追加されました。さらに、その主な前提条件である .NET Core 3 フレームワークも普及し、導入数が増加しています。
同時に、元の gRPC C# 実装（しばしば「Grpc.Core」、その NuGet パッケージ名で参照されます）は確かにその場所があり、非常に人気がありますが、2016年（gRPC C# が GA としてリリースされた年）には完璧だった設計上の決定が、もはや以前ほどの重みを持たなくなっています。例えば、2016年当時、利用可能な C# HTTP/2 ライブラリがなかったため、gRPC C# 実装をネイティブライブラリに基づいて開発することを決定しました。代わりに C コアネイティブライブラリに依存することで、すべてを C# でゼロから実装するよりもはるかに早く、安定した高性能な gRPC ライブラリを提供することができました。しかし、現在の観点からは、HTTP/2 サポートが .NET Core フレームワークに組み込まれたため、ネイティブ依存を持つことはそれほど意味がありません。ネイティブ依存を持つことの利点は低下していますが、そのメンテナンス負担はそのままです。
2つの安定した C# 実装のうち、grpc-dotnet 実装が間違いなく将来性が高いものです。よりモダンな実装であり、最新バージョンの .NET とうまく統合されており、数年後の C# コミュニティの方向性とより一致する可能性が高いです。また、純粋な C# 実装（ネイティブコンポーネントなし）であり、貢献が容易になり、デバッグ性が向上し、C# 愛好家にとっても魅力的なものです。
C# 用の gRPC の2つの公式実装を維持するには少なくないコストがかかること、そして長期的には grpc-dotnet がすべてのユーザーにとって最良の選択肢であると思われることから、私たちは よりモダンで将来性のある grpc-dotnet 実装を支持するために、元の gRPC C# 実装（NuGet パッケージ Grpc.Core）を段階的に廃止する意向を発表したい と思います。
計画の詳細は、なぜこれが理にかなっているかのさらなる説明とともに、以下のセクションで説明します。Grpc.Core の廃止決定の影響を理解するために、よくある質問とその回答のリストも作成しました。
grpc-dotnet が推奨される実装である理由
単純に言えば、grpc-dotnet は将来のために良い選択肢だと思われます。最も重要な点はすでに述べました。grpc-dotnet がユーザーのニーズをより良く満たすと信じる理由を以下に詳しく示します。
最近の .NET フレームワークの機能に基づいた、よりモダンな実装です。そのため、将来的に2つの実装の中でより実行可能なものになるでしょう。
現在の C# / .NET コミュニティの方向性と将来の方向性に沿っています。コミュニティの進む方向に沿っていることは、C# における gRPC の将来にとって最善の選択肢となるでしょう。
実装ははるかに機敏で貢献しやすいです。よく知られたプリミティブ/API（ASP.NET Core サービングAPIと HTTP2 クライアント）に基づいており、純粋な C# で実装されているため、C# 開発者にとってコードははるかにアクセスしやすくなります（物事がどのように機能するかを理解したいユーザーも、PR を作成する可能性のある開発者も同様です）。grpc-dotnet のコードベースは比較的小さく、ビルドには数秒、テストの実行は簡単で迅速です。長期的には、開発の容易さと貢献のしやすさが、現在不足しているいくつかの機能の補いとなり、ユーザーにとってより優れた選択肢となるでしょう。つまり、貢献や修正/改善の障壁を下げることは、時間の経過とともに、より多くのものが修正され、ユーザーエクスペリエンスが向上することにつながります。
純粋な C# で実装されたライブラリを持つことは、ネイティブコンポーネントに依存する実装と比較して、.NET コミュニティで一般的に好まれています。C# はネイティブライブラリとの相互運用に優れたサポートを持っていますが、ほとんどの C# 開発者には馴染みがなく、ブラックボックスのように見えます。ネイティブ相互運用は正しく行うのが難しく、多くの欠点があります（例：開発およびビルドプロセスの複雑化、デバッグの難しさ、保守の難しさ、複数のプラットフォームのサポートの難しさ）。Grpc.Core では、これらの課題のほとんどを克服することができましたが（現在ではうまく機能しています）、多大な労力がかかり、ソリューションは時々複雑で壊れやすく、保守にはコストがかかり、多くの専門知識が必要です。
注意：C# 用の Google.Protobuf ライブラリはすでに純粋な C# で書かれています（ネイティブコンポーネントなし）。したがって、gRPC の純粋な C# 実装により、開発者のマイクロサービススタックからネイティブコンポーネントを完全に排除できます。
なぜ Grpc.Core を永久に維持しないのか？
C# 用の gRPC の2つの実装を開発することは無料ではありません。貴重なリソースを消費し、エンジニアリング時間は、同じ目的を果たす2つの異なるコードベースに取り組む必要に迫られるのではなく、gRPC for C# を使いやすくし、新機能を追加すること（もちろんバグ修正も）に費やされた方が良いと信じています。また、2つの別個の実装を持つことは、必然的にユーザーベースをある程度断片化し、貢献者の努力を2つに分割します。さらに、ユーザーがどちらの2つの実装に賭けるかを選択する必要があるという単純な行為自体が、不確実性と固有のリスクを伴います（これらはユーザーに望まないことです）。
grpc-dotnet を推奨実装とし、Grpc.Core 実装を「メンテナンスのみ」とし（最終的には廃止する）、以下の目標を達成することを目指しています。
- より優れた機能と使いやすさのために、エンジニアリングリソースを解放する。
- gRPC C# ユーザーベースを統合する。これにより、すべてのコミュニティの作業と貢献が単一の実装に集約されます。また、ユーザーが2つの公式実装のどちらを選択する必要があるかによって生じる固有の摩擦も排除されます。
- 他の方法では対処が困難な、Grpc.Core のよく知られた問題点に対処する。
- C#/.NET gRPC 実装を将来にわたって保証するため、.NET コミュニティとの連携を維持する。
計画
フェーズ 1: Grpc.Core が「メンテナンスのみ」になる
時期: 即時（2021年5月）
今後、Grpc.Core の新機能や機能強化は提供しません。重要なバグやセキュリティの問題は、従来通り対応します。
Grpc.Core のリリースは、通常の6週間ごとのスケジュールで通常通り公開します。
リリースは最新の grpc C コアネイティブライブラリビルドに基づいているため、C# 固有の作業を必要としない新機能もすべて含まれます。
フェーズ 2: Grpc.Core が「非推奨」になる
時期: 1年後（2022年5月）
このマイルストーンに達すると、Grpc.Core は公式にサポートされなくなり、すべてのユーザーは、この時点以降は grpc-dotnet のみを使用することを強く推奨されます。
Grpc.Core NuGet パッケージは nuget.org リポジトリで引き続き利用可能ですが、それ以上の修正（セキュリティ修正さえも）は提供されません。
Grpc.Tools および Grpc.Core.Api NuGet パッケージの将来
両方のパッケージは、厳密には Grpc.Core の一部ではなく、grpc-dotnet でも使用されているため、引き続き完全にサポートされます。
- C# プロジェクトのコード生成ビルド統合を提供する Grpc.Tools NuGet パッケージは、Grpc.Core と grpc-dotnet の両方で使用されているため、引き続きサポートされ（改善される可能性もあります）。このパッケージは C コアとは独立しています。
- Grpc.Core.Api パッケージは grpc-dotnet の前提条件であるため、時間とともに進化する可能性があります（ただし、純粋な C# API のみを含むパッケージであり、公開 API サーフェスのみであるため、変更は非常にまれです）。
Q & A
現在 Grpc.Core を使用していますが、これは私にとって何を意味しますか？
Grpc.Core はしばらくの間サポートを継続しますが（詳細については非推奨スケジュールを参照）、将来的にアップデートやバグ修正を継続して受けたい場合は、プロジェクトを grpc-dotnet に移行する必要があります。
既存のプロジェクトを grpc-dotnet に移行するにはどうすればよいですか？
Grpc.Core と grpc-dotnet は2つの異なるライブラリであるため、プロジェクトでいくつかのコード変更が必要になります。両方の実装で RPC の呼び出しと処理のための API は共通しているため（意図的にそのように設計しました）、必要なコード変更はかなり最小限で済むと考えています。多くのアプリケーションでは、gRPC チャネルとサーバーの設定方法を変更するだけで済みます。これは通常、アプリの実装のわずかな部分であり、ビジネスロジックとは別に分離されている傾向があります。
Grpc.Core から grpc-dotnet への移行方法に関するヒントについては、C-core から ASP.NET Core への gRPC サービスの移行 を参照してください。
将来的には、Grpc.Core から grpc-dotnet への移行を容易にするための、より詳細な移行ガイドを公開する予定です。
新しいプロジェクトで gRPC in C# を使用したいのですが、どちらの実装を選択すべきですか？
新しいプロジェクトでは、grpc-dotnet のみの使用を強く推奨します。将来的に Grpc.Core のサポートを終了します。
これは、今すぐ Grpc.Core の使用を停止する必要があるということですか？
いいえ、Grpc.Core はしばらくの間サポートされます（非推奨スケジュールを参照）。状況を評価し、移行を計画するための十分な時間があります。
私はコードで gRPC を直接使用していませんが、Google Cloud クライアントライブラリ（内部で Grpc.Core を使用しています）を使用しています。これは私にどのような影響がありますか？
この非推奨は、現在 Google Cloud クライアントライブラリの既存ユーザーには影響しません。
Grpc.Core はこれらのクライアントライブラリの不可欠な部分であるため、Grpc.Core のセキュリティおよびバグ修正は Google Cloud クライアントライブラリに対しても引き続き提供されます。
延長サポートが提供されるクライアントライブラリ
注意：Grpc.Core の延長サポートは、これらのクライアントライブラリの一部として使用される場合にのみ提供されます。Google Cloud クライアントライブラリ以外のユースケースでは、非推奨日以降、Grpc.Core は公式にはサポートされず、ユーザーは非推奨が発生する前に既存のワークロードを grpc-dotnet に移行する必要があります。
サポートされている機能のリストはどこで見ることができますか？
GitHub の ドキュメント に、サポートされている機能の比較があります。
このドキュメントでカバーされていない、重要な Grpc.Core のユースケースがあります。
フィードバックをお待ちしています！ grpc-io Google グループ、またはその他の主要な gRPC コミュニティチャネル からご連絡ください。