[Js/Ts/Node.js] Questions on the state of the Js/Ts implementation

[andre...@gmail.com]

Hello all,
I am currently evaluating gRPC for an IoT type application. We currently have several microservices written in Js that talk a custom protocol but we want to move on to Typescript and a standard RPC mechanism.

I have quiet a few questions on the state of the gRPC/Node.js project and implementation:

1 | What is the relationship of the projects on https://github.com/grpc/grpc and https://github.com/grpc/grpc-node? Where should I file Node.js or Js specific issues or PRs?

2 | What is the relationship of grpc-node and protobuf.js? The grpc-native-core package has a dependency on an outdated protobuf version (^5.0.0) but from what I gather from grpc-protobufjs, it can somehow also deal with protobuf.js 6. How does that work? To me this kind of flexibility seems to make the project overly complex. Also, looking into https://github.com/grpc/grpc-node/issues/15 gives me the impression, that protobuf.js 6 is not fully supported yet.

3 | Code generation: Both grpc-tools and protobuf.js contain a code generator. My impression is that the grpc-tools generator generates only service files, while the one from protobuf.js also generates stubs for message definitions (and also Typescript definitions in v6.8). How are these supposed to be used together? Are there any plans to make this easier and more coherent?

4 | Typescript: I think it would not be too hard to generate Ts definition files alongside the Js files, all relevant type information is here. I currently have manually written definition files for my message types and services, but those need a few modification to grpc-native-core/index.d.ts. There are a lot of missed opportunities in type safety here, falling back to the 'any' type, when a generic parameter would work. But before tackling this area, I need to have the previous questions answered. Also, is there any general interest in this area from other people? Are there any plans to make the Typescript integration better?

5 | There should be more documentation, particularily:
    * how does grpc-node interact with protobuf.js
    * what is generated from the protoc plugin
    * a roadmap
    * what is currently worked on

Best,
André

[Michael Lumish]

1. Recently, development on the Node gRPC implementation has moved entirely to https://github.com/grpc/grpc-node. Issues and PRs specifically related to the Node implementation should be filed there. It is still implemented using code in grpc/grpc, so it has a submodule reference to that repository.
2. Node gRPC currently depends on protobuf.js 5, and because of how some of its APIs are re-exposed in gRPC's API, it cannot be updated without a breaking change. The grpc-protobufjs package is part of a larger project that will involve that package replacing the direct dependency on Protobuf.js.
3. The grpc-tools package is a redistribution of the protoc-based code generator, including protoc itself. It will in fact generate both messages and services if you pass the right arguments, and the service definitions won't work without the message definitions. That package exists primarily to provide a code generation experience similar to what is available for other languages. To be clear, it is not supposed to be used with the Protobuf.js-based code generation; it is an alternate option for accomplishing the same goal. The primary difference between the two is that the grpc-tools/protoc generator is a standalone executable that generates JS files, while the Protobuf.js generator generates JS objects and class definitions at runtime.
4. We've only recently started exploring the use of TypeScript in gRPC, so we haven't looked into generating TS definition files for service definitions from the protoc-based generator. I agree that such a thing would be useful, but I think it would be significantly more useful if and when protoc itself generates TS definitions for message descriptor files. That code lives in http://github.com/google/protobuf and is maintained by a different team.
5. I agree with you that it would be an improvement to document those things that you mention. I expect that we will be able to publish a roadmap some time within the next month or so.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/a26ea87b-08c2-4e83-b14d-82cec7fab2e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[andre...@gmail.com]

Thank you very much,

a few small follow-up question:

* Are the grpc-native and grpc-js versions supposed to be drop-in replacements or might their APIs divert in the future?

* What parts are currently missing from the JS version? 

Thanks in advance,

André

[Michael Lumish]

In the long run, grpc-native and grpc-js are supposed to be drop-in replacements to the greatest extent possible. Because that is not the case, we are planning a "capabilities" system to allow people to use them as drop-in replacements if they only need the features that both implement.

There are several parts missing from the pure JavaScript version. This is not an exhaustive list:

• All of the server code
• Compression support
• Client-side load balancing
• Census integration (though that's its own complicated topic)

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/92007dc8-857d-46e4-a928-84bd286d6de6%40googlegroups.com.