better nestjs support

[toonvanstrijp]

This pull request is discussed in #59, please see this issue for more context.

Let me know if anything needs to be changed. This pull request will be a breaking change, since we changed the output when the nestJs=true option is set.

I've changed/improved the following:

1. I added an nestjs section to the readme file: https://github.com/debugged-software/ts-proto#nestjs
2. It generated two interfaces, 1 for the client and 1 for the server. (only when nestjs=true)
3. I also added a naming convention for the interfaces in nestjs.
4. I created two dedicated functions for creating the server interface and the client interface. This way we can easily change the way how we build the interfaces for nestjs. (generateNestjsService and generateNestjsServiceClient).
5. when nestjs=true it also generates an class decorator for example HeroServiceControllerMethods (based on the name of the service). Normally in nestjs you would need to add @GrpcMethod('SERVICE_NAME') or @GrpcStreamMethod('SERVICE_NAME'). This however would fail in runtime when you accidentally change your service name. But because we generate this class decorator for you, you won't have this risk anymore. The only thing you need to do is provide this decorator on the controller class. The decorator will take care of applying the @GrpcMethod and @GrpcStreamMethod

@Controller('hero')
// Generated decorator that applies all the @GrpcMethod and @GrpcStreamMethod to the right methods
@HeroServiceControllerMethods()
export class HeroController implements HeroServiceController {
...
}

6. based on the .proto we'll generate a const for example HERO_PACKAGE_NAME and HERO_SERVICE_NAME this way your code breaks if you change your package or service name. (It's safer to have compiler errors than runtime errors)

[stephenh]

Few super minor comments but really looks great. @toonvanstrijp let me know once/if you want to address any of my nudges and I'll go ahead and merge it.

[stephenh]

Not quite following this? Would it hurt to just always export the const? Even if the user, should their service end with service doesn't technically need it, it's there for consistency?

[iangregsondev]

Ah I quite like that, @stephenh i think its explained here

Note: Based on the .proto we'll generate a const for example HERO_PACKAGE_NAME and HERO_SERVICE_NAME this way your code breaks if you change your package or service name. (It's safer to have compiler errors than runtime errors)

[toonvanstrijp]

@stephenh This way we offer more consistency in the naming. If the user happened to have a service inside their .proto named: hero then it would end up as HERO_NAME. We could do it without forcing the SERVICE in here but this also makes me think. If we go for this approach we also should force the service in the controller and client interface name?

@stephenh, @iangregsondev let me know what you guys think is a better approach.

[stephenh]

Ah okay.

If we go for this approach we also should force the service in the
controller and client interface name?

Eh, I could go either way. I think what you have now is fine (i.e. don't force Service into the interface names).

Most users probably do have Service as a suffix of their service names anyway? Or maybe they prefer something like HeroRpc (just making something up, but some other suffix that is "like service") so by assuming "oh you must want Service suffixed", we'd be doing the wrong thing.

Better to make less assumptions I think.

In that vein, I'm tempted to nudge the "does name end in service" check here out to be consistent, i.e. maybe they want would HERO_RPC_NAME 🤷 .

(I agree having service Hero is kind of odd, so I'm assuming most users won't do that.)

[toonvanstrijp]

Either HeroRpc or HeroService look fine to me but I prefer HeroService since it's a service inside the proto.

Also I think we should no force the user to much as you said.

So we can resolve this issue and leave it as it is now?

[toonvanstrijp]

@stephenh I fixed some of the changes you requested, and commented on the changes that need more info.

[toonvanstrijp]

@stephenh @iangregsondev please review this also: 93a4b28