Ability to generate typings for grpc-node service files

[Junkern]

This PR is by far from being finished, I opened it anyway to allow some discussion.

Also #74 should be merged first in order to npm run-script build again.

First of all the current output would be:

import * as orphan_pb from "./orphan_pb";
import * as grpc from "grpc";

type OrphanServiceDoUnary = {
  readonly methodName: string;
  readonly service: typeof OrphanService;
  readonly requestStream: false;
  readonly responseStream: false;
  readonly requestType: typeof orphan_pb.OrphanUnaryRequest;
  readonly responseType: typeof orphan_pb.OrphanMessage;
};

type OrphanServiceDoStream = {
  readonly methodName: string;
  readonly service: typeof OrphanService;
  readonly requestStream: false;
  readonly responseStream: true;
  readonly requestType: typeof orphan_pb.OrphanStreamRequest;
  readonly responseType: typeof orphan_pb.OrphanMessage;
};

export class OrphanService {
  static readonly serviceName: string;
  static readonly DoUnary: OrphanServiceDoUnary;
  static readonly DoStream: OrphanServiceDoStream;
}

export type ServiceError = { message: string, code: number; metadata: grpc.Metadata }
export type Status = { details: string, code: number; metadata: grpc.Metadata }

I have two points worth to discuss:

• What should the command look like to differentiate between grpc definition files and grpc-web definitio files? At the moment simply using service=true creates grpc-web files. However, the term "service" also appears in the grpc terminology. Maybe do something like service=grpc and service=grpc-web? Might also lead to confusion. On the other hand, having to commands (e.g. grpc-web=true and grpc=true) will lead to problems like: merge the two d.ts files?

• What type of files do we want to generate? For my use case the service.d.ts (as shown above) file is sufficient. Are service stubs needed?

[jonnyreeves]

What should the command look like to differentiate between grpc definition files and grpc-web definition files?

My vote is on --service=grpc-web and --service=node-grpc

What type of files do we want to generate

If I understand correctly, just the .d.ts files are required as the javascript files are generated by the node-grpc plugin

[MOZGIII]

If I understand correctly, just the .d.ts files are required as the javascript files are generated by the node-grpc plugin.

They are generated, however they don't really have the full code for performing the call, and they heavily rely on the "magical" grpc.makeGenericClientConstructor: https://github.com/grpc/grpc/blob/f2979e32185804ee707ab18da844d74496aeb479/examples/node/static_codegen/route_guide/route_guide_grpc_pb.js#L146

Not sure if this is the right issue to discuss, but I would like to have a golang-like API, because so far I find it the most robust. For unary methods they have a pretty straightforward implementation with usual function that returns a value, and for streaming calls they also have a function that accepts a stream as an argument, and that stream allows for reading and writing messages. The same would be possible with async/await syntax and promises for unary calls, and rxjs (or other observer implementation) for streaming calls.

[Junkern]

My vote is on --service=grpc-web and --service=node-grpc

This sounds good to me as well, I will implement that.

Regarding the "code generation" for grpc-node. I think it really depends on how you internally work with grpc. What I am doing in my service (simplified):

const creds = grpc.credentials.createSsl(cacert, key, cert)
const client = new protoFile.MyService(`${host}:${port}`, creds)

this._client['MyRPCService'](message, metadata, async (err: any, response: any) => {
   // error handling, handling the response and so on
})

I am doing simple calls, no streaming whatsoever. So for me just having a d.ts file is fine, I can enrich then my calls with the types.

However, I also could create JavaScript code which creates small snippets you can call MyService.MyRpcservice() and have all typying in there without having to apply it manually (I hope this makes sense :D):

class MyService {
    MyRPCService(message: RPCMessage, metadata: grpc.Metadata, (err: ServiceError, res: RPCResponseMessage)
}

[Junkern]

Currently writing tests, but I don't really understand the test setup, yet.

I am taking the existin grpc-web test as a reference. In the file (https://github.com/improbable-eng/ts-protoc-gen/blob/master/test/integration/service/grpcweb.ts) we read existing files from the examples folder and check if they contain the correct values?

But when I add now a second grpc-node test, I have to "rebuild" the files in the examples folder by editing the ./generate.sh and then run the tests. But then some tests will fail, because then the examples folder won't contain files needed for the grpc-web tests to succeed.

I think the examples should be seperated from files neede to test the code.

@jonnyreeves

[jonnyreeves]

Maybe we could add subfolders to the examples directory and then modify generate.sh to create them, eg

examples/no-service
examples/grpc-node-services
examples/grpc-web-services

Would this help?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[DanielRamosAcosta]

Is it possible to generate typings for the grpc-node services files?