Closed akshayjshah closed 3 years ago
Pushed a bit more progress tonight: we're now generating the server-side code to support all three streaming RPC types. Hopefully I'll get the client-side code and tests done in the next few days.
Done! reRPC now supports client, server, and bidirectional streaming, and cross-tests show that we're compatible with grpc-go. (We should probably exercise more corner cases in tests, though.)
Adding streaming didn't expand the API as much as I feared. We needed:
Stream
interface, which also serves as a pretty good transport abstraction for the generated code.StreamFunc
interface, analogous to Func
.Interceptor
interface.StreamType
constants.I'm still pretty close to the code, but the APIs feel pretty narrow to me.
Right now, reRPC only exposes support for unary RPCs. However, it wouldn't be terribly difficult to support client, server, and bidirectional streaming - under the hood,
NewReflectionHandler
already uses bidi streaming.Advantages of streaming:
grpc-go
just to call or serve one streaming method, so building with reRPC becomes a safer bet.Disadvantages of streaming:
net/http
in a somewhat unusual way. I'd expect more difficult-to-diagnose bugs.Func
andInterceptor
, and we might even need separate interfaces for each streaming type (like grpc-go).I lean toward keeping reRPC unary-only, but I'm leaving this issue open for discussion. I'm particularly interested in talking to anyone willing to use reRPC streaming in production.