Alternate Transports

[ccifra]

Has there been any consideration for adding support for alternate transports like shared memory, named pipes, RDMA, ...? Our use cases for gRPC can benefit greatly from high bandwidth low latency transports when the client and server are reachable using that transport. "traditional" gRPC makes it very hard to support a different transport and still support all needed languages. In C++ and languages that use the C++ core library it is extremely hard. .NET has a good solution but it does not work in general. Other languages are somewhere in between. Having this capability would be a great motivator to adopt and contribute to this project.

[timostamm]

Hey Christopher, Connect implementations rely on the platform's HTTP stack. For example, Connect for Go uses net/http, and Connect for Web uses fetch.

This keeps implementations focused, and allows them to work nicely alongside parts of the stack. For example, a connect-go handler is just a regular net/http handler: It can be served next to a handler serving - for example - a HTML document, and regular middleware can be applied to it.

This is an important feature of Connect, and alternate transports may be somewhat of an orthogonal feature. That said, the platform's HTTP stack may provide pluggable transports. I think Go's net.Transport is pretty flexible with DialContext.