Return promises from service client methods about ts-protoc-gen HOT 14 CLOSED

Maybe we could re-open this discussion now that the official client supports promise clients?

Obviously feature parity isn't a req but would be a shame to see a departure of new users over lower level usability stuff like this.

from ts-protoc-gen.

Just bumping this as there has been no further response from the community.

My current thinking is that we should mirror the node-grpc API for now to make migration pain free.

If you would like to see a Promise/Observable API then I would suggest we either:

1. Put it behind a feature flag so users of ts-protoc-gen have to opt into it.
2. Create a new package/repo which wraps the current API (this could then be used for both grpc-web and node-grpc) and we can mention it in the README

Let me know your thoughts

from ts-protoc-gen.

I'm on the fence.

Supporting this change is the evidence that Promises replacing callbacks appears to be the future, see this relevant discussion on StackOverflow: https://stackoverflow.com/questions/30299613/why-does-nodejs-not-use-promise-for-the-readfile-api

My concern with this approach is that we make a breaking change from the official nodejs gRPC API which returns a ClientUnaryCall instance which can be used to abort requests and access grpc Metadata on successful calls (note this API has yet to be implemented in ts-protoc-gen)

If we return a Promise from unary invocations then we will also need to provide an API for these use cases. We will also need to be comfortable with the fact that users who adopt grpc-web as their transport layer may face a difficult migration to the official nodejs gRPC API when it also supports Browser based environments (see grpc/grpc-web#91) and/if the grpc-web project is deprecated.

Thoughts and suggestions welcome 😀

from ts-protoc-gen.

@bhollis How would you handle the case where a request returns a stream of messages but you want to react to them immediately when they arrive rather than when the whole stream finishes? This is one of the reasons promises are not particularly suitable for this job as we need to be able to return a value multiple times which Promises do not allow.

from ts-protoc-gen.

That's fair - Observables would be better, but they're only a proposal right now. I was mostly thinking it'd be nice for unary calls, but I can always build my own Promise/Observable wrappers around the callback-driven code.

from ts-protoc-gen.

We have been using https://github.com/bojand/grpc-caller to promisify the GRPC calls. Having ts-protoc-gen generates a typescript definition with Promises would help. At the moment, we have to hardcode it manually which requires more updates than we want to when modifying the proto files.

from ts-protoc-gen.

@manu-st I'd be willing to consider a patch which generates promises, however it would need to be behind a protoc-gen feature flag

from ts-protoc-gen.

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.

from ts-protoc-gen.

Bump?

from ts-protoc-gen.

Thanks for bumping this issue @clanstyles, let me try and bring some closure.

As discussed in a handful of other issues, it's my current belief that ts-protoc-gen should be built around callbacks and event handlers. Other abstractions on top of these concepts (or: Promises and Observables) can be created by the community, presumably as a wrapper, ie:

promisify(myClient.doUnary, myMetadata)
  .then(response => /* … */)
  .catch(err => /* … */)

My rationale is that I would like to keep ts-protoc-gen's API surface area as small as possible to make it easier to maintain.

from ts-protoc-gen.

can this be reopend?

from ts-protoc-gen.

Maybe we could re-open this discussion now that the official client supports promise clients?

Agree

from ts-protoc-gen.

Big agree. Since the official client supports promises we should generate the types.

from ts-protoc-gen.

2023, still no promise client :D

from ts-protoc-gen.