Support streaming?

[akshayjshah]

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:

• Support a wider variety of use cases.
• Users wouldn't need to migrate to grpc-go just to call or serve one streaming method, so building with reRPC becomes a safer bet.

Disadvantages of streaming:

• We'd be using net/http in a somewhat unusual way. I'd expect more difficult-to-diagnose bugs.
• reRPC's surface area would grow quite a bit. We'd need streaming equivalents for Func and Interceptor, and we might even need separate interfaces for each streaming type (like grpc-go).
• Twirp doesn't support streaming: Proposal: Support streaming in the Twirp spec twitchtv/twirp#3. Most of the discussion on that issue focuses on the JSON streaming format, but we'd also probably want a framing mechanism for binary protobuf and a way to communicate errors mid-stream (after the HTTP status code has already been sent). For all its complexity, the gRPC specification solves these problems well.
• Client and server streaming will work over HTTP/1.1, but bidi requires HTTP/2. With the lack of Twirp support above, this makes reRPC's compatibility guarantees harder to understand.

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.

[akshayjshah]

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.

[akshayjshah]

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:

• A Stream interface, which also serves as a pretty good transport abstraction for the generated code.
• A StreamFunc interface, analogous to Func.
• An additional method in the Interceptor interface.
• A set of StreamType constants.

I'm still pretty close to the code, but the APIs feel pretty narrow to me.