NestJS Meetup #3 NestJS導入してみた

by Kouki

Slide 1

Slide 1 text

NestJS導入してみた PHPが主体の会社になぜ導入したのか? 2022.07.22 koki.okawa

Slide 2

Slide 2 text

@o_kouchanne 大川　航貴 Koki Okawa Webエンジニア6年目バックエンドを中心に幅広くやってます。

Slide 3

Slide 3 text

アジェンダ ● なぜNestJSを導入したの? ● NestJSを採用した決め手 ● NestJSがハマると思うところ

Slide 4

Slide 4 text

なぜNestJSを導入したの？

Slide 5

Slide 5 text

最初はNestJSというより Node.jsがマストだった

Slide 6

Slide 6 text

Node.jsがマストの技術要件だった今回のプロジェクトでは双方向通信をするためにWebSocketが必要だったので、Node.jsを使わなきゃいけないという条件があった APIはPHPでWebSocketだけは別途でNode.jsサーバーを立てて内部で通信をするみたいな時間がなかった...

Slide 7

Slide 7 text

エンジニアがフルスタック PCアプリ → Electron フロントエンド → React フロントエンドはJSがもう確定している状態で、開発するエンジニアはフロントエンド・バックエンドどちらもフルスタックに対応する必要があった。その際の言語の切り替えが開発体験を著しく下げてしまうのを防ぎたかった。

Slide 8

Slide 8 text

ではなぜNestJSになったの？

Slide 9

Slide 9 text

最初はExpressでやろうとおもった私自身はExpressでAPIを作った経験があったのでExpressでやろうと思った。しかし、Expressはフレームワークの性質上シンプルなのでWebフレームワークのベストプラクティスをある程度知っていないとプロジェクトが崩壊してしまうと感じていた。しかも、アサインされたメンバーはPHP x Laravelしかやったことないメンバーなので自分も手を動かしながらそこまでのハンドリングがちゃんとできるのだろうか？...

Slide 10

Slide 10 text

シンプルなフレームワークで失敗した過去あり PythonのFlaskというフレームワークを使った際にカオスな状態を作って失敗した経験があるシンプルなフレームワークは気軽に実装できる反面ある程度の規模になるとルールを作り込めないと崩壊することを学んでいた

Slide 11

Slide 11 text

Expressをカスタマイズ ORM → TypeORM を導入 Controller → routing-controllers を導入 TS化 → webpack で開発環境構築してデザインパターン → ディレクトリ構成を考えて... おやっ？これ全て揃ってるやつすでにあるじゃん...

Slide 12

Slide 12 text

そう! NestJSがあるじゃないか!

Slide 13

Slide 13 text

NestJSを採用した決め手

Slide 14

Slide 14 text

公式ドキュメントが充実している英語が読めればOK APIを作る際に必要なことはだいたい乗っている

Slide 15

Slide 15 text

スポンサーが充実しているある程度長期的に使って行けそうな安心感があった。 Node.jsのWEBフレームワークとして発展していきそうなイメージを持てた

Slide 16

Slide 16 text

TypeScriptがデフォルト昔と違って NotFound @type/hogehoge って言われることがなくなったので現代でTypeScriptを導入しない選択肢はない TypeScriptはwebpackで頑張る時代を生きてきた身にとっては、あの管理がなくなるのは最高に開発体験が良かった

Slide 17

Slide 17 text

Expressがベースである Expressがベースなので、Expressのことが分かっていれば大体のことは理解できた Express用のライブラリとのハイブリットな構成も実現可能 NestJSが用意していない機能等が必要になった場合は、Expressの Middlewareの作り方を知っていればなんとかなる

Slide 18

Slide 18 text

DIの仕組みが素敵自前で依存関係の注入は結構しんどいところがあります多分、シングルトンオブジェクトの作り方とか知らなかったらそもそもそこまでたどり着かない説がある NestJSはそのあたりを気にせずに実装できるのがすごくよいですよね使い勝手としてはJava/Spring Bootに近いのもポイントが高い

Slide 19

Slide 19 text

Nest CLI がある LaravelをやっていたメンバーにやってもらうにはCLIで色々できるという点は余計なことを考えなくて済むのでとても良かった。初期構築がとても楽、他のプロダクトでも導入するってなった際に環境差分を生みにくい webpackの自作はマジでしんどい

Slide 20

Slide 20 text

NestJSがハマると思うところ

Slide 21

Slide 21 text

中規模以上のサービス APIエンドポイントが複数あるような簡易的サービスじゃない場合は導入を検討したほうが良いです。 ORMが必要になってくるようなプロダクトは、Expressを使うと自前でハンドリングするのが大変になるのでNestJSを使うと幸せになれる気がする。逆にマイクロサービスとして展開するくらいであれば、オーバースペックかなという感じもある

Slide 22

Slide 22 text

フロント兼バックエンドなチーム弊社のように、フロントエンドとバックエンドで明確に分業がされていなくてどちらも対応しなきゃいけないようないわゆるフルスタックなチームには言語感のノイズがなくなって最高エンジニアの採用もTypeScript(JS)に一本化できるし

Slide 23

Slide 23 text

後々GraphQLを検討している人 GraphQLを導入したいけど、社内のリソースや技術スタックを考えたときにまずはREST APIから導入したい NestJSはそもそもフレームワークでREST APIもGraphQLもどちらも対応しているので、そのために新しく環境を新設する必要がないです。適切なServiceを作っておいて、追々GraphQLに移行していくという進め方も十分可能だと思います。

Slide 24

Slide 24 text

BFFサーバーとしての利用マイクロサービスマイクロサービスマイクロサービスフロントエンドそのまま、全てをNestJS内に完結しても十分利用できますがクライアントサイドとの中継役のBFFとしてのポテンシャルは高いと感じました。

Slide 25

Slide 25 text

NestJS 最高!