Introduce Grpc.Net.Server for Hosting gRPC Servers in .NET Standard and .NET 8+ (Non-ASP.NET Core)

[perpetualintelligencegit]

Proposal: Add Grpc.Net.Server for Non-ASP.NET Core Environments

Context

We have received customer requests to support gRPC within our terminal framework (for .NET Standard, .NET
https://github.com/perpetualintelligence/terminal
perpetualintelligence/terminal#44

Summary

Currently, gRPC server functionality is supported by:

1. Grpc.AspNetCore: Designed for ASP.NET Core environments.
2. Grpc.Core: Used for non-ASP.NET Core applications but is being deprecated.

With no clear alternative for non-ASP.NET Core environments like desktop, console, or lightweight server applications, developers are left without an option for gRPC servers outside of web contexts. This creates a gap for building gRPC servers in non-web scenarios.

Justification

• Non-Web Use Cases: gRPC is widely used in desktop apps, console apps, IoT, microservices, and secured factory environments where ASP.NET Core adds unnecessary overhead.
• No Alternative to Grpc.Core: As Grpc.Core is deprecated, developers need replacement that fits non-web applications.
• Consistency with Grpc.Net.Client: A Grpc.Net.Server package would align with Grpc.Net.Client, providing a unified experience for non-web gRPC development.
• Avoiding ASP.NET Core: Non-web applications shouldn’t need ASP.NET Core to host a gRPC server.

Proposed Solution

Introduce Grpc.Net.Server with:

• Lightweight, dependency-free gRPC server support for non-web applications (Multi target .NET Standard 2.0, .NET Standard 2.1, .NET Standard 8.0+)
• Full compatibility with Grpc.Net.Client.
• Support for HTTP/2, SSL/TLS, and .NET 6, 7, and 8.
• Grpc.AspNetCore will use Grpc.Net.Server

This would allow developers to easily adopt gRPC in non-ASP.NET Core environments without using deprecated packages.

[JamesNK]

What is a non-ASP.NET Core environment to you? You can host a gRPC service inside all kinds of apps. See #1419 (comment)

ASP.NET Core is just some APIs that you can include many kinds of .NET projects. All you need to do to support a gRPC server is add this line to a .NET 5+ app:

<FrameworkReference Include="Microsoft.AspNetCore.App" />

Creating a new server (TCP, TLS, HTTP/2, HTTP abstractions, etc) will be hundreds of hours of work, and the end result will be something done badly. It will be slower, less secure and have less features than Kestrel because it will have a fraction of the development time.

You or someone else is welcome to attempt writing your own server from scratch. I'd strongly advise against it, HTTP/2 is a very complicated protocol and it is easy to create DDOS vulnrabilities.

I can say with a lot of certainity that it won't be done as part of this project.

[perpetualintelligencegit]

Thank you for the response. I understand the value of Kestrel and ASP.NET Core for hosting gRPC services, but that is for the end application. I don’t believe a class library should require a reference to Microsoft.AspNetCore.App.

Requiring Microsoft.AspNetCore.App introduces unnecessary overhead for projects that don’t need web server features, such as desktop apps, console apps, on-prem IoT, and microservices. A lightweight, modular gRPC server class library without this dependency would simplify development and allow broader reuse in different environments.

E.g. Our entire terminal framework that provides multiple network protocols is a class library (Non ASP.NET) clients can use in console, Blazor or web apps.

[JamesNK]

Everything I said earlier still stands. Creating a new HTTP server, with TCP, HTTP/2, TLS/SSL, logging, configuration, security hardening, performance testing, and so on is a HUGE amount of work. I can say with a lot of certainity that it won't be done as part of this project.

You're welcome to do it yourself. The .NET gRPC APIs to do so are public and can be layered on top of a new server. But like I said before, I strongly recommend against it.

[perpetualintelligencegit]

@JamesNK: Thank you so much for your feedback. Based on your recommendation, we have successfully integrated the new gRPC setup into our Cross-Platform Terminal framework. Our implementation now consists of a class library (OneImlx.Terminal) that isolates the gRPC proto configuration and terminal routers, alongside an ASP.NET Core application that sets up the gRPC server, and a client library that facilitates the client apps.

We would greatly appreciate if you could review these files before we proceed with our release, and let us know if you see any concern:

• Framework
  https://github.com/perpetualintelligence/terminal/blob/main/src/OneImlx.Terminal/Runtime/TerminalGrpcRouter.cs

• AspNetCore Hosting
  https://github.com/perpetualintelligence/terminal/blob/main/src/OneImlx.Terminal.AspNetCore/Protos/oneimlx_terminal.proto
  https://github.com/perpetualintelligence/terminal/blob/main/src/OneImlx.Terminal.AspNetCore/TerminalGrpcMapService.cs

• Client
  https://github.com/perpetualintelligence/terminal/blob/main/src/OneImlx.Terminal.Client/Extensions/TerminalGrpcRouterProtoClientExtensions.cs

The sample code demonstrates the multi-network protocol support (e.g. Udp, TCP, gRPC, HTTP) capabilities provided by the Terminal framework. https://github.com/perpetualintelligence/terminal/tree/main/apps/s2s

Thanks again for your feedback.

[HppZ]

I support this proposal!

[HppZ]

#1419

[HppZ]

Thank you for the response. I understand the value of Kestrel and ASP.NET Core for hosting gRPC services, but that is for the end application. I don’t believe a class library should require a reference to Microsoft.AspNetCore.App.

Requiring Microsoft.AspNetCore.App introduces unnecessary overhead for projects that don’t need web server features, such as desktop apps, console apps, on-prem IoT, and microservices. A lightweight, modular gRPC server class library without this dependency would simplify development and allow broader reuse in different environments.

E.g. Our entire terminal framework that provides multiple network protocols is a class library (Non ASP.NET) clients can use in console, Blazor or web apps.

Agree!