docs(content): Pluralise class names

Fix #1176

According to @kamilmysliwiec, "plural form is recommended".

I updated some of the singularly named classes and updated them, along
with file names.

Signed-off-by: Stanislas Lange <[email protected]>

Author: angristan

content/microservices/grpc.md

@@ -90,15 +90,15 @@ The <strong>gRPC</strong> transporter options object exposes the properties desc
 
 #### Sample gRPC service
 
-Let's define our sample gRPC service called `HeroService`. In the above `options` object, the`protoPath` property sets a path to the `.proto` definitions file `hero.proto`. The `hero.proto` file is structured using <a href="https://developers.google.com/protocol-buffers">protocol buffers</a>. Here's what it looks like:
+Let's define our sample gRPC service called `HeroesService`. In the above `options` object, the`protoPath` property sets a path to the `.proto` definitions file `hero.proto`. The `hero.proto` file is structured using <a href="https://developers.google.com/protocol-buffers">protocol buffers</a>. Here's what it looks like:
 
 ```typescript
 // hero/hero.proto
 syntax = "proto3";
 
 package hero;
 
-service HeroService {
+service HeroesService {
   rpc FindOne (HeroById) returns (Hero) {}
 }
 
@@ -112,17 +112,17 @@ message Hero {
 }
 ```
 
-Our `HeroService` exposes a `FindOne()` method. This method expects an input argument of type `HeroById` and returns a `Hero` message (protocol buffers use `message` elements to define both parameter types and return types).
+Our `HeroesService` exposes a `FindOne()` method. This method expects an input argument of type `HeroById` and returns a `Hero` message (protocol buffers use `message` elements to define both parameter types and return types).
 
 Next, we need to implement the service. To define a handler that fulfills this definition, we use the `@GrpcMethod()` decorator in a controller, as shown below. This decorator provides the metadata needed to declare a method as a gRPC service method.
 
 > info **Hint** The `@MessagePattern()` decorator (<a href="microservices/basics#request-response">read more</a>) introduced in previous microservices chapters is not used with gRPC-based microservices. The `@GrpcMethod()` decorator effectively takes its place for gRPC-based microservices.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Controller()
-export class HeroController {
-  @GrpcMethod('HeroService', 'FindOne')
+export class HeroesController {
+  @GrpcMethod('HeroesService', 'FindOne')
   findOne(data: HeroById, metadata: any): Hero {
     const items = [
       { id: 1, name: 'John' },
@@ -133,8 +133,8 @@ export class HeroController {
 }
 @@switch
 @Controller()
-export class HeroController {
-  @GrpcMethod('HeroService', 'FindOne')
+export class HeroesController {
+  @GrpcMethod('HeroesService', 'FindOne')
   findOne(data, metadata) {
     const items = [
       { id: 1, name: 'John' },
@@ -147,17 +147,17 @@ export class HeroController {
 
 > info **Hint** The `@GrpcMethod()` decorator is imported from the `@nestjs/microservices` package.
 
-The decorator shown above takes two arguments. The first is the service name (e.g., `'HeroService'`), corresponding to the `HeroService` service definition in `hero.proto`. The second (the string `'FindOne'`) corresponds to the `FindOne()` rpc method defined within `HeroService` in the `hero.proto` file.
+The decorator shown above takes two arguments. The first is the service name (e.g., `'HeroesService'`), corresponding to the `HeroesService` service definition in `hero.proto`. The second (the string `'FindOne'`) corresponds to the `FindOne()` rpc method defined within `HeroesService` in the `hero.proto` file.
 
 The `findOne()` handler method takes two arguments, the `data` passed from the caller and `metadata` that stores gRPC request metadata.
 
 Both `@GrpcMethod()` decorator arguments are optional. If called without the second argument (e.g., `'FindOne'`), Nest will automatically associate the `.proto` file rpc method with the handler based on converting the handler name to upper camel case (e.g., the `findOne` handler is associated with the `FindOne` rpc call definition). This is shown below.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Controller()
-export class HeroController {
-  @GrpcMethod('HeroService')
+export class HeroesController {
+  @GrpcMethod('HeroesService')
   findOne(data: HeroById, metadata: any): Hero {
     const items = [
       { id: 1, name: 'John' },
@@ -168,8 +168,8 @@ export class HeroController {
 }
 @@switch
 @Controller()
-export class HeroController {
-  @GrpcMethod('HeroService')
+export class HeroesController {
+  @GrpcMethod('HeroesService')
   findOne(data, metadata) {
     const items = [
       { id: 1, name: 'John' },
@@ -180,12 +180,12 @@ export class HeroController {
 }
 ```
 
-You can also omit the first `@GrpcMethod()` argument. In this case, Nest automatically associates the handler with the service definition from the proto definitions file based on the **class** name where the handler is defined. For example, in the following code, class `HeroService` associates its handler methods with the `HeroService` service definition in the `hero.proto` file based on the matching of the name `'HeroService'`.
+You can also omit the first `@GrpcMethod()` argument. In this case, Nest automatically associates the handler with the service definition from the proto definitions file based on the **class** name where the handler is defined. For example, in the following code, class `HeroesService` associates its handler methods with the `HeroesService` service definition in the `hero.proto` file based on the matching of the name `'HeroesService'`.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Controller()
-export class HeroService {
+export class HeroesService {
   @GrpcMethod()
   findOne(data: HeroById, metadata: any): Hero {
     const items = [
@@ -197,7 +197,7 @@ export class HeroService {
 }
 @@switch
 @Controller()
-export class HeroService {
+export class HeroesService {
   @GrpcMethod()
   findOne(data, metadata) {
     const items = [
@@ -237,12 +237,12 @@ Once registered, we can inject the configured `ClientGrpc` object with `@Inject(
 ```typescript
 @Injectable()
 export class AppService implements OnModuleInit {
-  private heroService: HeroService;
+  private heroService: HeroesService;
 
   constructor(@Inject('HERO_PACKAGE') private client: ClientGrpc) {}
 
   onModuleInit() {
-    this.heroService = this.client.getService<HeroService>('HeroService');
+    this.heroService = this.client.getService<HeroesService>('HeroesService');
   }
 
   getHero(): Observable<string> {
@@ -267,10 +267,10 @@ export class AppService implements OnModuleInit {
   })
   client: ClientGrpc;
 
-  private heroService: HeroService;
+  private heroService: HeroesService;
 
   onModuleInit() {
-    this.heroService = this.client.getService<HeroService>('HeroService');
+    this.heroService = this.client.getService<HeroesService>('HeroesService');
   }
 
   getHero(): Observable<string> {
@@ -281,20 +281,20 @@ export class AppService implements OnModuleInit {
 
 Finally, for more complex scenarios, we can inject a dynamically configured client using the `ClientProxyFactory` class as described <a href="/microservices/basics#client">here</a>.
 
-In either case, we end up with a reference to our `HeroService` proxy object, which exposes the same set of methods that are defined inside the `.proto` file. Now, when we access this proxy object (i.e., `heroService`), the gRPC system automatically serializes requests, forwards them to the remote system, returns a response, and deserializes the response. Because gRPC shields us from these network communication details, `heroService` looks and acts like a local provider.
+In either case, we end up with a reference to our `HeroesService` proxy object, which exposes the same set of methods that are defined inside the `.proto` file. Now, when we access this proxy object (i.e., `heroService`), the gRPC system automatically serializes requests, forwards them to the remote system, returns a response, and deserializes the response. Because gRPC shields us from these network communication details, `heroService` looks and acts like a local provider.
 
-Note, all service methods are **lower camel cased** (in order to follow the natural convention of the language). So, for example, while our `.proto` file `HeroService` definition contains the `FindOne()` function, the `heroService` instance will provide the `findOne()` method.
+Note, all service methods are **lower camel cased** (in order to follow the natural convention of the language). So, for example, while our `.proto` file `HeroesService` definition contains the `FindOne()` function, the `heroService` instance will provide the `findOne()` method.
 
 ```typescript
-interface HeroService {
+interface HeroesService {
   findOne(data: { id: number }): Observable<any>;
 }
 ```
 
 A message handler is also able to return an `Observable`, in which case the result values will be emitted until the stream is completed.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Get()
 call(): Observable<any> {
   return this.heroService.findOne({ id: 1 });

content/microservices/kafka.md

@@ -168,7 +168,7 @@ client: ClientKafka;
 The `ClientKafka` class provides the `subscribeToResponseOf()` method. The `subscribeToResponseOf()` method takes a request's topic name as an argument and adds the derived reply topic name to a collection of reply topics. This method is required when implementing the message pattern.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 onModuleInit() {
   this.client.subscribeToResponseOf('hero.kill.dragon');
 }
@@ -177,7 +177,7 @@ onModuleInit() {
 If the `ClientKafka` instance is created asynchronously, the `subscribeToResponseOf()` method must be called before calling the `connect()` method.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 async onModuleInit() {
   this.client.subscribeToResponseOf('hero.kill.dragon');
   await this.client.connect();
@@ -205,9 +205,9 @@ Nest receives incoming Kafka messages as an object with `key`, `value`, and `hea
 Nest sends outgoing Kafka messages after a serialization process when publishing events or sending messages. This occurs on arguments passed to the `ClientKafka` `emit()` and `send()` methods or on values returned from a `@MessagePattern` method. This serialization "stringifies" objects that are not strings or buffers by using `JSON.stringify()` or the `toString()` prototype method.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Controller()
-export class HeroController {
+export class HeroesController {
   @MessagePattern('hero.kill.dragon')
   killDragon(@Payload() message: KillDragonMessage): any {
     const dragonId = message.dragonId;
@@ -225,9 +225,9 @@ export class HeroController {
 Outgoing messages can also be keyed by passing an object with the `key` and `value` properties. Keying messages is important for meeting the [co-partitioning requirement](https://docs.confluent.io/current/ksql/docs/developer-guide/partition-data.html#co-partitioning-requirements).
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Controller()
-export class HeroController {
+export class HeroesController {
   @MessagePattern('hero.kill.dragon')
   killDragon(@Payload() message: KillDragonMessage): any {
     const realm = 'Nest';
@@ -253,9 +253,9 @@ export class HeroController {
 Additionally, messages passed in this format can also contain custom headers set in the `headers` hash property. Header hash property values must be either of type `string` or type `Buffer`.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Controller()
-export class HeroController {
+export class HeroesController {
   @MessagePattern('hero.kill.dragon')
   killDragon(@Payload() message: KillDragonMessage): any {
     const realm = 'Nest';
@@ -355,7 +355,7 @@ const app = await NestFactory.createMicroservice(ApplicationModule, {
 And for the client:
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 @Client({
   transport: Transport.KAFKA,
   options: {
@@ -376,7 +376,7 @@ client: ClientKafka;
 Since the Kafka microservice message pattern utilizes two topics for the request and reply channels, a reply pattern should be derived from the request topic. By default, the name of the reply topic is the composite of the request topic name with `.reply` appended.
 
 ```typescript
-@@filename(hero.controller)
+@@filename(heroes.controller)
 onModuleInit() {
   this.client.subscribeToResponseOf('hero.get'); // hero.get.reply
 }

content/techniques/authentication.md

@@ -264,7 +264,7 @@ We've followed the recipe described earlier for all Passport strategies. In our
 
 We've also implemented the `validate()` method. For each strategy, Passport will call the verify function (implemented with the `validate()` method in `@nestjs/passport`) using an appropriate strategy-specific set of parameters. For the local-strategy, Passport expects a `validate()` method with the following signature: `validate(username: string, password:string): any`.
 
-Most of the validation work is done in our `AuthService` (with the help of our `UserService`), so this method is quite straightforward. The `validate()` method for **any** Passport strategy will follow a similar pattern, varying only in the details of how credentials are represented. If a user is found and the credentials are valid, the user is returned so Passport can complete its tasks (e.g., creating the `user` property on the `Request` object), and the request handling pipeline can continue. If it's not found, we throw an exception and let our <a href="exception-filters">exceptions layer</a> handle it.
+Most of the validation work is done in our `AuthService` (with the help of our `UsersService`), so this method is quite straightforward. The `validate()` method for **any** Passport strategy will follow a similar pattern, varying only in the details of how credentials are represented. If a user is found and the credentials are valid, the user is returned so Passport can complete its tasks (e.g., creating the `user` property on the `Request` object), and the request handling pipeline can continue. If it's not found, we throw an exception and let our <a href="exception-filters">exceptions layer</a> handle it.
 
 Typically, the only significant difference in the `validate()` method for each strategy is **how** you determine if a user exists and is valid. For example, in a JWT strategy, depending on requirements, we may evaluate whether the `userId` carried in the decoded token matches a record in our user database, or matches a list of revoked tokens. Hence, this pattern of sub-classing and implementing strategy-specific validation is consistent, elegant and extensible.
 
@@ -959,6 +959,6 @@ To use above decorator in your resolver, be sure to include it as a parameter of
 @Query(returns => User)
 @UseGuards(GqlAuthGuard)
 whoAmI(@CurrentUser() user: User) {
-  return this.userService.findById(user.id);
+  return this.UsersService.findById(user.id);
 }
 ```

content/techniques/sql.md

@@ -229,7 +229,7 @@ import { User } from './user.entity';
 
 @Injectable()
 @Dependencies(getRepositoryToken(User))
-export class UserService {
+export class UsersService {
   constructor(usersRepository) {
     this.usersRepository = usersRepository;
   }
@@ -272,13 +272,13 @@ Now if we import `UsersModule` in `UserHttpModule`, we can use `@InjectRepositor
 @@filename(users-http.module)
 import { Module } from '@nestjs/common';
 import { UsersModule } from './user.module';
-import { UserService } from './user.service';
-import { UserController } from './user.controller';
+import { UsersService } from './users.service';
+import { UsersController } from './users.controller';
 
 @Module({
   imports: [UsersModule],
-  providers: [UserService],
-  controllers: [UserController]
+  providers: [UsersService],
+  controllers: [UsersController]
 })
 export class UserHttpModule {}
 ```
@@ -543,7 +543,7 @@ The `@nestjs/typeorm` package exposes the `getRepositoryToken()` function which
 ```typescript
 @Module({
   providers: [
-    UserService,
+    UsersService,
     {
       provide: getRepositoryToken(User),
       useValue: mockRepository,
@@ -553,7 +553,7 @@ The `@nestjs/typeorm` package exposes the `getRepositoryToken()` function which
 export class UsersModule {}
 ```
 
-Now a substitute `mockRepository` will be used as the `UserRepository`. Whenever any class asks for `UserRepository` using an `@InjectRepository()` decorator, Nest will use the registered `mockRepository` object.
+Now a substitute `mockRepository` will be used as the `UsersRepository`. Whenever any class asks for `UsersRepository` using an `@InjectRepository()` decorator, Nest will use the registered `mockRepository` object.
 
 #### Custom repository
 
@@ -862,7 +862,7 @@ import { User } from './user.model';
 
 @Injectable()
 @Dependencies(getModelToken(User))
-export class UserService {
+export class UsersService {
   constructor(usersRepository) {
     this.usersRepository = usersRepository;
   }
@@ -910,13 +910,13 @@ Now if we import `UsersModule` in `UserHttpModule`, we can use `@InjectModel(Use
 @@filename(users-http.module)
 import { Module } from '@nestjs/common';
 import { UsersModule } from './user.module';
-import { UserService } from './user.service';
-import { UserController } from './user.controller';
+import { UsersService } from './users.service';
+import { UsersController } from './users.controller';
 
 @Module({
   imports: [UsersModule],
-  providers: [UserService],
-  controllers: [UserController]
+  providers: [UsersService],
+  controllers: [UsersController]
 })
 export class UserHttpModule {}
 ```
@@ -1112,7 +1112,7 @@ The `@nestjs/sequelize` package exposes the `getModelToken()` function which ret
 ```typescript
 @Module({
   providers: [
-    UserService,
+    UsersService,
     {
       provide: getModelToken(User),
       useValue: mockModel,