Feature request: In-process transport

[Daniel15]

Is your feature request related to a problem? Please describe.

I have an ASP.NET Core site that connects to 10 or so different instances of the same gRPC service, deployed across several servers.

One of the instances will be running on the local machine. In this case, I'd like to have both the server and the client hosted in a single app, and the ability to perform an "in-process" gRPC call, for example where the client directly instantiates an instance of the server. This would avoid TCP overhead, and Protobuf serialization/deserialization overhead (as the client could pass the Protobuf instances directly to the server instance).

Describe the solution you'd like

As above. I imagine this could be implemented by making the transport pluggable instead of hard-coding it to use HttpClient.

Additional context

• The Java gRPC library supports this feature: https://grpc.github.io/grpc-java/javadoc/io/grpc/inprocess/package-summary.html
• There is an open feature request to implement this in the Go gRPC library: Feature Request: Add support for custom transport (in-process, wasm) grpc-go#906

[davidfowl]

As above. I imagine this could be implemented by making the transport pluggable instead of hard-coding it to use HttpClient.

The transport is pluggable today but GRPC requires HTTP/2 which is implemented in HttpClient https://github.com/dotnet/corefx/issues/35404

[Daniel15]

GRPC requires HTTP/2 which is implemented in HttpClient

Requiring HTTP means you're always going to have the protobuf serialization/deserialization overhead, which is less than ideal as it should be unnecessary for something in-proc. Do you really need HTTP for communication within the same process? It should be possible to just use method calls.

I wonder how the Java library does it.

[JamesNK]

Java doesn’t serialize the messages, but that works for Java because their generated messages are immutable.

I doubt we’ll support that style of inproc, at least in the short/medium term. It would require rewriting the client and server. However, there is nothing stopping someone else writing a client CallInvoker that directly calls a service.

grpc-dotnet inproc will use a HttpClient + memory transport. The client and server will still use HTTP/2, but can call the Kestrel server without any TCP overhead.

[JamesNK]

Closing as duplicate of #239