Usage with plain javascript objects and typescript types

[jonaskello]

We currently use ts-proto to generate types and then just use plain object that follows the structure of those types. We prefer this model to generating runnable code such as classes. Today we implement our own framework for transfering the seriazlied proto data with an abstraction for transport.

When I saw the connect protocol that piqued my interest as it seems similar to what we are already doing, altough in a more standardized form. So I'm starting to research how we may use the connect protocol. The first question I got is if there is some way to use @connectrpc/connect without the requirement to generate classes? We still would like to use plain objects and only generate types instead of runnable code like we do today with ts-proto. I cannot seem to find a full doc on the API for the package other than some examples that all seem to use generated classes but maybe I am not looking in the correct place?

[jonaskello]

I dug a bit into the source and found this:

https://github.com/bufbuild/protobuf-es/blob/8745d7224980eff85344b68d018c956359626e3e/packages/protobuf/src/service-type.ts#L62

Here it seems there is a Message class with some required method that needs to be implemented eg. equals(). To me this class feels a bit like a java/c# construct rather than idomatic javascript/typescript. I think in order to do what we want this would be to be a type/interface here instead of a concrete class. Serialization/Deserialization would still be needed but this could still be achived by decoupling this part from the type as is done in ts-proto.

So my conclusion for now it that this Message class construct is a showstopper for us since I cannot see a workaround to use plain objects/types instead.

[srikrsna-buf]

Hey! From a UX standpoint you will still be creating plain objects for requests, the responses you get back are class objects.ts-proto also generates the serialization methods along side the types. We choose this because it is the only one that passes all the conformance tests.

We did have conversations around making connect-es runtime agnostic, but it hasn't been prioritized. Maybe you can open a issue detailing the feature and the use case?

[jonaskello]

It sounds like a trade-off for being conformant to class-based lanugages over making something more idiomatic (but perhaps unconformant) has already been made. So I'm thinking it might not be worth spending time writing detailed issues about it since it is quite a fundamental design choice that probably is not easy to change? I'm afraid that issue would end up in an endless discussion of what is idomatic :-)

[srikrsna-buf]

It sounds like a trade-off for being conformant to class-based lanugages over making something more idiomatic (but perhaps unconformant) has already been made.

Sorry I should have been more clear, the conformance tests are not related to the UX, it is to ensure the runtime is accurate so that proto and json serialization interop with other language implementations is accurate among other protobuf features.

So I'm thinking it might not be worth spending time writing detailed issues about it since it is quite a fundamental design choice that probably is not easy to change? I'm afraid that issue would end up in an endless discussion of what is idomatic :-)

Again sorry about the confusion, the issue I was referring to was for connect-es to support alternate runtimes like ts-proto. So no time will be spent on whats idiomatic, if connect-es can support multiple runtimes then everyone can use the one they like.

[jonaskello]

Aha, so "runtime" here refers just to the serialization and types? Then yes I would agree that making it possible for connect-es to use any serialization and types (eg. from ts-proto) would solve this problem.