search

stephenh / ts-proto

An idiomatic protobuf generator for TypeScript
Apache License 2.0
2.08k stars 340 forks source link

int64 in nestjs grpc converted into long object #411

Open sczrz opened 2 years ago

sczrz commented 2 years ago

happen in both request and response

"quantity": {
   "low": 100,
   "high": 0,
   "unsigned": false
},
sczrz commented 2 years ago

how can we make it into integer

stephenh commented 2 years ago

@sczrz I am not personally a NestJS user, but I believe the core issue here is that the ts-proto / NestJS integration currently works mostly by structural typing; i.e. ts-proto generates data/messages that match what NestJS expects.

However, once ts-proto does "fancier things" i.e. oneof (see #314) or here Long support, the internal NestJS serialization logic doesn't know about these things, and so you get weird/broken behavior like you're seeing.

Ideally what we need to do is find out how to tell NestJS to use ts-proto's own encode and decode messages for serializing/deserializing bytes on/off the wire.

If you could dig around and figure that out, that'd be great!

jsbrain commented 2 years ago

@sczrz

If I'm not mistaken, you can simply configure this in the grpc loader settings.

See here and here.

stephenh commented 2 years ago

@jsbrain I'm pretty sure those options are for using the proto-loader-gen-types messages and protobuf.js, which ts-proto does not use / is an alternative too.

Like here:

const packageDefinition = protoLoader.loadSync('./proto/example.proto');
const proto = (grpc.loadPackageDefinition(packageDefinition) as unknown) as ProtoGrpcType;
const server = new grpc.Server();
server.addService(proto.example_package.Example.service, exampleServer);

My guess is that the packageDefinition const has the various info about "how to encode/decode" messages that, as-is in their example, go through protobuf.js types, and that we'd want to instead provide a packageDefinition that was ts-proto created and/or ts-proto aware.

I have not looked into what type the grpc.loadPackageDefinition wants to accept, but that is probably what I'd poke at first. And then maybe runtime break points inside of the exampleServer to see what codepaths grpc is taking to get to the server, and from those codepaths find hints about "how did you decide which encode / decode methods to call?".