Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for generating grpc-node service types #193

Merged
merged 10 commits into from
Aug 29, 2019

Conversation

esilkensen
Copy link
Contributor

@esilkensen esilkensen commented Aug 5, 2019

Changes

This PR adds support for generating grpc-node service types (see #75, #42, #27):

Verification

To facilitate testing of the service options and the new service=grpc-node option in particular, the generate.sh script has been modified following #75 (comment):

  • examples/generated contains the output when the service option is not used
  • examples/generated-grpc-web contains the output for the service=grpc-web option
  • examples/generated-grpc-node contains the output for the service=grpc-node option

The generate.sh script uses grpc-tools to generate _grpc_pb.js implementation files to help test that the generated _grpc_pb.d.ts files are consistent with them.

@esilkensen esilkensen force-pushed the grpc-node-services branch 3 times, most recently from 1f95c2c to c66fcde Compare August 5, 2019 21:59
@esilkensen esilkensen marked this pull request as ready for review August 9, 2019 06:59

export const SimpleServiceService: ISimpleServiceService;

export class SimpleServiceClient extends grpc.Client {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example of one of the generated grpc-node service types

"lodash": "^4.17.5",
"lodash.isequal": "^4.5.0",
"minimist": "^1.2.0",
"mocha": "^5.2.0",
"mocha-spec-json-output-reporter": "^1.1.6",
"source-map-support": "^0.4.18",
"ts-node": "^5.0.1",
"ts-node": "^8.3.0",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I was working on this, it seemed that ts-node 5.0.1 wasn't catching type errors in test/integration/service/grpcnode.ts - I tried updating to the latest 8.3.0 and then it did catch them and would cause npm run test to fail, as expected.

@@ -46,13 +46,15 @@
"babel": "^6.5.2",
"browser-headers": "^0.4.1",
"chai": "^3.5.0",
"grpc": "^1.22.2",
Copy link
Contributor Author

@esilkensen esilkensen Aug 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this package ok here in "devDependencies" even though it's imported in the generated _grpc_pb.d.ts files?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep should be fine, I see you are only consuming the grpc package in your tests (hence a dev dependency) so shouldn't cause an issue for consumers.

}
}

export class GrpcServiceDescriptor {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is unchanged code extracted from grpcweb.ts - except for renaming this class from GrpcWebServiceDescriptor to GrpcServiceDescriptor since it wasn't necessarily specific to grpc-web.

@@ -19,7 +19,7 @@ fi
mocha \
--reporter mocha-spec-json-output-reporter \
--reporter-options "fileName=./test/mocha-report.json" \
--require ts-node/register/type-check \
--require ts-node/register \
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type-check is the default behavior in the newer ts-node

@esilkensen
Copy link
Contributor Author

Hi @jonny-improbable 👋

I wondered if this is still a feature you think is worth pursuing?

If so, I think this PR is potentially ready for a review. Whenever you have a chance to take a look, if there's anything I can do to help make it easier to review, I will be happy to do that.

(I wondered about breaking off an initial PR that did nothing but adding that examples/grpc-web-services directory, in the interest of shrinking the diff...)

Anyway, sorry to @ ping you - I'll look forward to any next steps to take with this PR, and of course will understand if this just isn't a path for this project to go down.

Cheers!

Copy link
Contributor

@jonny-improbable jonny-improbable left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I like your approach; and from experience I can imagine this was a lot of work!

Some thoughts in no particular order.

  1. Migration Path; I feel that it's important we provide a migration path for users; if we land this change as is, ts-protoc-gen with the service=true flag will no longer emit gprc-web client stubs which may be confusing for consumers. Can I suggest you add some logic to detect the usage of service=true, and emit a prominent message that this functionality will be deprecated and the consumer must change their usage of protoc.

  2. Ownership; are you able to commit to triaging issues that may arise from people using this code? I am not a consumer of 'node grpc' myself so will need help here.

  3. Placement; see RFC: The future of this package #145, I would actually prefer if this package went away however as you can see I haven't made much progress on this issue (and it got automatically closed, sorry about that!). Note that https://github.com/agreatfool/grpc_tools_node_protoc_ts appears to already provide gprc-node service creation; perhaps that package provides all the functionality required in which case encouraging users to migrate to https://github.com/agreatfool/grpc_tools_node_protoc_ts may be the better option once protoc-gen-improbable-eng-grpc-web Hello World grpc-web#368 is merged...

Please let me know your thoughts on the above, and sorry for the slow turn around.

@@ -46,13 +46,15 @@
"babel": "^6.5.2",
"browser-headers": "^0.4.1",
"chai": "^3.5.0",
"grpc": "^1.22.2",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep should be fine, I see you are only consuming the grpc package in your tests (hence a dev dependency) so shouldn't cause an issue for consumers.

src/index.ts Outdated
generateGrpcWebService(outputFileName, fileNameToDescriptor[fileName], exportMap)
.forEach(file => codeGenResponse.addFile(file));
}
if (generateGrpcNodeServices) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be else if to reflect the fact that it's not possible to emit both grpc-web and grpc-node services at the same time.

@@ -44,31 +44,40 @@ describe("service/grpc-web", () => {
assert.strictEqual(SimpleService.DoClientStream.responseType, Empty);
});

it("should contain the expected DoClientStream method", () => {
it("should contain the expected DoBidiStream method", () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙏

@esilkensen
Copy link
Contributor Author

esilkensen commented Aug 15, 2019

Thanks Jonny!

  1. Migration Path; I pushed a change that preserves the behavior for service=true, but logs a warning that it has been deprecated and service=grpc-web should be used instead.

  2. Ownership; I can definitely commit to this. I would be happy to jump on any issues, and also would be using this code personally at work.

  3. Placement; Ah yes, I was looking at RFC: The future of this package #145 and grpc_tools_node_protoc_ts (and this fork of it too) as I was getting started on this PR. I think what you've laid out makes a lot of sense.

I ended up going down this path because:

  • I really like the test/CI coverage in ts-protoc-gen. grpc_tools_node_protoc_ts doesn't have any; I think code was copied from ts-protoc-gen, but certain things like Handling of enums #156 haven't made it in.
  • We're already using ts-protoc-gen, and recently had reason to start using grpc-node services. It'd be super easy to just bump a version number and pass a new service parameter.

Do you think there's a case for adding this functionality to ts-protoc-gen, for however much current users of the package may get out of it, with the understanding that you would still be pursuing #145 and these grpc-node services wouldn't be part of the plans going forward?

If so, I'd reiterate my commitment to owning any issues related to this code. But if not, I certainly understand, and could look at contributing and migrating to that other project instead.

(Thanks for the pointer to that ts-morph library, looks cool!)

@jonny-improbable
Copy link
Contributor

Morning @esilkensen,

Thanks for answers my questions above; it looks like we are all set! Sorry to be a pain, but I've just landed #195 which has caused a number of conflicts, in particular around the way the example protos are generated. Please could you resolve these and then we will be good to merge.

@esilkensen
Copy link
Contributor Author

Sounds good, thanks so much @jonny-improbable,

I've just resolved the conflicts and will watch to make sure CI passes.

(Then head to bed, it is early morning for me 😴)

@esilkensen
Copy link
Contributor Author

Hi @jonny-improbable, I just wanted to check back in on this PR, to see if you were still thinking of merging it -- or if there are any additional changes I could make? Thanks again!

Copy link
Contributor

@jonny-improbable jonny-improbable left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's do this.

@jonny-improbable jonny-improbable merged commit 005b479 into improbable-eng:master Aug 29, 2019
@esilkensen esilkensen deleted the grpc-node-services branch August 30, 2019 06:40
@esilkensen
Copy link
Contributor Author

Nice!

What do you think about versioning? Will this eventually make it into a 0.10.1 release?

(I'll pull from ts-protoc-gen@next in the meantime)

@jonny-improbable
Copy link
Contributor

jonny-improbable commented Aug 30, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants