You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes (for instance, when testing) it is useful to skip the whole RPC layer and just wire up the system in a single process. As such, I would like to be able to use my gRPC server types as clients but I can't, as the client wants to pass the extra grcp.CallOptions.
Upon further consideration, I don't think this is a good idea. The "extra" CallOptions can do things like specify metadata, which may affect the behavior of the server.
I believe what you really want is #906 to cut out unnecessary gRPC processing while still doing the things it needs to do that affect client/server interaction.
We're not that concerned with serialization overhead but during development having all services in one binary and stack traces through RPC would be great.
You don't need this feature to do that. You can put your clients and services in one binary and have the server serve to a free port on localhost, with the clients dialing that same port.
Or, you could try out our bufconn package that we use for some of our testing to avoid the network stack entirely. To use it, you pass a bufconn.Listener to a grpc.Server's Serve method, and pass the listener's Dial function as a custom dialer via the WithDialer call option. (Wrap it to ignore the args.)
lockbot
locked as resolved and limited conversation to collaborators
Sep 26, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Sometimes (for instance, when testing) it is useful to skip the whole RPC layer and just wire up the system in a single process. As such, I would like to be able to use my gRPC server types as clients but I can't, as the client wants to pass the extra
grcp.CallOption
s.Would you consider auto-generating an adapter type to allow people to do this? It would be a little more complicated to support the various streaming interfaces too, but nothing to difficult. An example of a manually written adapter is here: https://github.com/weaveworks/cortex/blob/master/pkg/ingester/ingester_lifecycle_test.go#L248
The text was updated successfully, but these errors were encountered: