Know Easy 
はじめに
2020年1月16日時点でNestJSに対して思うことを書くだけの記事である。
ナレッジが増えてきて楽しい
嬉しいことに、日々、NestJSのナレッジがオンライン上に増えてきている。
ビジネスロジックはどれで書くのがいいの？
NestJSのプロジェクトでビジネスロジックを書くパターンは色々あるみたいだけど、Serviceで書くのか、Repositoryで書くのか、いやいやCustom Repositoryなのかあまりベストプラクティスが把握できない。
一応、私はCustomRepositoryパターンを採用してはいるが、それはたまたま購入したUdemyのオンラインコースがそうしているだけだったからだ。
それぞれでどんなメリット、デメリットがあるのか現在整理しないといけないなと思う。
まぁ、それらも含めて今後もやったろう感ぱねぇっすから。
今の理解を書いたメモ
Getの場合
- Controllerがまずはリクエストを受ける（URIパラメータのチェックとかもする）
- Serviceにイベントを振る
- ServiceがさらにRepositoryを呼び出す
- RepositoryがDBからデータを呼び出して返す（Repositoryでロジックを書く）
PostやPatchの場合
- Controllerがまずはリクエストを受ける
- リクエストに応じてDTO(Data Transfer Object)を生成
- DTOを? Controllerが受け取ったRequestの中身？をPipeがValidateまたはTransformする
- ServiceがDTOを受けとり、さらにRepositoryを呼び出してDTOをお渡し
- RepositoryがDBに書き込み
- 結果をクライエントに返す
みたいな大枠の流れがあると認識している
英語できないときつい感は現時点では正直ある
讃岐小僧（合田圭佑）は割と英語のコンテンツやテキストをみてもアレルギーないので対応できるが、そうじゃない場合はまだまだNestJSは日本人にとって学習しづらいものであることは確か。
Swaggerを自動生成は素敵
SwaggerにてAPIドキュメントを自動生成するのは激アツ機能。
なう
今日も、TypeORMでの typeorm migration:generateしたファイルでは各カラムにNOT NULLが絶対にくる件で今日も2時間ハマりましたが、そうやって日々前進していくんですよ。（↑これはNestJSの問題ではない）
ただ、現状のDBスキーマとentityの定義を見比べてmigrationファイルを作成してくれる機能に関してはRailsのActiveRecordより優れてると思う
以上これだけ。