NestJSを実運用してみて.pdf

by gizm000

Slide 1

Slide 1 text

NestJSを実運用してみて営業製作所白石卓馬

Slide 2

Slide 2 text

会社紹介：営業製作所・設立 2020年4月・本社大阪 (肥後橋駅徒歩3分) ・従業員数約150名 (2024年4月時点) ・目的日本の製造業を支える・特徴泥臭い中にこそ本質がある

Slide 3

Slide 3 text

自己紹介・なまえ白石卓馬 (gizm000) ・出身地大阪・職種ソフトウェアエンジニア・経歴 SIer → 受託 → SaaS

Slide 4

Slide 4 text

営業製作所のざっくり技術スタック・フロントエンド：Next.js ・サーバーサイド：NestJS ・IaC：Terraform (CDKじゃないヨ) 業務で使う 80 98%以上がTypeScript

Slide 5

Slide 5 text

営業製作所のざっくり技術スタック・フロントエンド：Next.js ・サーバーサイド：NestJS ・IaC：Terraform (CDKじゃないヨ) 業務で使う 80 98%以上がTypeScript

Slide 6

Slide 6 text

NestJSを採用している

Slide 7

Slide 7 text

なぜNestJSを採用したか？・TypeScriptがサポートされている・GraphQLがサポートされている・PrismaORMのモジュールが提供されている・Node.js界隈ではわりと枯れている (2017年リリース, Star 66.9K) 　・Mediumとかで調べても結構情報がある　・最近は日本語の情報も増えてきている

Slide 8

Slide 8 text

なぜNestJSを採用したか？・(個人的には)わりと理解しやすい・DIはそこまで必要かはわからないが、楽ではある　・明示的に new する必要がない・サーバーに対するe2eテスト用のAPIも用意されている・ボイラープレートが多いので記述のブレを少なくできそう

Slide 9

Slide 9 text

実際に導入してみた感触としても悪くないが...

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

ポジティブな意見がわりとある！

Slide 12

Slide 12 text

最近、風当たりが強くない？ 🤔

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

ネガティブな意見が増えてきた・・・？

Slide 15

Slide 15 text

デコレータおよびDIがなぁ...

Slide 16

Slide 16 text

デコレータおよびDIがなぁ...

Slide 17

Slide 17 text

クラスにつけたり・・・デコレータ

Slide 18

Slide 18 text

プロパティにつけたり・・・デコレータ

Slide 19

Slide 19 text

@Fieldをつけると、 schema.gqlに GraphQLスキーマとして出力されるデコレータ

Slide 20

Slide 20 text

TypeScriptでstring型のため、 GraphQLでStringとして定義されているデコレータ

Slide 21

Slide 21 text

NestJSのデコレータはなぜダメ？・reflect-metadataを使って得られたメタデータを利用している・TypeScriptの emitDecoratorMetadata オプションを true にする必要・型定義の情報を利用するため、開発時に型チェックをスキップできない・ビルドが遅い... 😢 ・TypeScript 5.0からはレガシー機能となった・仕様の異なるデコレータが正式版として採択されてしまった・experimentalDecorators フラグを有効にすれば利用可能

Slide 22

Slide 22 text

デコレータおよびDIがなぁ...

Slide 23

Slide 23 text

依存性注入はいつ必要？

Slide 24

Slide 24 text

なぜ依存性を注入するのか・外環境に依存していて簡単にモックできるようにしたい・決済API, AWS SDKとか・依存するモジュールが多い・依存関係を記述するのが面倒臭い・同一のインタフェースを持っていれば付け替えられるようにしたい・GoF デザインパターンの Template methodパターンのイメージ

Slide 25

Slide 25 text

依存性注入に反対勢の意見・同一のIFを持った別オブジェクトに付け替えることそんなにある？・環境変数に依存するケースぐらいではないか・異なるロガーを付け替えられるようにとか、本当にある？・エラーがわかりにくい、依存関係がわかりにくい・Nest can't resolve dependencies…. ・依存関係を表示するツールがまさかの有料

Slide 26

Slide 26 text

果たして、本当にDIは必要か？ TypeScriptであれば、依存関係は型定義によって担保されるので、十分なのでは...？

Slide 27

Slide 27 text

Now coding...

Slide 28

Slide 28 text

・依存関係は明確にしよう！・関数単位で依存している方が楽だぞ！

Slide 29

Slide 29 text

・依存関係は明確にしよう！・関数単位で依存している方が楽だぞ！ NestJSはどこまで依存しているかわからなくて大変になる... 子モジュールが依存している孫モジュールのimportがされていないくてエラーになるとか、めんどくさい！！！

Slide 30

Slide 30 text

ところで...

Slide 31

Slide 31 text

experimentalDecoratorに依存していなくてコードファーストに書ける GraphQLライブラリ...

Slide 32

Slide 32 text

experimentalDecoratorに依存していなくてコードファーストに書ける GraphQLライブラリ... 実はまだない ?

Slide 33

Slide 33 text

1. Pothos (旧GraphQL Nexus) 2. GraphQL Modules 3. type-graphql-next どれも使ったことない...󰷺 Claude調べ

Slide 34

Slide 34 text

ご清聴ありがとうございました

Slide 35

Slide 35 text

さいごに・絶賛採用活動中です❗ → X, LinkedIn, Green, LAPRAS, … 　情報交換程度でも良いので、　よかったらご連絡を😆