Documentation
¶
Overview ¶
Package inprocgrpc provides an in-process gRPC channel implementation. The in-process channel makes RPCs that are effectively in-process function calls. The function calls run in a separate goroutine from the caller so as to fully behave like a normal RPC call, including context deadlines and cancellations. This can be useful for same-process hand-off to RPC endpoints and for testing. It has less overhead than using a loopback socket connection as it elides marshaling to bytes and back.
Index ¶
- func ClientContext(ctx context.Context) context.Context
- type Channel
- func (c *Channel) Invoke(ctx context.Context, method string, req, resp interface{}, ...) error
- func (c *Channel) NewStream(ctx context.Context, desc *grpc.StreamDesc, method string, ...) (grpc.ClientStream, error)
- func (c *Channel) RegisterService(desc *grpc.ServiceDesc, svr interface{})
- func (c *Channel) WithCloner(cloner Cloner) *Channel
- func (c *Channel) WithServerStreamInterceptor(interceptor grpc.StreamServerInterceptor) *Channel
- func (c *Channel) WithServerUnaryInterceptor(interceptor grpc.UnaryServerInterceptor) *Channel
- type Cloner
- type ProtoCloner
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
Types ¶
type Channel ¶
type Channel struct {
// contains filtered or unexported fields
}
Channel is a gRPC channel where RPCs amount to an in-process method call. This is in contrast to a normal gRPC channel, where request messages marshaled to another process over a TCP socket and responses unmarshaled from the same socket.
So the in-process channel functions as both a client channel AND a server. It handles method calls from a gRPC client stub and then delivers them directly to a registered server implementation.
The server-side of an RPC is executed in a separate goroutine, so things like deadlines and context cancellation work, even for unary RPCs.
func (*Channel) Invoke ¶
func (c *Channel) Invoke(ctx context.Context, method string, req, resp interface{}, opts ...grpc.CallOption) error
Invoke satisfies the grpchan.Channel interface and supports sending unary RPCs via the in-process channel.
func (*Channel) NewStream ¶
func (c *Channel) NewStream(ctx context.Context, desc *grpc.StreamDesc, method string, opts ...grpc.CallOption) (grpc.ClientStream, error)
NewStream satisfies the grpchan.Channel interface and supports sending streaming RPCs via the in-process channel.
func (*Channel) RegisterService ¶
func (c *Channel) RegisterService(desc *grpc.ServiceDesc, svr interface{})
RegisterService registers the given service and implementation. Like a normal gRPC server, an in-process channel only allows a single implementation for a particular service. Services are identified by their fully-qualified name (e.g. "<package>.<service>").
func (*Channel) WithCloner ¶
WithCloner configures the in-process channel to use the given cloner to copy data from client to server and vice versa. Messages must be copied to avoid concurrent use of message instances.
If no cloner is configured, the default cloner can only properly support proto.Message instances. If the messages do not implement proto.Message (or if you use gogo/protobuf, whose values implement the golang/proto interface but will cause a runtime panic), you must provide a custom cloner.
func (*Channel) WithServerStreamInterceptor ¶
func (c *Channel) WithServerStreamInterceptor(interceptor grpc.StreamServerInterceptor) *Channel
WithServerStreamInterceptor configures the in-process channel to use the given server interceptor for streaming RPCs when dispatching.
func (*Channel) WithServerUnaryInterceptor ¶
func (c *Channel) WithServerUnaryInterceptor(interceptor grpc.UnaryServerInterceptor) *Channel
WithServerUnaryInterceptor configures the in-process channel to use the given server interceptor for unary RPCs when dispatching.
type Cloner ¶
Cloner knows how to make copies of messages. It can be asked to copy one value into another, and it can also be asked to simply synthesize a new value that is a copy of some input value.
This is used to copy messages between in-process client and server. Copying will usually be more efficient than marshalling to bytes and back (though that is a valid strategy that a custom Cloner implementation could take). Copies are made to avoid sharing values across client and server goroutines.
func CloneFunc ¶
CloneFunc adapts a single clone function to the Cloner interface. The given function implements the Clone method. To implement the Copy method, the given function is invoked and then reflection is used to shallow copy the clone to the output.
func CodecCloner ¶
CodecCloner uses the given codec to implement the Cloner interface. The Copy method is implemented by using the code to marshal the input to bytes and then unmarshal from bytes into the output value. The Clone method then uses reflection to create a new value of the same type and uses this strategy to then copy the input to the newly created value.
type ProtoCloner ¶
type ProtoCloner struct{}
ProtoCloner is the default cloner used by an in-process channel. This implementation can correctly handle protobuf messages. Copy and clone operations will fail if the input message is not a protobuf message (in which case a custom cloner must be used).
func (ProtoCloner) Clone ¶
func (ProtoCloner) Clone(in interface{}) (interface{}, error)
func (ProtoCloner) Copy ¶
func (ProtoCloner) Copy(out, in interface{}) error
Source Files