connectrpc
Option to remove connect wrappers in generated code
Is your feature request related to a problem? Please describe.
I understand connect.Request and connect.Response are useful types for providing access to metadata such as HTTP headers, but in practice I find myself absolutely never using such functions across many RPC servers/clients I've migrated to connect. They're essential in interceptors, but I think it's fairly common for users to not need these in RPC itself. But it gets tedious to have to call .Msg and feels like the framework working against me.
Another effect is not matching upstream stubs, so a migration does become both quite some work and also very difficult to do in a flag-guarded way preserving both code paths especially on the client side. If there was something awesome about calling connect.NewRequest and res.Msg on its own line after checking err, then it would be motivating, but it feels unnecessary.
I'm sure there must have been a lot of consideration put into this design decision to break from the upstream types, but wonder if there's been any thought otherwise on maybe allowing avoiding those types for users that don't need them?
Describe the solution you'd like
A code-gen option to provide client stubs and support server stubs that don't use connect.Request / connect.Response. The code-gen would probably be a simple enough place to wrap for providing to the framework which I think wouldn't need changes.
Describe alternatives you've considered
Continue to have extra verbosity / migration cost since it's still not a blocker. Also, I have found a generics based solution for the server side that I use both for this and other reasons, which allowed me to avoid the wrappers
https://github.com/curioswitch/go-curiostack/blob/main/server/connect.go#L18
I think a similar client version could be doable - basically instead of using stubs, the Procedure variables become the entry point to a single function. I might go with it for my own code but probably wouldn't recommend such a big change in paradigm for code I don't have sole ownership of.
Additional context
This isn't a highly important change but I thought I'd bring it up just to see what people's thoughts are on it.
FYI, there is already a discussion for this: #421.
There hasn't been many updates in that discussion thread in a while, but it is a thing that some of us maintainers have discussed in the past 12 months.
Thanks for the reference @jhump had checked the issues but forgot about discussions. Is it worth keeping this issue open? If there's direction on whether it's acceptable and an approach (personally I would go with an option rather than supporting both at the same time which gets more complicated, but anything would be fine), could try to help with a PR. I'm all-in on connect so would like to help make things easier if possible.
Just commenting in the issue as I think it's worth tracking as an issue:
I think we should re-visit this. Even as a maintainer, this is an annoyance for me when I use connect-go. It's even become such an annoyance to Buf employees that internal plugins have been developed to eliminate *connect.Request and *connect.Response. A solution wouldn't be terribly difficult - just use context.Context where necessary, like other RPC libraries, add some functions to the core package, and add an option (or another plugin) to generate the simple interface.
Just commenting here so we/I don't forget. I don't think this would be a huge investment though.
@anuraaga I've prototyped a solution at https://github.com/connectrpc/connect-go/pull/851 - take a look if you'd like.