Purpose of ts-proto unclear

[robtayl0r]

Struggling to understand what ts-proto does that @grpc/proto-loader does not. I understand that ts-proto depends on @grpc/proto-loader, but proto-loader (specifically it's proto-loader-gen-types script/executable) seems to generate the same TypeScript.

Did this library pre-date the TypeScript generation capabilities of proto-loader?

[stephenh]

Did this library pre-date the TypeScript generation capabilities of proto-loader?

Yes.

ts-proto was originally developed for ~circa-2018 / pre-grpc-ish Twirp/proto3 RPCs, when the only other options were protobuf's built-in JS and protobuf.js's "TypeScript codegen'd from JS comments" approach.

It's since grown to a variety of things, and has a variety of options, which I think the strong point being either:

a) there is likely an existing flag to make output "the way you want", or
b) it's generally/easily hackable to add/change such things if you want

I've not had a chance/reason to look at @grpc/proto-loader, so can't really say much about it. I see that it does code generation, like as it's own completely separate from protoc thing, which is great. If you like it's output, that's great, there is probably no reason to use ts-proto.

[robtayl0r]

Thanks for the great explanation!

On further inspection, it seems @grpc/proto-loader .ts generation lacks the equivalent of ts-proto's DeepPartial. Which, if I understand its purpose, is a really awesome and much needed capability if your proto message definitions are the base and complete representation of object types of whose required/expected fields will change between many contexts.

[stephenh]

@robtayl0r ah nice! I was just thinking, after my reply, I may have undersold some of ts-proto's cooler aspects of fromPartial / the just-landed Exact, and handling of things like well-known-types like StringValue/etc. :-) If you find things you like about ts-proto, that's great, and discussions/PRs to improve things are always appreciated!

[robtayl0r]

Is there a way to use the generated grpc client object's methods with partial messages instead of the complete message (without yielding type errors)? I took a look at examples under ./integration/ but haven't found anything that clicked yet.

Same question for the server implementation too, when I pass a partial in the callback, it's a type error. My use case is mostly fields that are generated, like uuid and timestamps, and don't exist on until insertion. Maybe I'm going about this the wrong way.

const client = new OrganizationsClient('localhost' + port, grpc.credentials.createInsecure());
//@ts-ignore
client.create({name:'Foo'}, (err, res)=>{ })

where {name:'Foo'} literal also has an id field in it's proto message definition.

[robtayl0r]

Ah, I see now.

client.create(Organization.fromPartial({name:'Foo'}), (err, res)=>{ })

[stephenh]

@robtayl0r ah yeah, the grpc-web output accepts partials directly, i.e. you can call client.create({foo: name}), and the create method that it generates internally calls fromPartial. Looks like we just haven't done that for the grpc-js output. That'd be a good improvement if you're interested in submitting a PR.