I've seen the idea proposed more than once that the generated stubs be backed by an interface -- something along the lines of a channel <https://github.com/grpc/grpc-java/blob/master/core/src/main/java/io/grpc/Channel.java>. Most recently, it was during discussion of client interceptors <https://github.com/grpc/grpc-go/issues/240>. It's also come up as a way of doing in-process dispatch <https://github.com/grpc/grpc-go/issues/247> without having to go through the network stack and (much more importantly) serialization and deserialization.
There have been objections to the idea, and I just wanted to understand the rationale behind them. I have a few ideas as to what the arguments for the current approach might be. Is it one or more of these? Or are there other arguments tat I am overlooking or nuance/detail I missed in the bullets below? 1. *Surface Area*. The main argument I can think of is that the API isn't yet sufficiently mature to lock down the interface now. So exporting only a single concrete type to be used by stubs makes the API surface area smaller, allowing more flexibility in changes later. To me, this implies that introduction of such an interface is an option in the future. (I don't particularly agree with this argument since the interface surface area could have been exposed *instead of* the existing grpc.Invoke and grpc.NewClientStream methods.) 2. *Overhead*. It could be argued that the level of indirection introduced by the use of an interface could be too much overhead. I'd really like to see a benchmark that shows this if this is the case. It seems hard to imagine that a single interface vtable-dispatch would be measurable overhead considering what else happens in the course of a call. (Perhaps my imagination is broke...) 3. *Complexity*. I suppose it might be argued that introducing another type, such as a channel interface, complicates the library and the existing flow. I happen to *strongly* disagree with such an argument. I think the interface could be added in a fairly painless way that would still support older generated code. This was described in this document <https://docs.google.com/document/d/1weUMpVfXO2isThsbHU8_AWTjUetHdoFe6ziW0n5ukVg/edit#>. But were this part of the objection, I'd like to hear more. For context: I have some ideas I want to build for other kinds of stubs -- like providing special stubs that make batch streaming calls look like just issuing a bunch of unary RPCs, or for making a single bidi-stream conversation resemble a sequence of normal service calls (for some other service) that happen to be pinned to the same stream. All of these currently require* non-trivial code generation* -- either specialized to the use, or I just provide my own interface-based dispatch and build all of these things on top of that. But it feels like a fundamental hole in the existing APIs that I cannot do this already. The Java implementation has a layered architecture with Stubs on top, Transports on the bottom, and Channel in-between. The Go implementation exposes nothing along the lines of channel, instead combining it with the transport into a single clientConn. This is incredibly limiting. *----* *Josh Humphries* Software Engineer *j...@fullstory.com <j...@fullstory.com>* -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAO78j%2BLG21J4ULLKkRvgtuFaUeK0kA4zeM5js1WYyVhbex7beQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
