sample(04-grpc): add independent gRPC Client / Server sample respectively

[youngkiu]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe: Add another gRPC sample

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

https://github.com/youngkiu/nest/blob/sample/34-grpc-client-server/sample/34-grpc-client-server/README.md

• c-2 --> s-2

[1] Calling SayHello with name:""
[1] Received error 3 INVALID_ARGUMENT: request missing required field: name
[2] Calling SayHello with name:"youngkiu"
[2] Received response Hello youngkiu
[3] Calling SayHelloStreamReply with name:""
[3] Received expected error 3 INVALID_ARGUMENT: request missing required field: name
[3] Received status with code=INVALID_ARGUMENT details=request missing required field: name
[4] Calling SayHelloStreamReply with name:"youngkiu"
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received status with code=OK details=OK

• c-2 --> s-3

[1] Calling SayHello with name:""
[1] Received error 3 INVALID_ARGUMENT: request missing required field: name
[2] Calling SayHello with name:"youngkiu"
[2] Received response Hello youngkiu
[3] Calling SayHelloStreamReply with name:""
[3] Received status with code=OK details=OK
[4] Calling SayHelloStreamReply with name:"youngkiu"
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received response Hello youngkiu
[4] Received status with code=OK details=OK

Currently, NestJS Server produces different results.
This will be resolved when #13195 is released.

[coveralls]

Pull Request Test Coverage Report for Build 95db5acc-385b-40ba-8c36-c49c7e046909

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 92.146%

---

Totals
Change from base Build fad5078e-9529-46ad-977e-491c6acb241f:	0.0%
Covered Lines:	6734
Relevant Lines:	7308

---

💛 - Coveralls

[kamilmysliwiec]

I wonder if adding yet another sample to this repository doesn't create even more unnecessary overhead that we already face with updating their dependencies (maintenance burden).

Is there any way we could merge this example with the existing grpc one? If not, I'd recommend creating a separate repository instead

[youngkiu]

1. The original 04-grpc consists of 1, 2, and 3 as one program, so it may be a little confusing for developers who are new to samples.

04-grpc	Client	Server
HTTP		1
gRPC	2	3

2. I wanted to introduce ts-proto to create 04-grpc/src/hero/interfaces more easily,
3. Usually in gRPC, client / server share proto files, so I thought a sample including the case of multiple proto files could be beneficial.

34-grpc-client-server was merged into 04-grpc, but if you still think the management burden is too high, it's okay to close the PR.

[ssilve1989]

Why is this using a ReplaySubject? This can be written in multiple other ways without the need of a ReplaySubject. The most concise of which would be

  sayHelloStreamReply({ name }: HelloRequest): Observable<HelloReply> {
    if (!name) {
      throw new RpcException({
        code: status.INVALID_ARGUMENT,
        message: 'request missing required field: name',
      });
    }

    return of({ message: `Hello ${name}` }).pipe(repeat(this.REPLY_COUNT));
  }

but even, so I would caution showing an example of streaming synchronous replies like this. When the list of emissions is sufficiently large this can block the event loop writing out all the messages not allowing anything else to occur. This often results in health check failures in environments like kubernetes. Ideally each emission is written out asynchronously which can be achieved with scheduled and an async scheduler.

[youngkiu]

Thank you for the code review and suggestions.
I hope the sample code will greatly help developers using nest & grpc.