Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
NestJS Meetup #3 NestJS導入してみた
Search
Kouki
July 25, 2022
Programming
0
710
NestJS Meetup #3 NestJS導入してみた
NestJS Meetup #3 の際に発表した登壇資料になります。
アーカイブはこちら
https://www.youtube.com/watch?v=tdg7IBb-oOQ
Kouki
July 25, 2022
Tweet
Share
Other Decks in Programming
See All in Programming
ご注文の差分はこちらですか? 〜 AWS CDK のいろいろな差分検出と安全なデプロイ
konokenj
4
610
TypeScriptでDXを上げろ! Hono編
yusukebe
3
820
Workers を定期実行する方法は一つじゃない
rokuosan
0
110
20250708_JAWS_opscdk
takuyay0ne
2
130
AI Agent 時代のソフトウェア開発を支える AWS Cloud Development Kit (CDK)
konokenj
6
850
Git Sync を超える!OSS で実現する CDK Pull 型デプロイ / Deploying CDK with PipeCD in Pull-style
tkikuc
4
380
Claude Code で Astro blog を Pages から Workers へ移行してみた
codehex
0
120
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
480
Model Pollution
hschwentner
1
160
Streamlitで実現できるようになったこと、実現してくれたこと
ayumu_yamaguchi
2
120
Vibe Codingの幻想を超えて-生成AIを現場で使えるようにするまでの泥臭い話.ai
fumiyakume
16
8.5k
「App Intent」よくわからんけどすごい!
rinngo0302
1
110
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Gamification - CAS2011
davidbonilla
81
5.4k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
47
9.6k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Done Done
chrislema
184
16k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
350
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
21
1.3k
It's Worth the Effort
3n
185
28k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
980
Transcript
NestJS導入してみた PHPが主体の会社になぜ導入したのか? 2022.07.22 koki.okawa
@o_kouchanne 大川 航貴 Koki Okawa Webエンジニア6年目 バックエンドを中心に 幅広くやってます。
アジェンダ • なぜNestJSを導入したの? • NestJSを採用した決め手 • NestJSがハマると思うところ
なぜNestJSを導入したの?
最初はNestJSというより Node.jsがマストだった
Node.jsがマストの技術要件だった 今回のプロジェクトでは双方向通信をするためにWebSocketが必要だったの で、Node.jsを使わなきゃいけないという条件があった APIはPHPでWebSocketだけは別途でNode.jsサーバーを立てて内部で通 信をするみたいな時間がなかった...
エンジニアがフルスタック PCアプリ → Electron フロントエンド → React フロントエンドはJSがもう確定している状態で、開発するエンジニアはフロント エンド・バックエンドどちらもフルスタックに対応する必要があった。 その際の言語の切り替えが開発体験を著しく下げてしまうのを防ぎたかった。
ではなぜNestJSになったの?
最初はExpressでやろうとおもった 私自身はExpressでAPIを作った経験があったのでExpressでやろうと思っ た。 しかし、Expressはフレームワークの性質上シンプルなのでWebフレームワー クのベストプラクティスをある程度知っていないとプロジェクトが崩壊してしまう と感じていた。 しかも、アサインされたメンバーはPHP x Laravelしかやったことないメンバー なので自分も手を動かしながらそこまでのハンドリングがちゃんとできるのだろ
うか?...
シンプルなフレームワークで失敗した過去あり PythonのFlaskというフレームワークを使った際にカオスな状態を作って失敗 した経験がある シンプルなフレームワークは気軽に実装できる反面ある程度の規模になると ルールを作り込めないと崩壊することを学んでいた
Expressをカスタマイズ ORM → TypeORM を導入 Controller → routing-controllers を導入 TS化
→ webpack で開発環境構築して デザインパターン → ディレクトリ構成を考えて... おやっ? これ全て揃ってるやつすでにあるじゃん...
そう! NestJSがあるじゃないか!
NestJSを採用した決め手
公式ドキュメントが充実している 英語が読めればOK APIを作る際に必要なことはだいたい 乗っている
スポンサーが充実している ある程度長期的に使って行けそうな 安心感があった。 Node.jsのWEBフレームワークとして 発展していきそうなイメージを持てた
TypeScriptがデフォルト 昔と違って NotFound @type/hogehoge って言われることがなくなったので 現代でTypeScriptを導入しない選択肢はない TypeScriptはwebpackで頑張る時代を生きてきた身にとっては、あの管理 がなくなるのは最高に開発体験が良かった
Expressがベースである Expressがベースなので、Expressのことが分かっていれば大体のことは理 解できた Express用のライブラリとのハイブリットな構成も実現可能 NestJSが用意していない機能等が必要になった場合は、Expressの Middlewareの作り方を知っていればなんとかなる
DIの仕組みが素敵 自前で依存関係の注入は結構しんどいところがあります 多分、シングルトンオブジェクトの作り方とか知らなかったらそもそもそこまでた どり着かない説がある NestJSはそのあたりを気にせずに実装できるのがすごくよいですよね 使い勝手としてはJava/Spring Bootに近いのもポイントが高い
Nest CLI がある LaravelをやっていたメンバーにやってもらうにはCLIで色々できるという点は 余計なことを考えなくて済むのでとても良かった。 初期構築がとても楽、他のプロダクトでも導入するってなった際に環境差分を 生みにくい webpackの自作はマジでしんどい
NestJSがハマると思うところ
中規模以上のサービス APIエンドポイントが複数あるような簡易的サービスじゃない場合は導入を検 討したほうが良いです。 ORMが必要になってくるようなプロダクトは、Expressを使うと自前でハンドリ ングするのが大変になるのでNestJSを使うと幸せになれる気がする。 逆にマイクロサービスとして展開するくらいであれば、オーバースペックかなと いう感じもある
フロント 兼 バックエンド なチーム 弊社のように、フロントエンドとバックエンドで明確に分業がされていなくてどち らも対応しなきゃいけないようないわゆるフルスタックなチームには言語感のノ イズがなくなって最高 エンジニアの採用もTypeScript(JS)に一本化できるし
後々GraphQLを検討している人 GraphQLを導入したいけど、社内のリソースや技術スタックを考えたときにま ずはREST APIから導入したい NestJSはそもそもフレームワークでREST APIもGraphQLもどちらも対応して いるので、そのために新しく環境を新設する必要がないです。 適切なServiceを作っておいて、追々GraphQLに移行していくという進め方も 十分可能だと思います。
BFFサーバーとしての利用 マイクロ サービス マイクロ サービス マイクロ サービス フロント エンド そのまま、全てをNestJS内に完結
しても十分利用できますがクライア ントサイドとの中継役のBFFとして のポテンシャルは高いと感じまし た。
NestJS 最高!