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) On Fri, Dec 8, 2017 at 7:37 AM <[email protected]> wrote: > 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 <[email protected]> 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 [email protected]. >>> To post to this group, send email to [email protected]. >> >> >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 > <https://groups.google.com/d/msgid/grpc-io/92007dc8-857d-46e4-a928-84bd286d6de6%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 [email protected]. To post to this group, send email to [email protected]. 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/CAPK2-4fofcewfgqdnphfCsAG6aSdJkGJTV3bqE6Cg46kChM2Ow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
