Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
nestjs_typeorm
Search
Wataru Morita
June 18, 2019
Technology
0
660
nestjs_typeorm
Wataru Morita
June 18, 2019
Tweet
Share
More Decks by Wataru Morita
See All by Wataru Morita
thanks_react_router_v7
tascript
0
170
5-things-for-front-end
tascript
0
10k
legacy_code_fukuoka_js
tascript
1
450
svelte_typescript_fukuoka_ts
tascript
1
460
enjoy_mruby_2021
tascript
0
110
TypeScript_BFF
tascript
4
4.8k
frontend_to_cli_tool_by_rust
tascript
0
570
Asyncで 非同期処理を 少しだけ楽に書く/ ruby_with_async
tascript
0
220
Other Decks in Technology
See All in Technology
今年のデータ・ML系アップデートと気になるアプデのご紹介
nayuts
1
130
Sansanが実践する Platform EngineeringとSREの協創
sansantech
PRO
2
660
日本Rubyの会の構造と実行とあと何か / hokurikurk01
takahashim
4
940
pmconf2025 - 他社事例を"自社仕様化"する技術_iRAFT法
daichi_yamashita
0
790
今からでも間に合う!速習Devin入門とその活用方法
ismk
1
500
生成AI・AIエージェント時代、データサイエンティストは何をする人なのか?そして、今学生であるあなたは何を学ぶべきか?
kuri8ive
2
2.1k
Kubernetes Multi-tenancy: Principles and Practices for Large Scale Internal Platforms
hhiroshell
0
110
ML PM Talk #1 - ML PMの分類に関する考察
lycorptech_jp
PRO
1
730
Lambdaの常識はどう変わる?!re:Invent 2025 before after
iwatatomoya
1
340
グレートファイアウォールを自宅に建てよう
ctes091x
0
140
“決まらない”NSM設計への処方箋 〜ビットキーにおける現実的な指標デザイン事例〜 / A Prescription for "Stuck" NSM Design: Bitkey’s Practical Case Study
bitkey
PRO
1
580
モバイルゲーム開発におけるエージェント技術活用への試行錯誤 ~開発効率化へのアプローチの紹介と未来に向けた展望~
qualiarts
0
660
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8.3k
Documentation Writing (for coders)
carmenintech
76
5.2k
[RailsConf 2023] Rails as a piece of cake
palkan
58
6.1k
How to Ace a Technical Interview
jacobian
280
24k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
Making Projects Easy
brettharned
120
6.5k
4 Signs Your Business is Dying
shpigford
186
22k
Testing 201, or: Great Expectations
jmmastey
46
7.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
A designer walks into a library…
pauljervisheath
210
24k
Transcript
/FTU+4º5ZQF03. @tascript Fukuoka.ts
;͋Έ 森田 亘(@tascript) GMOペパボエンジニア Nuxt、Vue、TypeScript React、ReactNative(お休み中)
/FTU+4
લఏ Expressを使っている TypeScriptを使っている Nestは書いたことない 日本語の記事少なくて辛い 新しいことはみんなでやっていこうね!
/FTU+4 Node.jsのフルスタックフレームワーク デフォルトでTypeScriptを使用した開発が可能 DIを使用して疎結合なアプリケーション開発を実現 責務を分離することで冗長性の高い開発が可能
$POUSPMMFS 4FSWJDF 4FSWJDF 4FSWJDF 3FRVFTU $POUSPMMFS $POUSPMMFS ࠷খΞʔΩςΫνϟ
࠷খΞʔΩςΫνϟ ContollerはHTTPリクエストを受けてレスポンスを返すだけ Controllerでルーティングを決めておく ビジネスロジックはServiceに実装する ControllerごとにServiceをDIする $POUSPMMFS 4FSWJDF 4FSWJDF 4FSWJDF 3FRVFTU
$POUSPMMFS $POUSPMMFS
$POUSPMMFS @Controllerデコレータでlocalhost:3000/catsが定義される コンストラクタの中で欲しいServiceを注入する
4FSWJDF @Injectableでインジェクションされることを宣言 ビジネスロジックを追加する
.PEVMF࡞ 使用する機能をカプセル化する 機能間の依存関係を解決する エンドポイント単位で作成するのがベター Controller、Service、Entityなどを宣言する 複数のmoduleから新たなmoduleを作成することもできる 1つのアプリケーションに対し最低1つのmoduleが必要
.PEVMF࡞ $BU.PEVMF 0XOFS.PEVMF %PH.PEVMF "OJNBM.PEVMF )VNBO.PEVMF "QQ.PEVMF
.PEVMF࡞ 最終的には1つのルートモジュールにまとめる エントリーポイントであるmain.tsにてimportして利用する module単位で依存関係を可視化できる 問題箇所を切り離しやすい $BU.PEVMF 0XOFS.PEVMF %PH.PEVMF "OJNBM.PEVMF )VNBO.PEVMF
"QQ.PEVMF
.PEVMF࡞ ΤϯυϙΠϯτ୯Ґ @Moduleデコレータでmoduleを定義する 使用するControllerやServiceを定義
.PEVMF࡞ ϧʔτ importsに使用するmoduleを定義する 全ルートに対して実施するmiddlewareの宣言もここで実施
5ZQF4DSJQU ͱͷੑ
%50 Data Transfer Object リクエストの型をチェックするためのオブジェクト interfaceかクラスで定義可能 クラスで書きましょう!
%50 クラスの場合 class-validatorでプロパティの型をチェックする
JOUFSGBDFͰ͍͍ͷͰʁ
1JQF Controller内におけるメソッドの引数をチェックする 受け取った引数の(型の変換 + )バリデーションを実施する バリデーションに通ったリクエストのみルートハンドラを実行する リクエストの型チェックをServiceの中でしなくてよくなる アプリケーションの疎結合が担保される interfaceの場合プロパティの再計算が実施できない (https://github.com/nestjs/nest/issues/1228)
1JQF $POUSPMMFS 4FSWJDF 4FSWJDF 4FSWJDF 3FRVFTU $POUSPMMFS $POUSPMMFS 1JQF
1JQF plainToClassで引数の情報をDTOクラスに変換 class-validatorのvalidateを使用してDTOオブジェクトとの比較
Ҏ্Λ౿·͑ͯ
/FTU+4ͷϝϦοτ ルーティングとビジネスロジックが分割されているので可読性が高い Fat Controllerになりにくい 単一責任の原則(SRP)により何を書くべきかが明瞭 async/awaitがデフォルトで使用可能(expressより導入しやすい) module単位、ルート単位でカスタマイズが簡単 TypeScript書ける人にはもってこい お約束はあるが割と直感的に書ける(個人差があるだろうけど)
/FTU+4ͷͦ͠͏ͳ サブルーティングが切りにくい(moduleアーキテクチャの副作用) シェアするServiceが増えるとmoduleの分割が難しくなる InterceptorやPipeで型をCastしすぎないように注意 お作法に則るので人間が注意すべき点が多くなる 日本語の記事が…(一緒に増やしていきましょう!)
5ZQF03.
લఏ sequelize(-typescript)を使っている TypeORMを使ったことがない 新しいことはみんなでやっていきましょう!
5ZQF03. TypeScriptで利用可能なORM(ES5, ES6, ES7, ES8でも利用可能) Entity(Model)の定義からmigration or DBを直接操作 RepositoryパターンとActiveRecordパターンのいずれかで開発可能 取得したデータから型の恩恵を受けられる
Nestの公式で利用を推奨
/FTU+4ͱͷΈ߹Θͤ ormconfig.json(.js .env .yml .xml)をプロジェクトルートに配置 テーブルごとにentity(モデルに該当)を用意する entityにはテーブルの定義やメソッドを書く entityを使用するserviceとモジュールに注入する
PSNDPOpHKTPO typescriptの場合はtsconfig.jsonのoutDirに合わせて entities、migrations、subscribersのpathを作成する
&OUJUZ @Entityでentityの宣言とテーブル名の宣言をする sequelize-typscriptと大きく変わらない
4FSWJDF コンストラクタでentityからリポジトリを生成してDI リポジトリからテーブルを操作
.JHSBUJPO エンティティの変更履歴を確認して自動生成 DBにMigrationsテーブルが作成され実行履歴が確認できる リレーションも簡単に定義可能 TypeORM最高じゃん!
ҙ
.JHSBUJPOͷ᠘ DBに接続(サーバー立ち上げておかないと)migrationできない entityを作る・消すをしていると消したはずのentityのmigrationが残る Date型がstringとして帰ってくるケース
ௗ͡ΌΜʂ
ݪҼ
ݪҼ
͓·͑ͩͬͨͷ͔
ରࡦ distを消して再度npm run build npm run prestart:prodでも同じ ごめんねTypeORM
%BUFܕͷऔѻ͍ 例えばこんなentityを用意した場合は要注意
%BUFܕͷऔѻ͍ IUUQTHJUIVCDPNUZQFPSN UZQFPSNJTTVFT
%BUFܕͷऔѻ͍ ΧϥϜͷλΠϓΛEBUFʹ͢Δͱ %BUFܕΛఆ͍ٛͯͯ͠ TUSJOH͕ฦͬͯ͘Δ
カラムの値をチェックする条件文が常に通らない(string型 ≠ Date型) asを使って型をcastし始める 型の正誤性が取れなくなる
ରࡦ time stampを使いましょう(Date型を返す) できるだけcastは使いたくないよね 時間の取扱いって難しいよね
5ZQF03.ͷϝϦοτ Migrationは癖があるけど、使い勝手がよい(ただしsynchronizeは…) 型の恩恵もそれなりに受けられる 導入までに時間がかからない(ほんの数分でできた) 非同期処理もスムーズに書けるNestとの相性は良好 リレーションで取得したプロパティにentityの型がつく
5ZQF03.ͷ͍͠ͱ͜Ζ タイプセーフなの? Date型の件から察するにコンパイル時に怒られない場合が高い 型をcastする可能性も高い subscribersでどうにかしてください、だと辛い
࣍ճҎ͍߱ͬͯ͘͜ͱ expressからNestJSにお引越し作戦(今回は間に合いませんでした) TypeORMとTypeScriptの親和性を検証
5IBOLZPV @tascript Fukuoka.ts