Support Connect RPC client

[StevenACoffman]

I would like it if ts-proto supported generating a connect-rpc client, the way it does for Twirp, grpc-web, grpc-js and nestjs are supported. Right now, using connectrpc requires us to abandon ts-proto and switch to protobuf-es.

connectrpc/connect-es#1016

[stephenh]

Hi @StevenACoffman ! I'm not an expert on connect-rpc, but lately we do sit on top of @buf/protobuf anyway for our underlying encode/decode methods, so I would thinks this should be possible!

In particular the REST APIs, of "just drop me the JSON with a header or two":

curl \
    --header 'Content-Type: application/json' \
    --data '{"sentence": "I feel happy."}' \
    https://demo.connectrpc.com/connectrpc.eliza.v1.ElizaService/Say

Seems easy to get supported in ts-proto, given this is basically what Twirp is/was, afaiu?

I dunno, maybe a 1st pass would be do copy/paste the Twirp client? Not sure if that or NestJS would be a better starting place to copy/paste from; Twirp was the very 1st client that I wrote cough years ago, and probably basically doesn't get used, so maybe NestJS instead? But I feel like Twirp is closer in spirit to Connect, so still might be a better starting place.

Would you be open to looking into this and submitting a PR? Happy to help review/poke around a bit if so. Thanks!

[StevenACoffman]

I dug around a little and my original impetus for using ts-proto was to avoid using JavaScript classes (ick), but Connect-ES v2 now uses Protobuf-ES v2, which is now built around using plain typescript (javascript) objects:

• https://buf.build/blog/protobuf-es-v2
• https://buf.build/blog/connect-es-v2

It looks like with protobuf-es-v2, and ts-proto using buf, there's a lot more convergence then there used to be.

Independent of connect-rpc (and connect-es), it might be generally helpful to enumerate the points of convergence and any remaining points of divergence between newer ts-proto and protobuf-es-v2

[stephenh]

Ah yeah, I kinda remember that going by, but hadn't deeply looked into their new v2 bindings.

I agree it would be worth a readme entry/note with a short tldr of the two.

Fwiw my assumption is that connect/protobuf-es-v2 will have very correct/conformant APIs (definitely their strong suit), now sans class-es, but ts-proto might still have the edge on "pure TypeScript idiomatic-ness", especially where "what's idiomatic" is a subjective opinion, and ts-proto has ~admittedly too many knobs to support the grab-bag of styles/usages that is the ~fragmented protobuf ecosystem/myriad use cases.

(Which, to their credit, afaiu connect/buf is trying to clean up all that fragmentation, and establish "the one way of doing things that just works", which is great, but the fragmentation cat is already out of the bag, and so I imagine ts-proto will always have a place in some stacks. 🤷 )