protoc-gen-go-grpc: Use grpc.ServiceRegistrar instead of *grpc.Server in _grpc.pb.go

[vadimsht]

Use case(s) - what problem will this feature solve?

I'm from a team behind Chromium CI system aka LUCI. We use gRPC domain model (services defined in *.proto, generated stubs etc) to publish our internal APIs on Appengine Standard Environment. We don't use gRPC protocol proper, since Appengine doesn't really support inbound HTTP2. This thing we built is called prpc and it is kind of a hack. The idea is to eventually switch to real gRPC, when we can, by swapping prpc server and client instantiations with gRPC ones.

As such we have our own Server and Client implementations that conform to gRPC semantics (sans streaming), but use simpler HTTP1 protocol.

Client implements grpc.ClientConnInterface and stubs generated by protoc-gen-go-grpc work splendidly with it!

Server implements grpc.ServiceRegistrar, but stubs generated by protoc-gen-go-grpc are not using it and instead hardcode dependency on *grpc.Server. So we have an extra code-generatation stage to "fix" .pb.go to use an interface instead of a concrete type. We really-really want to get rid of it.

Curiously, at some point grpc stubs were using ServiceRegistrar, but it was reverted in #3885 (and now ServiceRegistrar seems to be completely unreferenced).

Proposed Solution

I propose to change protoc-gen-go-grpc to emit e.g.

func RegisterFooServer(s grpc.ServiceRegistrar, srv FooServer) {
	s.RegisterService(&_Foo_serviceDesc, srv)
}

instead of the current

func RegisterFooServer(s *grpc.Server, srv FooServer) {
	s.RegisterService(&_Foo_serviceDesc, srv)
}

It seems like a small change, but it will make a group of ~15 developers a bit happier and will justify continuing existence of grpc.ServiceRegistrar.

[dfawley]

Oops. Yes, that was the whole point. It seems we missed this when switching back to the older codegen style shortly before 1.0.