Golang RPC and everything…

In general, gogo is twice as fast as Google’s implementation. By the way, you can see in the table a certain musgo – shows itself very well (because codegen). Probably, it was worth inserting into the table a well-known msgpack – a project from the opensource community, which still does not take off as it should (but there seems to be some progress). For additional reading – Zoo at Golang MSA. Protobuf, MessagePack, Gob – what to choose?

Move on. More and more often, developers are wondering, why is golang gRPC so monstrous in terms of overhead on dependencies? And why under the hood it has its own implementation of the http/2 stack, and not the reuse of the “golang.org/x/net/http2” package (well, yes, types and configs from it are used, but no more). And in general – not everything is so smooth with forwarding http/2 through load balancers.

In order to solve the two mentioned problems – dependencies on the code (read, the constant war with bugs and breaking changes, which in Google, apparently, is a “normal” phenomenon) and support for http 1.1, in Twitch filed your framework Twirp (by the way, http/2 is also supported from golang standard library) – Twirp: a sweet new RPC framework for Go, it was also written about on Habr – Twirp vs gRPC. Is it worth it?

For the same reasons in Storj also developed their own alternative to gRPC – DRPCsee article Introducing DRPC: Our Replacement for gRPCand they considered Twirp as a possible solution, but it did not have the necessary feature – streaming (as in gRPC), which was also implemented in DRPC.

Wait a minute, so far all the talk has been about RPC between, relatively speaking, the cloud and PC/Mobile clients. And why such bells and whistles for the interaction of microservices? Why not plain TCP (or even UDP, they sometimes do this in network toys)? Oh yes – net / rpc is there (what else do you need, as if asking Google).

Need more performance and features! This is how the library first appeared. valyala/gorpcand then valyala/fastrpc from Alexander Valyalkin, author fast http (read about it here on Habr – Sins of performance optimization).

Upon closer examination, it turns out that in fact there are many RPC implementations (for example, rpcx, kitex, arpccomparing their performance with gRPC and net/rpc – 2022 Go Ecosystem rpc Framework Benchmark), but gRPC is known to everyone as a kind of “silver bullet”.

And about UDP based RPC – there is a project Hprose (High Performance Remote Object Service Engine) from Chinese comrades, it is supported for many languages, and for golang also has an implementation, and so – there is UDP support. Also, the above rpcx supports TCP, HTTP, QUIC (which is under the hood of UDP) and KCP (so to speak, the Chinese version of QUIC, also on UDP).

And finally, to the question of how gRPC works under the hood … It turns out that there is an easy way to speed it up. Here are some slowpacks writing in 2022, something The Mysterious Gotcha of gRPC Stream Performancewe have been using this trick in PROD for 4 years already: as you know, gRPC has simple calls and streaming ones, and so – if you make a pool of streams instead of a simple call, then everything works about twice as fast (with sequential or concurrent requests – it doesn’t matter ), abstract example:

api.proto

syntax = "proto3";

package pb

message Request {}
message Response {}

service Service {
  rpc Unary (Request) returns (Response);
  rpc Stream (stream Request) returns (stream Response);
}

server.go

func (s *grpcServer) Unary(ctx context.Context, req *pb.Request) (*pb.Response, error) {
	return &pb.ResponseDomain{}, nil
}

func (s *grpcServer) Stream(stream pb.Service_StreamServer) error {
	ctx := stream.Context()
	for {
		select {
		case <-ctx.Done():
			return ctx.Err()
		default:
		}

		req, err := stream.Recv()
		if err == io.EOF {
			break
		}

		if err != nil {
			return err
		}

		resp, _ := s.Unary(ctx, req)
		if err := stream.Send(resp); err != nil {
			return err
		}
	}
	return nil
}

client.go

func (c *grpcClient) Call(ctx context.Context, req *pb.Request) (*pb.Response, error) {
	if !c.streams {
		return c.client.Unary(ctx, req)
	}

	stream := c.getStreamFromPool()
	if stream == nil {
		return nil, fmt.Errorf("no stream")
	}

	if err := stream.Send(req); err != nil {
		stream, err = c.client.Stream(ctx)
		if err != nil {
			return nil, err
		}
	}

	defer c.putStreamToPool(stream)
	return stream.Recv()
}

But no one knows when it will break (although this is a hack, whatever one may say), otherwise such tweets would not be, I think.