NestJS Meetup #3 NestJS導入してみた

NestJS Meetup #3 の際に発表した登壇資料になります。

アーカイブはこちら
https://www.youtube.com/watch?v=tdg7IBb-oOQ

Transcript

1. NestJS導入してみた PHPが主体の会社になぜ導入したのか? 2022.07.22 koki.okawa
2. @o_kouchanne 大川　航貴 Koki Okawa Webエンジニア6年目 バックエンドを中心に 幅広くやってます。
3. アジェンダ • なぜNestJSを導入したの? • NestJSを採用した決め手 • NestJSがハマると思うところ
4. なぜNestJSを導入したの？
5. 最初はNestJSというより Node.jsがマストだった
6. Node.jsがマストの技術要件だった 今回のプロジェクトでは双方向通信をするためにWebSocketが必要だったの で、Node.jsを使わなきゃいけないという条件があった APIはPHPでWebSocketだけは別途でNode.jsサーバーを立てて内部で通 信をするみたいな時間がなかった...
7. エンジニアがフルスタック PCアプリ → Electron フロントエンド → React フロントエンドはJSがもう確定している状態で、開発するエンジニアはフロント エンド・バックエンドどちらもフルスタックに対応する必要があった。 その際の言語の切り替えが開発体験を著しく下げてしまうのを防ぎたかった。
8. ではなぜNestJSになったの？
9. 最初はExpressでやろうとおもった 私自身はExpressでAPIを作った経験があったのでExpressでやろうと思っ た。 しかし、Expressはフレームワークの性質上シンプルなのでWebフレームワー クのベストプラクティスをある程度知っていないとプロジェクトが崩壊してしまう と感じていた。 しかも、アサインされたメンバーはPHP x Laravelしかやったことないメンバー なので自分も手を動かしながらそこまでのハンドリングがちゃんとできるのだろ うか？...
10. シンプルなフレームワークで失敗した過去あり PythonのFlaskというフレームワークを使った際にカオスな状態を作って失敗 した経験がある シンプルなフレームワークは気軽に実装できる反面ある程度の規模になると ルールを作り込めないと崩壊することを学んでいた
11. Expressをカスタマイズ ORM → TypeORM を導入 Controller → routing-controllers を導入 TS化 → webpack で開発環境構築して デザインパターン → ディレクトリ構成を考えて... おやっ？ これ全て揃ってるやつすでにあるじゃん...
12. そう! NestJSがあるじゃないか!
13. NestJSを採用した決め手
14. 公式ドキュメントが充実している 英語が読めればOK APIを作る際に必要なことはだいたい 乗っている
15. スポンサーが充実している ある程度長期的に使って行けそうな 安心感があった。 Node.jsのWEBフレームワークとして 発展していきそうなイメージを持てた
16. TypeScriptがデフォルト 昔と違って NotFound @type/hogehoge って言われることがなくなったので 現代でTypeScriptを導入しない選択肢はない TypeScriptはwebpackで頑張る時代を生きてきた身にとっては、あの管理 がなくなるのは最高に開発体験が良かった
17. Expressがベースである Expressがベースなので、Expressのことが分かっていれば大体のことは理 解できた Express用のライブラリとのハイブリットな構成も実現可能 NestJSが用意していない機能等が必要になった場合は、Expressの Middlewareの作り方を知っていればなんとかなる
18. DIの仕組みが素敵 自前で依存関係の注入は結構しんどいところがあります 多分、シングルトンオブジェクトの作り方とか知らなかったらそもそもそこまでた どり着かない説がある NestJSはそのあたりを気にせずに実装できるのがすごくよいですよね 使い勝手としてはJava/Spring Bootに近いのもポイントが高い
19. Nest CLI がある LaravelをやっていたメンバーにやってもらうにはCLIで色々できるという点は 余計なことを考えなくて済むのでとても良かった。 初期構築がとても楽、他のプロダクトでも導入するってなった際に環境差分を 生みにくい webpackの自作はマジでしんどい
20. NestJSがハマると思うところ
21. 中規模以上のサービス APIエンドポイントが複数あるような簡易的サービスじゃない場合は導入を検 討したほうが良いです。 ORMが必要になってくるようなプロダクトは、Expressを使うと自前でハンドリ ングするのが大変になるのでNestJSを使うと幸せになれる気がする。 逆にマイクロサービスとして展開するくらいであれば、オーバースペックかなと いう感じもある
22. フロント 兼 バックエンド なチーム 弊社のように、フロントエンドとバックエンドで明確に分業がされていなくてどち らも対応しなきゃいけないようないわゆるフルスタックなチームには言語感のノ イズがなくなって最高 エンジニアの採用もTypeScript(JS)に一本化できるし
23. 後々GraphQLを検討している人 GraphQLを導入したいけど、社内のリソースや技術スタックを考えたときにま ずはREST APIから導入したい NestJSはそもそもフレームワークでREST APIもGraphQLもどちらも対応して いるので、そのために新しく環境を新設する必要がないです。 適切なServiceを作っておいて、追々GraphQLに移行していくという進め方も 十分可能だと思います。
24. BFFサーバーとしての利用 マイクロ サービス マイクロ サービス マイクロ サービス フロント エンド そのまま、全てをNestJS内に完結 しても十分利用できますがクライア ントサイドとの中継役のBFFとして のポテンシャルは高いと感じまし た。
25. NestJS 最高!