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
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
180
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
890
Julia という言語について (FP in Julia « SIDE: F ») for 関数型まつり2025
antimon2
3
980
A2A プロトコルを試してみる
azukiazusa1
2
1.1k
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
190
Elixir で IoT 開発、 Nerves なら簡単にできる!?
pojiro
1
150
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
230
Bytecode Manipulation 으로 생산성 높이기
bigstark
2
380
Create a website using Spatial Web
akkeylab
0
300
「ElixirでIoT!!」のこれまでとこれから
takasehideki
0
370
Haskell でアルゴリズムを抽象化する / 関数型言語で競技プログラミング
naoya
17
4.9k
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
510
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
53
7.7k
Faster Mobile Websites
deanohume
307
31k
YesSQL, Process and Tooling at Scale
rocio
173
14k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
670
GitHub's CSS Performance
jonrohan
1031
460k
Balancing Empowerment & Direction
lara
1
370
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
5
210
Building an army of robots
kneath
306
45k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Done Done
chrislema
184
16k
Gamification - CAS2011
davidbonilla
81
5.3k
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 最高!