int64 in nestjs grpc converted into long object

[sczrz]

happen in both request and response

"quantity": {
   "low": 100,
   "high": 0,
   "unsigned": false
},

[sczrz]

how can we make it into integer

[stephenh]

@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]

@sczrz

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

See here and here.

[stephenh]

@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?".