【NestJS】ちょっと思ったことを書く

• はじめに
  • ナレッジが増えてきて楽しい
  • ビジネスロジックはどれで書くのがいいの？
  • 今の理解を書いたメモ
    • Getの場合
    • PostやPatchの場合
• 英語できないときつい感は現時点では正直ある
• Swaggerを自動生成は素敵
• なう

はじめに

2020年1月16日時点でNestJSに対して思うことを書くだけの記事である。

ナレッジが増えてきて楽しい

嬉しいことに、日々、NestJSのナレッジがオンライン上に増えてきている。

ビジネスロジックはどれで書くのがいいの？

NestJSのプロジェクトでビジネスロジックを書くパターンは色々あるみたいだけど、Serviceで書くのか、Repositoryで書くのか、いやいやCustom Repositoryなのかあまりベストプラクティスが把握できない。

一応、私はCustomRepositoryパターンを採用してはいるが、それはたまたま購入したUdemyのオンラインコースがそうしているだけだったからだ。

それぞれでどんなメリット、デメリットがあるのか現在整理しないといけないなと思う。

まぁ、それらも含めて今後もやったろう感ぱねぇっすから。

今の理解を書いたメモ

Getの場合

1. Controllerがまずはリクエストを受ける（URIパラメータのチェックとかもする）
2. Serviceにイベントを振る
3. ServiceがさらにRepositoryを呼び出す
4. RepositoryがDBからデータを呼び出して返す（Repositoryでロジックを書く）

PostやPatchの場合

1. Controllerがまずはリクエストを受ける
2. リクエストに応じてDTO(Data Transfer Object)を生成
3. DTOを? Controllerが受け取ったRequestの中身？をPipeがValidateまたはTransformする
4. ServiceがDTOを受けとり、さらにRepositoryを呼び出してDTOをお渡し
5. RepositoryがDBに書き込み
6. 結果をクライエントに返す

みたいな大枠の流れがあると認識している

英語できないときつい感は現時点では正直ある

讃岐小僧（合田圭佑）は割と英語のコンテンツやテキストをみてもアレルギーないので対応できるが、そうじゃない場合はまだまだNestJSは日本人にとって学習しづらいものであることは確か。

Swaggerを自動生成は素敵

SwaggerにてAPIドキュメントを自動生成するのは激アツ機能。

なう

今日も、TypeORMでの typeorm migration:generateしたファイルでは各カラムにNOT NULLが絶対にくる件で今日も2時間ハマりましたが、そうやって日々前進していくんですよ。（↑これはNestJSの問題ではない）

ただ、現状のDBスキーマとentityの定義を見比べてmigrationファイルを作成してくれる機能に関してはRailsのActiveRecordより優れてると思う

以上これだけ。