[Question] design tradeoffs about including ctx in method argument for generated stream handler

[DMwangnima]

Hi all, I noticed that for connect-go, it generated stream handler with ctx in method argument:

type PingServiceHandler interface {
	// Sum calculates the sum of the numbers sent on the stream.
	Sum(context.Context, *connect.ClientStream[v1.SumRequest]) (*connect.Response[v1.SumResponse], error)
	// CumSum determines the cumulative sum of all the numbers sent on the stream.
	CumSum(context.Context, *connect.BidiStream[v1.CumSumRequest, v1.CumSumResponse]) error
}

For grpc-go, instead of adding a ctx in method argument, it adds a Context() method to the Stream interface that is exposed to the user. But for unary method, it still includes ctx.

type RouteGuideServer interface {
        GetFeature(context.Context, *Point) (*Feature, error)
	ListFeatures(*Rectangle, grpc.ServerStreamingServer[Feature]) error
	RecordRoute(grpc.ClientStreamingServer[Point, RouteSummary]) error
	RouteChat(grpc.BidiStreamingServer[RouteNote, RouteNote]) error
	mustEmbedUnimplementedRouteGuideServer()
}

• I think connect-go has a more unified interface design. Did you specifically consider this when you designed it? Is there any other reason?
• And do you know why grpc-go doesn't take a ctx as a method parameter, it seems like a bit of by design from this issue generated stream handler doesn't include context in method argument grpc/grpc-go#173

[emcfarlane]

Hi @DMwangnima moved this issue to a discussion. The context.Context is passed as the first arg for usability and consistency. It allows interceptors to set the context more easily then stubbing the method on the stream handler.

[DMwangnima]

Thx for your reply!

[gtomitsuka]

meta: is it possible to block non-maintainers from opening discussions? sucks to have this stuff crowd out other things in the homepage