would it make sense to rename gRPC decorators?

[ticmaidev]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

As of now, we got 2 decorators for servers:

• @GrpcMethod()
• @GrpcStreamMethod()

This second decorator might suggest this is the only option for using streams.

Although, this is not the case. Me and other people have learnt it only after a searching on the web.

Describe the solution you'd like

I would like to propose renaming the full-duplex corresponding decorator:

1. @GrpcBidirectionalMethod()
2. @GrpcFullDuplexMethod()

or renaming the 2 different decorators:

1. @GrpcSimplexMethod()
2. @GrpcFullDuplexMethod()

or...

1. @GrpcOneWayChannel()
2. @GrpcTwoWayChannel()

Teachability, documentation, adoption, migration strategy

Users would simply adopt the new names.

What is the motivation / use case for changing the behavior?

I've spent a half a day trying to figure out why streams woudn't work.

One of the reasons for that is because these decorators names are deceiving and I was trying to implement full-duplex communication when I actually only needed one way communication with streams.

Another good improvement might be: adding a note about using the "stream" keyword on protobuf files when dealing with "Subject Strategy".

[ticmaidev]

Documentation could also benefit from an example on how to work with one way communication with streams.

[kamilmysliwiec]

Thanks for your suggestion!

This has been discussed in the past and we decided to not introduce this breaking change in the foreseeable future.

If you think your request could live outside Nest's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.