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
540
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
ONE WEDGE_company_guide
1wedge_one
0
490
Compose-View Interop in Practice (mDevCamp 2024)
stewemetal
0
140
StoreKit2によるiOSのアプリ内課金のリニューアル
kangnux
0
110
検証も兼ねて個人開発でHonoとかと向き合った話
hanetsuki
1
1.1k
0→1と1→10の狭間で Javaという技術選定を振り返る/Reflecting on the Decision to Choose Java Between Scaling from 0 to 1 and 1 to 10
jaguar_imo
2
380
educure_カリキュラム生操作マニュアル.pdf
linew_official
0
810
VSCodeでのDatabricks開発もお勧めしたい/I would also recommend Databricks development with VSCode.
kazumain
0
260
Fragment Composition of GraphQL
quramy
7
1k
冗長なエラーログを削減し、スタックトレースを手に入れる / Reducing Verbose Error Logs and Obtaining Stack Traces
upamune
0
780
ゆるい個人開発のススメ
kuroppe1819
10
990
try!Swift Tokyo 2024 参加報告 LT
akidon0000
1
220
Build Apps for iOS, Android & Desktop in 100% Kotlin With Compose Multiplatform (mDevCamp 2024)
zsmb
0
340
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
16
2.6k
Practical Orchestrator
shlominoach
182
9.7k
Making the Leap to Tech Lead
cromwellryan
124
8.5k
A Philosophy of Restraint
colly
197
16k
Bash Introduction
62gerente
604
210k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
17
1.4k
We Have a Design System, Now What?
morganepeng
43
6.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
116
18k
Side Projects
sachag
451
41k
The Illustrated Children's Guide to Kubernetes
chrisshort
31
46k
Code Reviewing Like a Champion
maltzj
514
39k
Docker and Python
trallard
34
2.7k
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 最高!