Upgrade to Pro — share decks privately, control downloads, hide ads and more …

nestjs_typeorm

 nestjs_typeorm

622e438138519f0b3c2dbd50bc64a5a9?s=128

Wataru Morita

June 18, 2019
Tweet

More Decks by Wataru Morita

Other Decks in Technology

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. 5IBOLZPV @tascript Fukuoka.ts