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é On Friday, November 17, 2017 at 11:07:02 PM UTC+1, Michael Lumish wrote: > > > 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. > > > On Wed, Nov 8, 2017 at 3:16 AM <andre...@gmail.com <javascript:>> wrote: > >> >> 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é >> >> -- >> 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 <javascript:>. >> To post to this group, send email to grp...@googlegroups.com >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/grpc-io/a26ea87b-08c2-4e83-b14d-82cec7fab2e0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/92007dc8-857d-46e4-a928-84bd286d6de6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
