nestjs_typeorm

Transcript

1. /FTU+4
   º
   5ZQF03. @tascript Fukuoka.ts
2. ;͋Έ 森田 亘(@tascript) GMOペパボエンジニア Nuxt、Vue、TypeScript React、ReactNative(お休み中)
3. /FTU+4
4. લఏ Expressを使っている TypeScriptを使っている Nestは書いたことない 日本語の記事少なくて辛い 新しいことはみんなでやっていこうね！
5. /FTU+4 Node.jsのフルスタックフレームワーク デフォルトでTypeScriptを使用した開発が可能 DIを使用して疎結合なアプリケーション開発を実現 責務を分離することで冗長性の高い開発が可能
6. $POUSPMMFS 4FSWJDF 4FSWJDF 4FSWJDF 3FRVFTU $POUSPMMFS $POUSPMMFS ࠷খΞʔΩςΫνϟ
7. ࠷খΞʔΩςΫνϟ ContollerはHTTPリクエストを受けてレスポンスを返すだけ Controllerでルーティングを決めておく ビジネスロジックはServiceに実装する ControllerごとにServiceをDIする $POUSPMMFS 4FSWJDF 4FSWJDF 4FSWJDF 3FRVFTU $POUSPMMFS $POUSPMMFS
8. $POUSPMMFS ＠Controllerデコレータでlocalhost:3000/catsが定義される コンストラクタの中で欲しいServiceを注入する
9. 4FSWJDF ＠Injectableでインジェクションされることを宣言 ビジネスロジックを追加する
10. .PEVMF࡞੒ 使用する機能をカプセル化する 機能間の依存関係を解決する エンドポイント単位で作成するのがベター Controller、Service、Entityなどを宣言する 複数のmoduleから新たなmoduleを作成することもできる 1つのアプリケーションに対し最低1つのmoduleが必要
11. .PEVMF࡞੒ $BU.PEVMF 0XOFS.PEVMF %PH.PEVMF "OJNBM.PEVMF )VNBO.PEVMF "QQ.PEVMF
12. .PEVMF࡞੒ 最終的には1つのルートモジュールにまとめる エントリーポイントであるmain.tsにてimportして利用する module単位で依存関係を可視化できる 問題箇所を切り離しやすい $BU.PEVMF 0XOFS.PEVMF %PH.PEVMF "OJNBM.PEVMF )VNBO.PEVMF "QQ.PEVMF
13. .PEVMF࡞੒ ΤϯυϙΠϯτ୯Ґ ＠Moduleデコレータでmoduleを定義する 使用するControllerやServiceを定義
14. .PEVMF࡞੒ ϧʔτ importsに使用するmoduleを定義する 全ルートに対して実施するmiddlewareの宣言もここで実施
15. 5ZQF4DSJQU
    ͱͷ਌࿨ੑ
16. %50 Data Transfer Object リクエストの型をチェックするためのオブジェクト interfaceかクラスで定義可能 クラスで書きましょう！
17. %50 クラスの場合 class-validatorでプロパティの型をチェックする
18. JOUFSGBDFͰ͍͍ͷͰ͸ʁ
19. 1JQF Controller内におけるメソッドの引数をチェックする 受け取った引数の(型の変換 + )バリデーションを実施する バリデーションに通ったリクエストのみルートハンドラを実行する リクエストの型チェックをServiceの中でしなくてよくなる アプリケーションの疎結合が担保される interfaceの場合プロパティの再計算が実施できない (https://github.com/nestjs/nest/issues/1228)
20. 1JQF $POUSPMMFS 4FSWJDF 4FSWJDF 4FSWJDF 3FRVFTU $POUSPMMFS $POUSPMMFS 1JQF
21. 1JQF plainToClassで引数の情報をDTOクラスに変換 class-validatorのvalidateを使用してDTOオブジェクトとの比較
22. Ҏ্Λ౿·͑ͯ
23. /FTU+4ͷϝϦοτ ルーティングとビジネスロジックが分割されているので可読性が高い Fat Controllerになりにくい 単一責任の原則(SRP)により何を書くべきかが明瞭 async/awaitがデフォルトで使用可能(expressより導入しやすい) module単位、ルート単位でカスタマイズが簡単 TypeScript書ける人にはもってこい お約束はあるが割と直感的に書ける(個人差があるだろうけど)
24. /FTU+4ͷ೉ͦ͠͏ͳ఺ サブルーティングが切りにくい(moduleアーキテクチャの副作用) シェアするServiceが増えるとmoduleの分割が難しくなる InterceptorやPipeで型をCastしすぎないように注意 お作法に則るので人間が注意すべき点が多くなる 日本語の記事が…(一緒に増やしていきましょう！)
25. 5ZQF03.
26. લఏ sequelize(-typescript)を使っている TypeORMを使ったことがない 新しいことはみんなでやっていきましょう！
27. 5ZQF03. TypeScriptで利用可能なORM(ES5, ES6, ES7, ES8でも利用可能) Entity(Model)の定義からmigration or DBを直接操作 RepositoryパターンとActiveRecordパターンのいずれかで開発可能 取得したデータから型の恩恵を受けられる Nestの公式で利用を推奨
28. /FTU+4ͱͷ૊Έ߹Θͤ ormconfig.json(.js .env .yml .xml)をプロジェクトルートに配置 テーブルごとにentity(モデルに該当)を用意する entityにはテーブルの定義やメソッドを書く entityを使用するserviceとモジュールに注入する
29. PSNDPOpHKTPO typescriptの場合はtsconfig.jsonのoutDirに合わせて entities、migrations、subscribersのpathを作成する
30. &OUJUZ @Entityでentityの宣言とテーブル名の宣言をする sequelize-typscriptと大きく変わらない
31. 4FSWJDF コンストラクタでentityからリポジトリを生成してDI リポジトリからテーブルを操作
32. .JHSBUJPO エンティティの変更履歴を確認して自動生成 DBにMigrationsテーブルが作成され実行履歴が確認できる リレーションも簡単に定義可能 TypeORM最高じゃん！
33. ஫ҙ
34. .JHSBUJPOͷ᠘ DBに接続(サーバー立ち上げておかないと)migrationできない entityを作る・消すをしていると消したはずのentityのmigrationが残る Date型がstringとして帰ってくるケース
35. ௗ͡ΌΜʂ
36. ݪҼ
37. ݪҼ
38. ͓·͑ͩͬͨͷ͔
39. ରࡦ distを消して再度npm run build npm run prestart:prodでも同じ ごめんねTypeORM
40. %BUFܕͷऔѻ͍ 例えばこんなentityを用意した場合は要注意
41. %BUFܕͷऔѻ͍ IUUQTHJUIVCDPNUZQFPSN UZQFPSNJTTVFT
42. %BUFܕͷऔѻ͍ ΧϥϜͷλΠϓΛEBUFʹ͢Δͱ
    %BUFܕΛఆ͍ٛͯͯ͠΋
    TUSJOH͕ฦͬͯ͘Δ
43. ໰୊ カラムの値をチェックする条件文が常に通らない(string型 ≠ Date型) asを使って型をcastし始める 型の正誤性が取れなくなる
44. ରࡦ time stampを使いましょう(Date型を返す) できるだけcastは使いたくないよね 時間の取扱いって難しいよね
45. 5ZQF03.ͷϝϦοτ Migrationは癖があるけど、使い勝手がよい(ただしsynchronizeは…) 型の恩恵もそれなりに受けられる 導入までに時間がかからない(ほんの数分でできた) 非同期処理もスムーズに書けるNestとの相性は良好 リレーションで取得したプロパティにentityの型がつく
46. 5ZQF03.ͷ೉͍͠ͱ͜Ζ タイプセーフなの？ Date型の件から察するにコンパイル時に怒られない場合が高い 型をcastする可能性も高い subscribersでどうにかしてください、だと辛い
47. ࣍ճҎ߱΍͍ͬͯ͘͜ͱ expressからNestJSにお引越し作戦(今回は間に合いませんでした) TypeORMとTypeScriptの親和性を検証
48. 5IBOL
    ZPV
     @tascript Fukuoka.ts