これを解決します。

src/models/user.ts

import { IsNotEmpty, MaxLength } from 'class-validator';
import { Column, PrimaryGeneratedColumn } from 'typeorm';
import { ApiProperty } from '@nestjs/swagger';

export class User {
  @PrimaryGeneratedColumn()
  @ApiProperty({ example: 1 })
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  @Column()
  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  @Column()
  @ApiProperty({ example: 'alice' })
  name!: string;

  @MaxLength(140)
  @Column('text')
  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

この記事は NestJS アドベントカレンダー 2019 18 日目の記事です。

はじめに

NestJS + ClassValidator + TypeORM 、という構成などのときに、上記のような Decorator Hell を想像してしまうことはあると思います。
動くものとしては十分ですが、メンテナンス性を高めるために、 Abstract Class と Interface を活用して分離し、依存関係を整理する一例を紹介します。

https://github.com/nestjs-jp/advent-calendar-2019/tree/master/day18-avoid-decorator-hell

なお、環境は執筆時点での Node.js の LTS である v12.13.x を前提とします。
また、この Decorator の挙動は ECMA Script 仕様として定義されていない Decorator に対して、TypeScript 3.7.x 時点での実装による挙動であるため、将来的に仕様の作成・変更に伴い TypeScript コンパイラの挙動が変更になる可能性があります。

現実装の Decorator の挙動については Decorator と継承 にも書いていますので併せてお読み下さい。

Validator を分離する

export class ValidatableUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

export class User extends ValidatableUser {
  @PrimaryGeneratedColumn()
  @ApiProperty({ example: 1 })
  id!: number;

  @Column()
  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @Column()
  @ApiProperty({ example: 'alice' })
  name!: string;

  @Column('text')
  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

class-validator が継承した Class でも validation ができることを利用し、 validation の定義を親クラスに移譲します。
以下のコードを実行すると、バリデーションエラーが発生します。

import { User } from './src/models/user';
import { validate } from 'class-validator';

async function main() {
  const user = new User();
  user.id = 1;
  user.displayId = 'alice1234567890123456';
  user.name = 'alice';

  const err = await validate(user, { skipMissingProperties: true });
  console.log(err);
}

main().catch(console.error);

API 層を分離する

API レスポンスとして使用される / Swagger のドキュメント生成に使用される Class を別に定義します。

import { IsNotEmpty, MaxLength } from 'class-validator';
import { Column, PrimaryGeneratedColumn } from 'typeorm';
import { ApiProperty } from '@nestjs/swagger';

export class ValidatableUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

export class User extends ValidatableUser {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

type TransferUserType = Omit<User, 'createdAt' | 'updatedAt'>;

export class TransferUser extends User implements TransferUserType {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;
}

src/app.controller.ts

import { Controller, Get, HttpException, Query } from '@nestjs/common';
import { TransferUser } from './models/user';
import { ApiResponse } from '@nestjs/swagger';
import { validate } from 'class-validator';

@Controller()
export class AppController {
  @Get()
  @ApiResponse({ status: 200, type: TransferUser })
  @ApiResponse({ status: 400 })
  async getUser(
    @Query() { displayId, name }: { displayId: string; name: string },
  ): Promise<TransferUser> {
    if (!displayId || !name) {
      throw new HttpException('displayId and name are required', 400);
    }

    const user = new TransferUser();
    user.id = 123;
    user.displayId = displayId;
    user.name = name;

    const errs = await validate(user, { skipMissingProperties: true });

    if (errs.length) {
      console.error(errs);
      throw new HttpException(errs, 400);
    }

    console.log(user);

    return user;
  }
}

$ curl localhost:3000\?displayId=alice07\&name=alice
{"id":123,"displayId":"alice07","name":"alice"}

$ curl localhost:3000\?displayId=alice1234567890123456\&name=alice
[{"target":{"id":123,"displayId":"alice1234567890123456","name":"alice"},"value":"alice1234567890123456","property":"displayId","children":[],"constraints":{"maxLength":"displayId must be shorter than or equal to 16 characters"}}]

TypeORM 層を分離する

次に、 User Class から TypeORM の Decorator を分離します。

import { IsNotEmpty, MaxLength } from 'class-validator';
import { Column, PrimaryGeneratedColumn } from 'typeorm';
import { ApiProperty } from '@nestjs/swagger';

export class ValidatableUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

export class User extends ValidatableUser {
  id!: number;
  displayId!: string;
  name!: string;
  profileText?: string;
  createdAt!: number;
  updatedAt!: number;
}

type SerializableUserType = Omit<User, 'createdAt' | 'updatedAt'>;

export class SerializableUser extends User implements SerializableUserType {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;
}

export class UserEntity extends User {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

ロジックを持ち基底となる Pure な User を用意し、整理する

上記の手順で User Class は class-validator を継承しているため、基底とは言えません。
なので、基底となる、 Decorator のない Pure TypeScript な User Class として定義するよう、継承関係を整理します。
また、ここで実装される toObject メソッドは User を継承した全ての Class で使用できるメソッドになります。

export class User {
  id: number;
  displayId: string;
  name: string;
  profileText?: string;
  createdAt?: number;
  updatedAt?: number;

  constructor({
    id,
    displayId,
    name,
    profileText,
    createdAt,
    updatedAt,
  }: User) {
    this.id = id;
    this.displayId = displayId;
    this.name = name;
    this.profileText = profileText;
    this.createdAt = createdAt;
    this.updatedAt = updatedAt;
  }

  toObject() {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
      createdAt: this.createdAt,
      updatedAt: this.updatedAt,
    };
  }
}

export class ValidatableUser extends User {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

type TransferUserType = Omit<User, 'createdAt' | 'updatedAt'>;

export class TransferUser extends ValidatableUser
  implements TransferUserType {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  toObject() {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
    };
  }
}

export class UserEntity extends ValidatableUser {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

Abstract Class 、 Interface を活用し整理する

最後に、 インスタンス化しないものを Abstract Class 化します。
この Abstract Class も、 toObject された値も、ともに満たす Interface を定義し実装します。

export interface UserInterface {
  id: number;
  displayId: string;
  name: string;
  profileText?: string;
  createdAt?: number;
  updatedAt?: number;
}

export abstract class AbstractUser implements UserInterface {
  id: number;
  displayId: string;
  name: string;
  profileText?: string;
  createdAt?: number;
  updatedAt?: number;

  constructor({
    id,
    displayId,
    name,
    profileText,
    createdAt,
    updatedAt,
  }: UserInterface) {
    this.id = id;
    this.displayId = displayId;
    this.name = name;
    this.profileText = profileText;
    this.createdAt = createdAt;
    this.updatedAt = updatedAt;
  }

  toObject(): UserInterface {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
      createdAt: this.createdAt,
      updatedAt: this.updatedAt,
    };
  }
}

export abstract class ValidatableUser extends AbstractUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt?: number;
  updatedAt?: number;
}

export type TransferUserType = Omit<UserInterface, 'createdAt' | 'updatedAt'>;

export class User extends ValidatableUser {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  toObject() {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
    };
  }
}

export class UserEntity extends ValidatableUser {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt?: number;

  @Column()
  updatedAt?: number;
}

この状態でも、ロジック(Controller にロジックを書くべきではないとは思いますが例なので)側からは自然に見えるように思います。

src/app.controller.ts

@Controller()
export class AppController {
  @Get()
  @ApiResponse({ status: 200, type: User })
  @ApiResponse({ status: 400 })
  async getUser(
    @Query() { displayId, name }: { displayId: string; name: string },
  ): Promise<UserInterface> {
    if (!displayId || !name) {
      throw new HttpException('displayId and name are required', 400);
    }

    const user = new User({ id: 123, displayId, name });

    const errs = await validate(user, { skipMissingProperties: true });

    if (errs.length) {
      console.error(errs);
      throw new HttpException(errs, 400);
    }

    console.log(user);

    return user.toObject();
  }
}

ここまで分離する必要があるかどうかはケースバイケースかと思いますが、 Decorator を提供する複数のライブラリに同時に依存してしまうリスクをある程度排除し、同時にメンテナンス性もある程度担保できるかと思います。

おわりに

NestJS + ClassValidator + TypeORM 、という構成などのときに、 Abstract Class と Interface を活用して Decorator Hell を解消する方法の一例を紹介しました。
この方法が全てのプロジェクトに当てはまるわけではありませんが、参考にしていただければ幸いです。

これを解決します。

src/models/user.ts

import { IsNotEmpty, MaxLength } from 'class-validator';
import { Column, PrimaryGeneratedColumn } from 'typeorm';
import { ApiProperty } from '@nestjs/swagger';

export class User {
  @PrimaryGeneratedColumn()
  @ApiProperty({ example: 1 })
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  @Column()
  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  @Column()
  @ApiProperty({ example: 'alice' })
  name!: string;

  @MaxLength(140)
  @Column('text')
  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

この記事は NestJS アドベントカレンダー 2019 18 日目の記事です。

はじめに

NestJS + ClassValidator + TypeORM 、という構成などのときに、上記のような Decorator Hell を想像してしまうことはあると思います。
動くものとしては十分ですが、メンテナンス性を高めるために、 Abstract Class と Interface を活用して分離し、依存関係を整理する一例を紹介します。

https://github.com/nestjs-jp/advent-calendar-2019/tree/master/day18-avoid-decorator-hell

なお、環境は執筆時点での Node.js の LTS である v12.13.x を前提とします。
また、この Decorator の挙動は ECMA Script 仕様として定義されていない Decorator に対して、TypeScript 3.7.x 時点での実装による挙動であるため、将来的に仕様の作成・変更に伴い TypeScript コンパイラの挙動が変更になる可能性があります。

現実装の Decorator の挙動については Decorator と継承 にも書いていますので併せてお読み下さい。

Validator を分離する

export class ValidatableUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

export class User extends ValidatableUser {
  @PrimaryGeneratedColumn()
  @ApiProperty({ example: 1 })
  id!: number;

  @Column()
  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @Column()
  @ApiProperty({ example: 'alice' })
  name!: string;

  @Column('text')
  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

class-validator が継承した Class でも validation ができることを利用し、 validation の定義を親クラスに移譲します。
以下のコードを実行すると、バリデーションエラーが発生します。

import { User } from './src/models/user';
import { validate } from 'class-validator';

async function main() {
  const user = new User();
  user.id = 1;
  user.displayId = 'alice1234567890123456';
  user.name = 'alice';

  const err = await validate(user, { skipMissingProperties: true });
  console.log(err);
}

main().catch(console.error);

API 層を分離する

API レスポンスとして使用される / Swagger のドキュメント生成に使用される Class を別に定義します。

import { IsNotEmpty, MaxLength } from 'class-validator';
import { Column, PrimaryGeneratedColumn } from 'typeorm';
import { ApiProperty } from '@nestjs/swagger';

export class ValidatableUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

export class User extends ValidatableUser {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

type TransferUserType = Omit<User, 'createdAt' | 'updatedAt'>;

export class TransferUser extends User implements TransferUserType {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;
}

src/app.controller.ts

import { Controller, Get, HttpException, Query } from '@nestjs/common';
import { TransferUser } from './models/user';
import { ApiResponse } from '@nestjs/swagger';
import { validate } from 'class-validator';

@Controller()
export class AppController {
  @Get()
  @ApiResponse({ status: 200, type: TransferUser })
  @ApiResponse({ status: 400 })
  async getUser(
    @Query() { displayId, name }: { displayId: string; name: string },
  ): Promise<TransferUser> {
    if (!displayId || !name) {
      throw new HttpException('displayId and name are required', 400);
    }

    const user = new TransferUser();
    user.id = 123;
    user.displayId = displayId;
    user.name = name;

    const errs = await validate(user, { skipMissingProperties: true });

    if (errs.length) {
      console.error(errs);
      throw new HttpException(errs, 400);
    }

    console.log(user);

    return user;
  }
}

$ curl localhost:3000\?displayId=alice07\&name=alice
{"id":123,"displayId":"alice07","name":"alice"}

$ curl localhost:3000\?displayId=alice1234567890123456\&name=alice
[{"target":{"id":123,"displayId":"alice1234567890123456","name":"alice"},"value":"alice1234567890123456","property":"displayId","children":[],"constraints":{"maxLength":"displayId must be shorter than or equal to 16 characters"}}]

TypeORM 層を分離する

次に、 User Class から TypeORM の Decorator を分離します。

import { IsNotEmpty, MaxLength } from 'class-validator';
import { Column, PrimaryGeneratedColumn } from 'typeorm';
import { ApiProperty } from '@nestjs/swagger';

export class ValidatableUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

export class User extends ValidatableUser {
  id!: number;
  displayId!: string;
  name!: string;
  profileText?: string;
  createdAt!: number;
  updatedAt!: number;
}

type SerializableUserType = Omit<User, 'createdAt' | 'updatedAt'>;

export class SerializableUser extends User implements SerializableUserType {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;
}

export class UserEntity extends User {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

ロジックを持ち基底となる Pure な User を用意し、整理する

上記の手順で User Class は class-validator を継承しているため、基底とは言えません。
なので、基底となる、 Decorator のない Pure TypeScript な User Class として定義するよう、継承関係を整理します。
また、ここで実装される toObject メソッドは User を継承した全ての Class で使用できるメソッドになります。

export class User {
  id: number;
  displayId: string;
  name: string;
  profileText?: string;
  createdAt?: number;
  updatedAt?: number;

  constructor({
    id,
    displayId,
    name,
    profileText,
    createdAt,
    updatedAt,
  }: User) {
    this.id = id;
    this.displayId = displayId;
    this.name = name;
    this.profileText = profileText;
    this.createdAt = createdAt;
    this.updatedAt = updatedAt;
  }

  toObject() {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
      createdAt: this.createdAt,
      updatedAt: this.updatedAt,
    };
  }
}

export class ValidatableUser extends User {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt!: number;
  updatedAt!: number;
}

type TransferUserType = Omit<User, 'createdAt' | 'updatedAt'>;

export class TransferUser extends ValidatableUser
  implements TransferUserType {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  toObject() {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
    };
  }
}

export class UserEntity extends ValidatableUser {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt!: number;

  @Column()
  updatedAt!: number;
}

Abstract Class 、 Interface を活用し整理する

最後に、 インスタンス化しないものを Abstract Class 化します。
この Abstract Class も、 toObject された値も、ともに満たす Interface を定義し実装します。

export interface UserInterface {
  id: number;
  displayId: string;
  name: string;
  profileText?: string;
  createdAt?: number;
  updatedAt?: number;
}

export abstract class AbstractUser implements UserInterface {
  id: number;
  displayId: string;
  name: string;
  profileText?: string;
  createdAt?: number;
  updatedAt?: number;

  constructor({
    id,
    displayId,
    name,
    profileText,
    createdAt,
    updatedAt,
  }: UserInterface) {
    this.id = id;
    this.displayId = displayId;
    this.name = name;
    this.profileText = profileText;
    this.createdAt = createdAt;
    this.updatedAt = updatedAt;
  }

  toObject(): UserInterface {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
      createdAt: this.createdAt,
      updatedAt: this.updatedAt,
    };
  }
}

export abstract class ValidatableUser extends AbstractUser {
  id!: number;

  @IsNotEmpty()
  @MaxLength(16)
  displayId!: string;

  @IsNotEmpty()
  @MaxLength(16)
  name!: string;

  @MaxLength(140)
  profileText?: string;

  createdAt?: number;
  updatedAt?: number;
}

export type TransferUserType = Omit<UserInterface, 'createdAt' | 'updatedAt'>;

export class User extends ValidatableUser {
  @ApiProperty({ example: 1 })
  id!: number;

  @ApiProperty({ example: 'alice07' })
  displayId!: string;

  @ApiProperty({ example: 'alice' })
  name!: string;

  @ApiProperty({ example: `Hello, I'm NestJS Programmer!` })
  profileText?: string;

  toObject() {
    return {
      id: this.id,
      displayId: this.displayId,
      name: this.name,
      profileText: this.profileText,
    };
  }
}

export class UserEntity extends ValidatableUser {
  @PrimaryGeneratedColumn()
  id!: number;

  @Column()
  displayId!: string;

  @Column()
  name!: string;

  @Column('text')
  profileText?: string;

  @Column()
  createdAt?: number;

  @Column()
  updatedAt?: number;
}

この状態でも、ロジック(Controller にロジックを書くべきではないとは思いますが例なので)側からは自然に見えるように思います。

src/app.controller.ts

@Controller()
export class AppController {
  @Get()
  @ApiResponse({ status: 200, type: User })
  @ApiResponse({ status: 400 })
  async getUser(
    @Query() { displayId, name }: { displayId: string; name: string },
  ): Promise<UserInterface> {
    if (!displayId || !name) {
      throw new HttpException('displayId and name are required', 400);
    }

    const user = new User({ id: 123, displayId, name });

    const errs = await validate(user, { skipMissingProperties: true });

    if (errs.length) {
      console.error(errs);
      throw new HttpException(errs, 400);
    }

    console.log(user);

    return user.toObject();
  }
}

ここまで分離する必要があるかどうかはケースバイケースかと思いますが、 Decorator を提供する複数のライブラリに同時に依存してしまうリスクをある程度排除し、同時にメンテナンス性もある程度担保できるかと思います。

おわりに

NestJS + ClassValidator + TypeORM 、という構成などのときに、 Abstract Class と Interface を活用して Decorator Hell を解消する方法の一例を紹介しました。
この方法が全てのプロジェクトに当てはまるわけではありませんが、参考にしていただければ幸いです。

ほんとにどうってこと無いメモです。

久々に開発しようとしたNuxtJSプロジェクトで、node-sassがコケました。
node-sassはv4.13.0です。

$ yarn dev

・
・
・

● Client █████████████████████████ building (61%) 431/466 modules 35 active
 node_modules/markdown-it/lib/rules_core/state_core.js

✖ Server
  Compiled with some errors in 9.34s


✖ Client
  Compiled with some errors in 13.93s

✖ Server
  Compiled with some errors in 9.34s


 ERROR  Failed to compile with 1 errors                                            friendly-errors 23:04:34


 ERROR  in ./layouts/blog.vue?vue&type=style&index=0&lang=scss&                    friendly-errors 23:04:34

Module build failed (from ./node_modules/sass-loader/dist/cjs.js):                 friendly-errors 23:04:34
Error: Missing binding /Users/n0bisuke/dotstudio/1_protooutstudio/node_modules/node-sass/vendor/darwin-x64-79/binding.node
Node Sass could not find a binding for your current environment: OS X 64-bit with Node.js 13.x

Found bindings for the following environments:
  - OS X 64-bit with Node.js 12.x

・
・
・

みたいなコケかたをしました。

Node Sass could not find a binding for your current environment: OS X 64-bit with Node.js 13.x

この64-bitをみると一瞬カタリナにmacOSをアップデートしたから怒られるやつかと思いましたが、

Found bindings for the following environments:
  - OS X 64-bit with Node.js 12.x

こちらを見ると既に64bit Node.js v12でnode-sassが紐付けされてたみたいですね。

それにしてもエラー表示がすごい。

これで解決

yarn add node-sass

npmの人も入れ直せばOK。

はじめに

細かいことは気にせずにNode.jsでwebアプリケーションを作る手順をまとめました。
新入社員の教育につかってみたら思ったより理解してくれて、開発の一歩目になってもらえたのでメモがてら置いておきます。
これから開発をする方がこの記事にたどり着いて少しでも開発への苦手意識などがなくなれば嬉しいです。

SlideShareはこちら?
https://www.slideshare.net/SoheiUchino1/nodejs-beginner

前提条件

% node --version
v12.13.0

% npm --version
6.13.2

目的

最近、grpc_tools と grpc_tools_node_protoc_ts を併せて Typescript の型ファイルと node.js の gRPC のクライアントを生成する機会がありました。生成される GRPC クライアントなのですが、Node.js にありがちな callback にて行う非同期処理です。そのため、GraphQL のリゾルバ等と組み合わせて使用する場合、非常に使い勝手が悪いです。

今回は生成された gRPC クライアントの関数を promisify します。

gRPC クライアントの生成

例えば、次のような protocol buffer から pb ファイルを生成することを考えます。

user.proto

syntax = "proto3";

package user;

option go_package = "v1";

service UserService {
    rpc CreateUser (CreateUserRequest) returns (CreateUserResponse);
}

message CreateUserRequest {
    int64 id = 1;
    string name = 2;
}

message CreateUserResponse {
    int64 id = 1;
    string name = 2;
}

grpc_tools_node_protoc コマンドから pb ファイルを生成します。

dist='src/grpc/generated'; \
grpc_tools_node_protoc \
  --js_out=import_style=commonjs,binary:${dist} \
  --ts_out=${dist} \
  --grpc_out=${dist} \
  -I ./proto
  ./proto/user.proto

生成された型ファイルの一部を抜粋します。

user_grpc_pb.d.ts

export class UserServiceClient extends grpc.Client implements IUserServiceClient {
    constructor(address: string, credentials: grpc.ChannelCredentials, options?: object);
    public createUser(request: user_pb.CreateUserRequest, callback: (error: grpc.ServiceError | null, response: user_pb.CreateUserResponse) => void): grpc.ClientUnaryCall;
    public createUser(request: user_pb.CreateUserRequest, metadata: grpc.Metadata, callback: (error: grpc.ServiceError | null, response: user_pb.CreateUserResponse) => void): grpc.ClientUnaryCall;
    public createUser(request: user_pb.CreateUserRequest, metadata: grpc.Metadata, options: Partial<grpc.CallOptions>, callback: (error: grpc.ServiceError | null, response: user_pb.CreateUserResponse) => void): grpc.ClientUnaryCall;
}

createUser 関数の最後の引数がそえぞれ callback となっていることがわかります。

クライアントの実装

Promise を実装する。

まずは自力で Promise を実装します。

client.ts

import { UserServiceClient } from './generated/user_grpc_pb';
import { credentials } from 'grpc';
import { CreateUserRequest, CreateUserResponse } from './generated/user_pb';

export const createClient = (url: string) => (
  request: CreateUserRequest
): Promise<CreateUserResponse> => {
  const client = new UserServiceClient(url, credentials.createInsecure());

  return new Promise((resolve, reject) => {
    client.createUser(request, (err, response) => {
      err === null ? resolve(response) : reject(err);
    })
  });
};

コレでも良いのですが、gRPC のエンドポイントが増えるたびに実装を行うのはなかなかツライです。

util.promisify を利用する。

次に Node.js の util.promisify を利用することを考えてみます。UserServiceClient クラスのメソッドを promisify しているため、bind 関数により this を束縛しないとエラーが発生することに注意してください。

client.ts

import { UserServiceClient } from './generated/user_grpc_pb';
import { credentials } from 'grpc';
import { CreateUserRequest, CreateUserResponse } from './generated/user_pb';
import { promisify } from 'util'

export const createClient = (url: string) => (
  request: CreateUserRequest
): Promise<CreateUserResponse> => {
  const client = new UserServiceClient(url, credentials.createInsecure());
  return promisify<CreateUserRequest, CreateUserResponse>(client.createUser).bind(client)(request)
};

エラーの有無に起因する分岐処理はなくなりましたが、ジェネリクスを指定する必要があります。

Bluebird.js を利用する。

Promise の実装である Bluebird.js を使用すると次のようになります。

client.ts

import { UserServiceClient } from './generated/user_grpc_pb';
import { credentials } from 'grpc';
import { CreateUserRequest, CreateUserResponse } from './generated/user_pb';
import { promisify } from 'bluebird'

export const createClient = (url: string) => (
  request: CreateUserRequest
): Promise<CreateUserResponse> => {
  const client = new UserServiceClient(url, credentials.createInsecure());
  return promisify(client.createUser, { context: client })(request)
};

ジェネリクスがなくなり、this の束縛も含めてシンプルになった印象です。promisify により生成される関数の戻り値の型が Bluebird<unknown> から Promise<CreateUserResponse> へ暗黙的にキャストが行われている点が少し気になりますが...

所感

今の所、Bluebird.js を利用した promisify がベターだと感じています。そもそものクライアントの実装をなんとかしてほしいところではあります。他の良い方法があれば是非とも教えて頂きたいです。

はじめに

最近バックエンドの実装をメインに担当しているエンジニアです。
先日チームメンバー（@sen-higaさん）と共同で行った業務効率化タスクを通して、初めてWebhookやサーバレスアーキテクチャに触れたので、その時の備忘録です。

やったこと

Github上のアクションを検知してGithubに対してアクションするという仕組みをLambda + API Gatewayで実装しました。
GithubからGithubへの動線がわかりやすいように、タスクの実装時とは内容を変えて、イシューがOpenされた時に、作成者をイシューに自動アサインするというシンプルな仕組みにしました。

もっとこうした方がいい、自分ならこう実装するというご意見があればぜひお願いします。

開発環境

os: mac High Sierra 10.13.6
npm: 6.11.3
Node: 12.12.0

利用技術

今回、利用したのはGithub Webhook Github API,AWS Lambda, Amazon API Gatewayになります。

Github webhook

Webhookとはあるサービスでのイベント発生時に、指定したURLにPOSTリクエストする仕組みです。（webhookとは？より）
Github webhookは、Githubが提供しているwebhookで、特定のアクションがリポジトリあるいは Organization で生じたときに外部の Web サーバーへ通知を配信する方法を提供しています。（公式ドキュメントより）

例えば、イシューのwebhookを登録しておくと、イシューがopenした時に登録したエンドポイントに以下のようなリクエストが送られます。

(公式ドキュメントより）

Github API

Webhookとは逆にGithubにアクションする時に使います。APIを利用するには、アクションを実行させるアカウントでアクセストークンを発行する必要があります。

AWS Lambda

サーバーレスでコードを実行できるサービスです。管理画面で、コーディング、環境変数の管理、テストなど色々できます。

Amazon API Gateway

開発規模に応じたエンドポイントを簡単に用意できるサービスです。webhookがリクエストを投げるエンドポイントを作成するために利用しました。Lambdaと連携させると、ヘッダー、ボディをJSON形式でlambdaに渡してくれます。

実装の流れ(概要)

以下のような流れで実装しました。

1. Lambda関数の作成
2. エンドポイントの作成
3. Github Webhookの追加
4. Github API用のアクセストークンの取得
5. Lambda関数の実装
   1. リクエストのバリデーション
   2. Webhookのリクエストを解釈
   3. APIを叩けるようにモジュールを追加
   4. Github APIにリクエストを投げる
6. 動作確認

実装の流れ（詳細）

1. Lambda関数の作成

コンソールから言語をnode.jsに指定して作成しました。

2. エンドポイントの作成

Designerの「トリガーの追加」からエンドポイントを追加しました。
「トリガーの追加」 -> 「API Gateway」を選択し、新規APIの作成画面を表示します。
今回はシンプルな動作のみ実装するのでテンプレートは「HTTP API」を選択しました。

作成後リダイレクトされたLambdaの画面下部に、デプロイ済みのエンドポイントが表示されます。こちらのエンドポイントをGithub Webhookに登録します。

3. Github Webhookの追加

3.1 Webhookに登録するトークンを生成

先程作成したエンドポイントは任意のリクエストを受け付ける状態になっているので、Webhookの認証用ヘッダーを見てリクエストを制限します。認証用ヘッダーをWebhookに埋め込んでもらうために、トークンを事前に用意しておきます。

今回は公式ドキュメント に従って生成したトークンを利用しました。

こちらのトークンは実装時にも利用するので、Lambda関数の環境変数に任意のキー名（SECRET TOKEN等）で追加しておきます。

3.2 Webhookの追加

先程作成したエンドポイントを使ってwebhookを追加します。
アクションを検知したいリポジトリに行き、 Settings -> Webhooks -> Add Webhook
から追加します。この時、先程生成したトークンをSecret欄に記入します。

また、今回はイシューのみを対象としたいので
「Let me select individual events」 -> 「issues」 にチェックを入れました。

4. Github API用のアクセストークンの取得

4.1 Tokenの取得

Github API用のトークンも取得しておきます。
自分のアイコンマークを押すと表示されるメニュー -> Setting -> Developer settings -> Personal access tokens -> Generate New Token から追加します。

今回は「repo」の権限を与えたトークンを発行しました。

発行されたTokenはLambdaの「環境変数」に任意のキー名（ACCSESS_TOKEN等）で登録しておきます。

これで、Githubからのアクションを検知し、Github APIを叩く動線が整いました。

5. Lambda関数の実装

以下のような手順で実装しました。

1. リクエストのバリデーション
2. 対象のアクションか判定
3. APIリクエスト用にモジュールを追加
4. GithubAPIにリクエストを投げる

5.1 リクエストのバリデーション

リクエストのバリデーションには、X-Hub-Signatureヘッダー、リクエストボディ、環境変数に登録したSECRET_TOKENを利用します。

公式ドキュメントによると、X-Hub-Signatureは、鍵をSecret Token、データをボディ として算出した値(MAC値)と一致します。

バリデーション実装部分のコードはこちらです。

exports.handler = (event) => {
    const headers = event.headers;
    const body = event.body;
    if (! isValid(body, headers)) {
        const response = {
            statusCode: 500,
            body: 'Given signatue is invalid',
        };
        return response;
    }
    const response = {
        statusCode: 200,
        body: 'OK',
    };
    return response;
};

function isValid (body, headers) {
    const crypto = require('crypto');
    const hmac = crypto.createHmac('sha1', process.env.SECRET_TOKEN);
    hmac.update(body, 'utf8');
    const signature = 'sha1=' + hmac.digest('hex');
    return signature === headers['X-Hub-Signature'];
}

2. 対象のアクションか判定する

次に、リクエストが対象のアクションのものか判定する部分を実装します。現状だとissueに関わるあらゆるアクション（edited, deleted, transferred等）に反応してしまうので、今回はopenedのみ反応するようにします。

exports.handler = (event) => {
    ...
    if (! isOpened(JSON.parse(body))) {
        const response = {
            statusCode: 400,
            body: 'Given action is invalid',
        };
        return response;
    }
    ...
};

function isValid (body, headers) {
    ...
}

function isOpened (body) {
    return body.action === 'opened';
}

これで、Webhookのリクエストを解釈する部分の実装は完了です。

3. APIリクエスト用にモジュールを追加する

続いて、APIを叩く部分の実装に入る前に、リクエストを行えるようrequestモジュールを追加しておきます。
公式の注記に従って、Layerという機能を使ってmoduleを追加しました。

追加手順は、
1.ローカルPCでrequestモジュールをnpm install
2.node_modulesのzipファイルを用意（zipファイルのディレクトリは「nodejs」が先頭です）

 {ファイル名}.zip
 └ nodejs/node_modules/...

3.lambda画面左側の「Layer」からレイヤーを追加します
4.追加したレイヤーをlambda画面「Designer」の「Layers」から今回のlambdaと紐づけます
Layerで紐付けたモジュールはlambda関数から自由に利用できます。

4. GithubAPIにリクエストを投げる

APIにリクエストを投げる部分を実装します。
イシュー作成者をイシューにアサインする場合、ヘッダー、メソッド、URI、ボディは以下の
ように設定します。

ヘッダー

環境変数に追加したトークンを利用してAuthenticationヘッダーを、トークンを発行したユーザ名をUser-Agentヘッダーに追加します

URI

イシューを更新する場合は
{ルートエンドポイント}/repos/:owner/:repo/issues/:issue_numberを指定します

　メソッド

イシューを更新する場合はPATCHを指定します

リクエストボディ

JSON形式でパラメータを記入します。(
今回はAssigneeを指定するパラメータ)

exports.handler = (event) => {
    ...
    const request = require('request');
    request(params(JSON.parse(body)), (error, response, body) => {
        if (error) {
            console.error('Issue assign failed');
        } else {
            console.log('Issue assign success');
        }
    });
    ...
};

...

function params (body) {
    return {
        json: true,
        headers: {
            'Authorization': 'token ' + process.env.ACCESS_TOKEN,
            'User-Agent': 'yanagimura'
        },
        method: 'PATCH',
        uri: `${body.issue.repository_url}/issues/${body.issue.number}`,,
        json: {
            'assignee': 'yanagimura'
        }
    };
}

6. 動作確認

早速イシューを作成してみます。

イシューを立てた直後にはAssineesは空ですが

?

すぐにイシューを立てたユーザ（私）がアサインされました！

まとめ

　
チームメンバーと共同で実装した時から時間が経っていたため、忘れている部分も多々あり、今回記事を投稿することで復習できてよかったです。ひとつひとつの実装はシンプルでしたが、それを組み合わせて、ひとつの流れを作ろうとすると、サーバレスとはいえ結構複雑だと感じました。　

また、ヘッダーの署名やAPIリクエストの構造などの知見は、外部サービスの利用と構築の両方の観点から得るものが多かったです。

最後に

全体のコードを記載しておきます。

exports.handler = (event) => {
    const headers = event.headers;
    const body = event.body;
    if (! isValid(body, headers)) {
        const response = {
            statusCode: 500,
            body: 'Given signatue is invalid',
        };
    }
    if (! isOpened(JSON.parse(body))) {
        const response = {
            statusCode: 400,
            body: 'Given action is invalid',
        };
        return response;
    }
    const request = require('request');
    request(params(JSON.parse(body)), (error, response, body) => {
        if (error) {
            console.error('Issue assign failed');
            console.error(error);
        } else {
            console.log('Issue assign success');
            console.log(response);
            console.log(body);
        }
    });
    const response = {
        statusCode: 200,
        body: 'OK',
    };
    return response;
};

function isValid (body, headers) {
    const crypto = require('crypto');
    const hmac = crypto.createHmac('sha1', process.env.SECRET_TOKEN);
    hmac.update(body, 'utf8');
    const signature = 'sha1=' + hmac.digest('hex');
    return signature === headers['X-Hub-Signature'];
}

function isOpened (body) {
    return body.action === 'opened';
}

function params (body) {
    return {
        json: true,
        headers: {
            'Authorization': 'token ' + process.env.ACCESS_TOKEN,
            'User-Agent': 'yanagimura'
        },
        method: 'PATCH',
        uri: `${body.issue.repository_url}/issues/${body.issue.number}`,
        json: {
            'assignee': `${body.sender.login}`
        }
    };
}

PONOS Advent Calendar 2019の24日目の記事です。
?メリークリスマス！！クリスマス・イブにFirebaseの記事をお届けします！！！?
???????????????????????????

はじめに

現在運用中のゲームでFirebaseを導入しました。
この記事では活用事例とノウハウを紹介していきます。
Firebase利用の一例になれば幸いです。

組み込み方法は別記事をご参照ください
公式ドキュメント
iOS
Android
Unity
C++
Web

この記事の対象者

・Firebase初心者、中級者
・Firebaseを検討中の方
・Firebaseの実装イメージを掴みたい方
・サーバーレスを検討中の方
・Googleのサービスが好きな方、興味のある方

Firebaseの各機能をざっくり紹介

機能がたくさんあります

名称	機能	活用
Firebase Authentication	認証機能	◎
Firebase Realtime Database	NoSQL クラウド データベースでデータの保管と同期を行うことができる	◯
Cloud Firestore	Realtime Database からさらにパワーアップした NoSQL データベース。	△
Cloud Storage for Firebase	写真や動画などのコンテンツを保管、取得することができる。	◎
Firebase Hosting	webサイトを構築	◎
Cloud Functions for Firebase	関数ごとにサーバー処理を簡単に用意できる	◯
ML Kit for Firebase	機械学習	×
Firebase Crashlytics	クラッシュ レポート管理	◯
Firebase Performance Monitoring	パフォーマンスの問題を診断	◯
Firebase Test Lab	様々なデバイスでアプリの自動テストおよびカスタマイズされたテストを実行	◎
Firebase Cloud Messaging	サーバから通知機能	◎
Firebase In-App Messaging	ターゲットを絞り込んでアプリ内で通知	×
Firebase Predictions	機械学習を用いた分析ツール	◎
Firebase Remote Config	Firebase consoleから、外観の変更、機能の段階的な展開などをカスタマイズ	×
Google Analytics for Firebase	総合的な分析ツール	◎
Firebase A/B Testing	ユーザーごとに出し分けしてA/Bテストを行う	◎
Firebase Dynamic Links	複数のプラットフォームで機能するURLを生成	×
Firebase App Indexing	アプリを Google 検索結果に表示することができる	×

活用１：ログイン時のユーザー認証

Firebase Authenticationをゲーム内での認証機能として使っています。
ログイン時に認証して、Firebase各種機能と連携して認証済みのアカウントしかセキュリティー的に許可しないようにしています。
以下の４種類の認証を使っています。
・Google
・Facebook
・メールアドレス
・匿名認証

匿名認証で作成したデータと各種連携したデータを紐づける処理はこちらで実装する必要がありますが、
公式ドキュメントにもサンプルコードが用意されているので低コストで実装できます。

匿名認証のコード

Auth.cpp

#include "firebase/app.h"
#include "firebase/auth.h"

void Auth::signInAnonymously(){
    firebase::App* app = App::GetInstance();
    firebase::auth::Auth* auth = Auth::GetAuth(app);

    auth->SignInAnonymously().OnCompletion([this](const firebase::Future<firebase::auth::User*>& result){
        if (result.status() == firebase::kFutureStatusComplete &&
         result.error() == firebase::auth::kAuthErrorNone &&
         result.result()) {
            //成功処理
        }else{
           //失敗処理
        }
    });
}

活用２：通信時の不正対策

通信時の不正対策として
Firebase Authentication
と
Cloud Functions
を組み合わせてサーバーサイドでも認証チェックしております。

Cloud Functionsを使用するとクライアント側の通信処理もセキュアでシンプルな作りになります。
詳細はCloud Functionsのドキュメントを一読するのもありです。

クライアント側の通信処理
Cloud Functionsで定義したsampleにリクエストを投げます。

Request.cpp

void Request::callSample(){
    firebase::Variant data = firebase::Variant::EmptyMap();

    firebase::functions::HttpsCallableReference doSomething = functions->GetHttpsCallable("sample");
    doSomething.Call(data).OnCompletion([this]
    (firebase::Future<firebase::functions::HttpsCallableResult> result){
        if(result.status() == firebase::kFutureStatusComplete &&
        result.error() == firebase::functions::kErrorNone && result.result()){
        //成功処理
        }else{
        //失敗処理
        }
    });
}

サーバー側の認証チェック
exports.sampleの部分がレスポンスを返します。

Server.js

const functions = require('firebase-functions');
const admin = require('firebase-admin');
admin.initializeApp();
 
exports.sample = functions.https.onCall((data, context) => {
    if(!checkAuth (data, context) ){
        throw new functions.https.HttpsError('failed-precondition', 'The function must be called ' +'while authenticated.');
    }
    //以降でサーバー処理を記入していく 
    return {
            text:"success",
    };
});


//認証チェック
async function checkAuth (data, context) {
    if( !(context.auth && context.auth.uid && context.auth.token)){
        console.log('checkAuth error');
        return false;
    }
    const user = await admin.auth().getUser(context.auth.uid);
    if (user.customClaims && user.customClaims.admin !== true) {
        console.log('checkAuth error');
        return false;
    }
    return true;
}

活用３：サーバーからのPush通知

Cloud Messagingを活用して特定条件を満たしたユーザーにPush通知を送るようにしています。
このサンプルソースではRealTimeDBにユーザーのpushTokenが保存されており、pushTokenを取り出して
使用しているパターンです。

Server.js

exports.pushNotification = functions.https.onCall((data, context) => {
    if(!checkAuth (data, context) ){
        throw new functions.https.HttpsError('failed-precondition', 'The function must be called ' +
        'while authenticated.');
    }


    const userId = data.userId;
    var pass = "user_table/" + userId + "/" + "pushToken";
    return admin.database().ref(pass).once('value').then(function(snapshot){
        var pushToken = snapshot.val();
        const payload = {
            notification: {
              title: 'プッシュ通知タイトル',
              body: `プッシュ通知本文`
            }
          };
          return admin.messaging().sendToDevice(pushToken, payload);
    }).catch(error => {
          console.error(error);
          throw new functions.https.HttpsError(error);
    });
});

シンプルに書くとこれだけで通知を送れます。

          return admin.messaging().sendToDevice(pushToken, payload);

活用４：バトルログの保存（アップロード）

バトル時のログや詳細情報はCloud Storageに保存しています。
DBに保存すると量と値段の面で、デメリットがあったので分析の必要がなく、他のユーザーから参照されないデータはCloud StorageにGZip化して保存しています。

CloudStorage.cpp

#include "firebase/app.h"
#include "firebase/storage.h"

void CloudStorage::storageUpLoad(){
    firebase::App* app = App::GetInstance();
    firebase::storage::Storage* storage = Storage::GetInstance(app);

    //アップロード先のパス
    std::string serverPath = "/";
    //アップロードするファイル保存先
    std::string localPath = "file://" + "ローカルパス";

    storage->GetReference().Child(serverPath).PutFile(localPath.c_str()).OnCompletion([](const firebase::FutureBase& result) {
                if (result.error() == firebase::storage::kErrorNone){
                  //成功処理
                }
                else {
                  //失敗処理
                }
    });

}

活用５：リソースダウンロード

これもCloud Storageを活用しています。
リソース数、容量などによって状況は変わると思いますが、問題ない速度でダウンロードできています。
何よりもCloud Storageはコストパフォーマンスがいいです。
現在、ほぼ無料枠で済んでいます。

CloudStorage.cpp

#include "firebase/app.h"
#include "firebase/storage.h"

void CloudStorage::storageDownload(){
    firebase::App* app = App::GetInstance();
    firebase::storage::Storage* storage = Storage::GetInstance(app);

    //対象リソースのパス
    std::string serverPath = "/";
    //ダウンロード後の保存先
    std::string localPath = "file://" + "ローカルパス";
    storage->GetReference().Child(serverPath).GetFile(localPath.c_str()).OnCompletion([](const firebase::FutureBase& result) {
        if (result.error() == firebase::storage::kErrorNone) {
         //成功処理
        }
        else {
         //失敗処理
        }
    });
}

活用６：ゲーム内お知らせ

お知らせ機能はFirebase Hostingを活用しています。
環境構築などの導入は非常に簡単です。
5分くらいでできると思います。
環境構築

環境構築が終わったら、HTML,CSS,画像などのWEB素材を用意して

firebase deploy

で、デプロイして完了です。

固定のお知らせやヘルプページを見せるだけでしたらFirebase Hostingだけで十分なのですが
ユーザーごとに見せるページを変えたい、期間で出し分けをしたい
などの仕様によってはサーバー側でHTMLを生成する必要があるので
うちのゲームではCloud Function、RealTimeDatabaseなども絡めて使っている箇所があります。

注意点としては
過去にデプロイしたWEBページがCDNに溜まっていき、容量が無駄になるので
Firebaseコンソール上からときどき消去しないといけません。
WEBページに問題があったときに、とっさにロールバックできるのでそれとトレードオフという感じですね

活用７：KPI 分析

ゲーム運営にKPI 分析は必須ですよね
Google Analytics for Firebaseを使っています。
for Firebaseと書いていますが、バックエンドの仕組みはGoogle AnalyticsでKPI分析するうえでは違いはありません。違いは組み込み方法が若干違うくらいです。

こちらのFirebase デモプロジェクトを触ってみるのが理解が早いです。

1.デモプロジェクトログイン
デモプロジェクトが見れるようになったらAnalyticsページへ
2.デモプロジェクト　Analyticsページ
※リンクから飛べない場合は、左側のメニューにてアナリティクス配下のDashboardをクリック

Analyticsは組み込むだけでセッション数、DAU、課金額、ARPPUなど
デフォルトでいくつかの値を集計してくれます。
ゲーム内独自の集計をしたい場合は、イベントを実装すればできます。

イベント実装例

FirebaseAnalytics.cpp

#include "firebase/app.h"
#include "firebase/analytics.h"

void FirebaseAnalytics::init(){
    firebase::App* app = App::GetInstance();
    firebase::analytics::Initialize(*app);
}

//レベルアップ時、イベント登録
void FirebaseAnalytics::levelUp(){
    firebase::analytics::LogEvent(firebase::analytics::kEventLevelUp);
}

活用８：予測データの運営活用

Firebase PredictionsではGoogleの機械学習の予測結果を簡単に知ることができます。

デモプロジェクト

以下項目の一週間後の予測結果を知ることができます。
churn：離脱ユーザーの数

not_churn：継続ユーザーの数

spend：課金するユーザーの数

not_spend：課金しないユーザーの数

Firebase Predictionsの優れている点は
これらの予測結果に対して
・A/Bテストを行なって動向を分析できる
・Remote ConfigによってUIやパラメーターなどを瞬時に変えることができる
・Cloud Messagingを使ってお得な情報などを送ることができる
ことにあると思います。

また、Google Analyticsと連携してコンバージョンに設定されたイベントを予測項目として追加することもできます。
ゲームごとに有効なイベントを設定すれば有効活用できると思います。

活用９：バナー広告、動画広告

Google AdMobを使って、バナー広告、動画広告に対応することができます。
Firebaseの機能としてあまり注目されてないですが、実はFirebase SDKではAdMobの機能もサポートされてます。

バナー広告表示

FirebaseAdmob.cpp

#include "firebase/app.h"
#include "firebase/admob.h"
#include "firebase/admob/banner_view.h"


void FirebaseAdmob::createBanner(){
    //firebase::admob::BannerView* banner_view
    banner_view = new firebase::admob::BannerView();

    firebase::admob::AdSize ad_size;
    ad_size.ad_size_type = firebase::admob::kAdSizeStandard;
    ad_size.width = 320;
    ad_size.height = 50;
    // my_ad_parent is a reference to an iOS UIView or an Android Activity.
    // This is the parent UIView or Activity of the banner view.
    // kBannerAdUnitはAdMobのサイトで発行されるId
    banner_view->Initialize(getAdParent(), kBannerAdUnit, ad_size);
}

void FirebaseAdmob::showBanner(){
    banner_view->MoveTo(banner_view->kPositionBottomLeft);
    banner_view->Show();
    firebase::admob::AdRequest my_ad_request = {};
    banner_view->LoadAd(my_ad_request);
}

活用１０：多端末テスト

スマホゲーム開発において多端末検証って大変ですよね
特にAndroidとかAndroidとかAndroidとか・・・
そこで活躍するのが
Firebase Test Lab
Google データセンターでホストされているデバイス上でアプリをテストします。
1 回のオペレーションで、さまざまなデバイス、
さまざまなデバイス構成で Android アプリや iOS アプリをテストし、
Firebase consoleで結果（ログ、動画、スクリーンショットなど）
を確認できます。

・Android端末が足りない場合
・テスターが足りない場合
・QA開始前のシステム的なテストをしたい場合
など使いどころはたくさんあります。

1.デモプロジェクトログイン
デモプロジェクトが見れるようになったらTest Labページへ
2.デモプロジェクト　Test Labページ
※リンクから飛べない場合は、左側のメニューにて品質、配下のTest Labをクリック

おわりに

Firebaseを導入してみての感想としては・・・

非常に簡単、便利で素晴らしいです！
ゲーム仕様や料金面での検討をする必要はありますが
まずは無料プランで使ってみてから他のサービスと比較検討する方法がオススメです！

料金面にて実装で創意工夫した箇所もありますが、結果として今は超・低コストで運営できています。

以下の機能は無料で使い続けることができるので、組み込んでおいて損はないです
・Google Analytics for Firebase
・Firebase Authentication
・Firebase Crashlytics
・Firebase Performance Monitoring
・Firebase Cloud Messaging
・Firebase Predictions
・Firebase Dynamic Links
・Firebase App Indexing
・Firebase A/B Testing

本プロジェクトではGCPも併用して活用しています。
次回はGCPのゲーム活用事例を書きたい思います。

明日は@honeniqさんの記事です
最終日の記事も楽しみですね！

はじめに

バックエンドをNode.js、フロントエンドをVue.jsでwebアプリを開発することが増えたので簡単にひな形を作る手順を残しておこうと思います。

手順

expressのプロジェクト作成

express プロジェクト名

vueのプロジェクトを作成

expressで作ったプロジェクトのルートディレクトリへ移動し
vue create public
publicというタイトルになっているので、気になる方はvueプロジェクトのindex.htmlのtittleタグを編集

vueプロジェクトでビルドする

publicディレクトリへ移動し
npm run build

expressのapp.jsに記述されているpublicのパスを変える

app.use(express.static(path.join(__dirname, 'public’)));
↓
app.use(express.static(path.join(__dirname, 'public/dist’)));

一応この記述も消しておく

// view engine setup
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'jade'); 

node.jsプロジェクトでサーバー起動

npm start

アクセスするとVueの初期画面が表示される

localhost:3000

おわりに

さくっと雛形を作ってすぐに開発に取り掛かりましょう！

A boilerplate for Node.js apps / API server / Authentication from scratch - express, graphql - (graphql compose), mongodb - (mongoose).

https://github.com/watscho/express-graphql-mongodb-boilerplate

はじめに

CI/CD Advent Calendar 2019 1日目に毎日npm auditを実行して脆弱性対応する取り組みを紹介しました。このときはCircleCI上で実行していたのですが、GitHub Actionsを使ってみたい、自作Actionを開発してみたいと思ってやってみました。

GitHub Actions Advent Calendar 2019 16日目のphp-audit-action(β版）をマーケットプレイスに公開してみたを読んだときは、出だしからnpm auditと書いてあるし、ネタが丸かぶりかとヒヤヒヤしました。記事タイトルを拝借しました。

作ったもの

npm auditを実行するActionを作りました。

リポジトリ、マーケットプレイス

https://github.com/oke-py/npm-audit-action
https://github.com/marketplace/actions/npm-audit-action

仕様

v1.1.0時点では大きく2つの機能があります。いずれもnpm auditを実行して脆弱性があればレポートする点は同じですが、トリガーによって動作が異なります。

Pull Requestがトリガーの場合

脆弱性があれば該当のPRに対してコメントをつけます。また、ジョブ自体は失敗とします。

Pull Request以外がトリガーの場合

Pushやスケジュール実行時に脆弱性があればIssueを作成します。

使い方

こんな感じです。

.github/workflows/audit.yml

name: npm audit

on:
  pull_request:
  push:
    branches:
      - master
      - 'releases/*'
# on:
#   schedule:
#     - cron: '0 10 * * *'

jobs:
  scan:
    name: npm audit
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: install dependencies
        run: npm ci
      - uses: oke-py/npm-audit-action@v1.1.0
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          issue_assignees: oke-py
          issue_labels: vulnerability,test

作り方

テンプレートの利用

6日目¹に紹介されていた公式のTypeScriptテンプレート²を利用しました。

npm installのエラー（うろ覚え）

何か宣言が足りないとかでエラーになった気がします。以下のように自分で定義するとエラーが解消されました。

@types/octokit/index.d.ts

declare module '@octokit/graphql' {
  export type Variables = any
  export type GraphQlQueryResponse = any
}

GitHub contextの取得

トリガーに応じて動作を変えるため、githubコンテキスト³を利用しました。ユーザーが指定しなくて済むようにaction.ymlでデフォルト値として指定しました。

action.yml

...
inputs:
  github_context:
    description: 'The `github` context'
    default: ${{ toJson(github) }}
    required: false
...

ローカルでの動作確認

開発中はローカルでActionを実行して動作確認したかったのですが、inputsの渡し方がわかりませんでした。そこでソースコード⁴を読んでみたところ環境変数として指定できることがわかりました。

packages/core/src/core.ts

export function getInput(name: string, options?: InputOptions): string {
  const val: string =
    process.env[`INPUT_${name.replace(/ /g, '_').toUpperCase()}`] || ''
  if (options && options.required && !val) {
    throw new Error(`Input required and not supplied: ${name}`)
  }

  return val.trim()
}

INPUT_ISSUE_ASSIGNEES=oke-py INPUT_ISSUE_LABELS=vulnerability,test node lib/main.js

PRコメント

GitHubの操作は@octokit/rest⁵を利用しましたが、単純なコメントをつけることができませんでした⁶。特定のコミット、行に対するコメントのみつけることができました。

To add a regular comment to a pull request timeline, see "Comments."

そこで、axiosを使ってGitHub API⁷を直接たたくようにしました。

テストコード

公式テンプレートからリポジトリを作成するとJestを使うようになっていました。モックの使い方がよくわからず悪戦苦闘しました。一応理解した気はしますが、あまり説明できません。

テストカバレッジの取得

19日目⁸に投稿したのでご参照ください。

pre-commit hookの設定

ソースコードを修正して動作確認したところで、意図した通りに動かないことが多々ありました。主な原因はTypeScriptのトランスパイル忘れでした。pre-commit hookを設定することで回避しました。

.git/hooks/pre-commit

#!/bin/sh
npm run all

マーケットプレイスのアイコン設定

action.ymlのbrandingでカラーとFeatherアイコンを指定できました⁹。絵心ないので助かりました。

action.yml

...
branding:
  icon: 'search'
  color: 'orange'

おわりに

CI/CD Advent Calendar 2019 初日にnpm auditネタではじまり、GitHub Actions Advent Calendar 2019 最終日にnpm auditネタで終えることができました。

とりあえず自分が使いたいものはできたかなと思いますが、少しでもユーザーが増えてくれたら嬉しいです。マーケットプレイスに公開して流入はあるのでしょうか・・・？　また、GitHubでスターをもらえたら嬉しいです。

---

1. https://qiita.com/iyu/items/2567877a74a77311ce0e ↩

2. https://github.com/actions/typescript-action ↩

3. https://help.github.com/ja/actions/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions ↩

4. https://github.com/actions/toolkit/blob/master/packages/core/src/core.ts#L67-L75 ↩

5. https://www.npmjs.com/package/@octokit/rest ↩

6. https://octokit.github.io/rest.js/#octokit-routes-pulls-create-comment ↩

7. https://developer.github.com/v3/issues/comments/#create-a-comment ↩

8. https://qiita.com/oke-py/items/d0bd20604bd53dcfaf88 ↩

9. https://help.github.com/ja/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions ↩

結論

npxコマンドを使おう

グローバルインストール

とは

$ npm install -g elm

このように-gをつけてグローバル環境にパッケージをインストールをすることです

ローカルインストール

対して、ローカルインストールは、

$ mkdir my_project && cd my_project
$ npm init
$ npm install elm --save // or --save-dev

こんな感じでインストールすると、my_project/node_modules/の中にパッケージがインストールされます。

違い

ローカルインストールの利点としては、プロジェクト毎にpackage.jsonで管理をするため、作ったプロジェクトを本番環境や他の人の環境に渡すことが簡単になります！

そして、いろいろなプロジェクトに手を出す際に、バージョン管理が簡単になります！

そしてグローバルインストールと違い、パソコンの環境を汚染しないため気持ち良いです！

CLI系のパッケージはどうするの

グローバルインストールをした場合のCLIパッケージの実行ファイルは皆さんがnode.jsをインストールした際にパスを通したディレクトリになります。

そして、ローカルインストールをした場合の実行ファイルのインストール先はmy_project/node_modules/.bin/ディレクトリになり、プロジェクトの度にパスを通すわけにもいかないし、コマンドを打つ度に./my_project/node_modules/.bin/elmなんて打っていたら面倒臭すぎて死にたくなっちゃいますよね

このような理由がある為、CLI系のパッケージをインストールして利用する際、みんながパスを通すであろうグローバルのnode_modulesディレクトリに実行可能ファイルが作られた方が簡単に取り扱える為、Qiita等いろいろな技術サイトで

CLIなのでグローバルイントールしましょう！

などと書かれていたりします。

しかし上で書いた通り、グローバルインストールは憲法違反です

npxコマンド

ローカルにインストールした実行ファイルの参照解決をしてくれるコマンドがnpmには備わっているのです！(npmのバージョンが 5.2.0以上)

まずelmのcliをインストールしたプロジェクトを作りましょう。

$ mkdir my_project && cd my_project
$ npm init
$ npm install elm --save // or --save-dev

上記のようにインストールしたelmの実行ファイルはここにいるのでこんな感じで使えます。

$ ./node_modules/.bin/elm

でもnpxならこう！！！

$ npx elm 

さあ、グローバル環境を汚さずにelmを書こう。

まとめ

こうやって書かれているnpmのcli系パッケージの記事は

$ npm install -g {package_name}
$ {command}

全部こうやって読み替えよう！！

$ npm install {package_name} // オプションで --save or --save-dev
$ npx {command}

理由があってグローバルインストールをしている場合もあるので憲法違反じゃないかもしれないです、そのときは臨機応変に☺️

この記事は NestJS アドベントカレンダー 2019 14 日目の記事です。
寝込んでいたため遅くなり申し訳ありません。

はじめに

この記事では NestJS で多用される Decorator を継承した場合の挙動について説明します。
サンプルコードのリポジトリは以下になります。

https://github.com/nestjs-jp/advent-calendar-2019/tree/master/day14-decorator-and-inheritance

なお、環境は執筆時点での Node.js の LTS である v12.13.x を前提とします。
また、この Decorator の挙動は ECMA Script 仕様として定義されていない Decorator に対して、TypeScript 3.7.x 時点での実装による挙動であるため、将来的に仕様の策定・変更に伴い TypeScript コンパイラの挙動が変更になる可能性があります。

結論

メソッドの Decorator 情報は継承されます。オーバーライドで切ることができます。

プロパティの Decorator は Class の定義時にしか評価されません。
しかし評価時にクラス名をキーにして container に副作用を与え、 instanceof で比較を行うようなライブラリでは、 instanceof は子 Class に対して親 Class と比較しても true となる(後述します)ため、継承しているような挙動に見えることがあります。

詳しくは以下で、 Method Decorator と Property Decorator に分けて説明します。

Method Decorator の挙動を追う

Decorator を定義した Class を継承した、 Decorator を直接定義していない Class のインスタンスを生成し、 Validator を定義した sayHello() を呼びます。
以下で定義する @LogProxy() は、関数の実行前後にログを出力する簡単な Decorator 関数です。

src/main.ts

function LogProxy(when: 'before' | 'after' | 'all') {
  return function(_target: any, key: string, desc: PropertyDescriptor) {
    const prev = desc.value;
    const next = function() {
      if (when === 'before' || when === 'all') {
        console.log(`${this.name}.${key} will start.`);
      }
      const result = prev.apply(this);
      if (when === 'after' || when === 'all') {
        console.log(`${this.name}.${key} has finished.`);
      }
      return result;
    };
    desc.value = next;
  };
}

class User {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  @LogProxy('all')
  sayHello() {
    console.log(`Hello, I am ${this.name}.`);
  }
}

class JapaneseUser extends User {
  name: string;

  constructor(name: string) {
    super(name);
    this.name = name;
  }
}

const alice = new User('alice');
alice.sayHello();
const arisu = new JapaneseUser('有栖');
arisu.sayHello();

$ yarn ts-node src/main.ts

alice.sayHello will start.
Hello, I am alice.
alice.sayHello has finished.
有栖.sayHello will start.
Hello, I am 有栖.
有栖.sayHello has finished.

コンパイルされた Decorator がどのような挙動をしているのか確認するため、コンパイルされたファイルを読みます。なお、 target は es2019 ですが、 2015 以降であれば Decorator 周りはほぼ変わらないようです。

dist/main.js

var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
    return c > 3 && r && Object.defineProperty(target, key, r), r;
};
function LogProxy(when) {
    return function (_target, key, desc) {
        const prev = desc.value;
        const next = function () {
            if (when === 'before' || when === 'all') {
                console.log(`${this.name}.${key} will start.`);
            }
            const result = prev.apply(this);
            if (when === 'after' || when === 'all') {
                console.log(`${this.name}.${key} has finished.`);
            }
            return result;
        };
        desc.value = next;
    };
}

class User {
    constructor(name) {
        this.name = name;
    }
    sayHello() {
        console.log(`Hello, I am ${this.name}.`);
    }
}
__decorate([
    LogProxy('all')
], User.prototype, "sayHello", null);
class JapaneseUser extends User {
    constructor(name) {
        super(name);
        this.name = name;
    }
}
const alice = new User('alice');
alice.sayHello();
const arisu = new JapaneseUser('有栖');
arisu.sayHello();
//# sourceMappingURL=main.js.map

全てを読まずとも、 __decorate が User.prototype の name に、 decorator 関数を食わせた値を再代入していることが分かります。
下の継承している側の Class では特に defineProperty をしているわけではないので、 Decorator の影響を受け続けています。

そのため、継承した Class でオーバーライドした場合には Decorator の影響は受けません。

src/main.ts

function LogProxy(when: 'before' | 'after' | 'all') {
  return function(_target: any, key: string, desc: PropertyDescriptor) {
    const prev = desc.value;
    const next = function() {
      if (when === 'before' || when === 'all') {
        console.log(`${this.name}.${key} will start.`);
      }
      const result = prev.apply(this);
      if (when === 'after' || when === 'all') {
        console.log(`${this.name}.${key} has finished.`);
      }
      return result;
    };
    desc.value = next;
  };
}

class User {
  name: string;

  constructor(name: string) {
    this.name = name;
  }

  @LogProxy('all')
  sayHello() {
    console.log(`Hello, I am ${this.name}.`);
  }
}

class JapaneseUser extends User {
  name: string;

  constructor(name: string) {
    super(name);
    this.name = name;
  }

  sayHello() {
    console.log(`こんにちは、私は${this.name}です。`);
  }

}

const alice = new User('alice');
alice.sayHello();
const arisu = new JapaneseUser('有栖');
arisu.sayHello();

$ yarn ts-node src/main.ts

alice.sayHello will start.
Hello, I am alice.
alice.sayHello has finished.
こんにちは、私は有栖です。

Property Decorator の挙動を追う

同様に、 Decorator を定義した Class とその子 Class を定義します。
以下で定義する @Effect() は、呼び出し時に呼び出し元とプロパティ名、引数を Container に記録する副作用を持つ Decorator 関数です。

src/main.ts

let effectContainer = {};
let effectCounter = 0;

function Effect(str: string) {
  return function(target: any, key: string) {
    const className = target.constructor.name;
    const prev = effectContainer[className];
    effectContainer[className] = { ...prev, [key]: str };
    effectCounter++;
  };
}

class User {
  @Effect('decorating User.name property')
  name: string;

  constructor(name: string) {
    this.name = name;
  }
}

class JapaneseUser extends User {
  name: string;

  constructor(name: string) {
    super(name);
    this.name = name;
  }
}

const alice = new User('alice');
console.log(alice.name)
const beth = new User('beth');
console.log(beth.name)
const arisu = new JapaneseUser('有栖');
console.log(arisu.name)

console.log(effectContainer);
console.log(effectCounter);

$ yarn ts-node src/main.ts
alice
beth
有栖
{ User: { name: 'decorating User.name property' } }
1

User Class のインスタンスは子 Class 含め複数回生成していますが、 Decorator 関数は 1度しか呼ばれていません。
コンパイル済みの以下のコードを見ると、 Class 宣言の後に1度評価されているのみであることが分かります。

dist/main.js

var __decorate = (this && this.__decorate) || function (decorators, target, key, desc) {
    var c = arguments.length, r = c < 3 ? target : desc === null ? desc = Object.getOwnPropertyDescriptor(target, key) : desc, d;
    if (typeof Reflect === "object" && typeof Reflect.decorate === "function") r = Reflect.decorate(decorators, target, key, desc);
    else for (var i = decorators.length - 1; i >= 0; i--) if (d = decorators[i]) r = (c < 3 ? d(r) : c > 3 ? d(target, key, r) : d(target, key)) || r;
    return c > 3 && r && Object.defineProperty(target, key, r), r;
};
let effectContainer = {};
function Effect(str) {
    return function (target, key) {
        const className = target.constructor.name;
        const prev = effectContainer[className];
        effectContainer[className] = { ...prev, [key]: str };
    };
}
class User {
    constructor(name) {
        this.name = name;
    }
}
__decorate([
    Effect('decorating name property')
], User.prototype, "name", void 0);
class JapaneseUser extends User {
    constructor(name) {
        super(name);
        this.name = name;
    }
    sayHello() {
        console.log(`こんにちは、私は${this.name}です。`);
    }
}
const alice = new User('alice');
const beth = new User('beth');
const arisu = new JapaneseUser('有栖');
console.log(effectContainer);
//# sourceMappingURL=main.js.map

この例で上げたのが副作用であるのは、 Decorator 関数の返す関数が取れる引数が 2つのみであり、 PropertyDescripter が存在しないため、呼び出し元の Class に対して何も操作することが現状できないためです。
子 Class に対して定義した場合は、新規の定義として実行されます。

class JapaneseUser extends User {
  @Effect('decorating JapaneseUser.name property')
  name: string;

  constructor(name: string) {
    super(name);
    this.name = name;
  }
}

$ yarn ts-node src/main.ts
alice
beth
有栖
{
  User: { name: 'decorating User.name property' },
  JapaneseUser: { name: 'decorating JapaneseUser.name property' } 
}
2

class-validator の Decorator の挙動

class-validator では上記の Property Decorator を使用して定義しますが、その際に Class 名とプロパティ名を Container に記録しています。
内部では instanceof による比較をしているようであるため、 Decorator の定義を継承したような挙動に見えます。

備考: instanceof と子クラスについて

該当する Class のインスタンスであるかの比較に instanceof を使用すると、その子孫クラスと比較した場合も true となります。

class User {}
const user = new User()
user instanceof User //=> true
class ExUser extends User {}
const exUser = new ExUser()
exUser instanceof User //=>true

子孫クラスであることを明確に区別したい場合は、 Class 名を取得して比較するのが良いです。

user.constructor.name === exUser.constructor.name //=> false

おわりに

この記事では NestJS で多様される Decorator を継承した場合の挙動について説明しました。
Decorator の仕様はまだ安定していないため、今後挙動が変わる可能性がある点はくれぐれもご留意ください。

明日は @potato4d の GitHub Actions を利用した NestJS アプリケーションの Google AppEngine への自動デプロイ です。