Expressでのチーム開発が辛いあなたのためのNestJS - ハードルを下げ続けるブログ@task

この記事は mohikanz Advent Calendar 2019の3日目です

昨日は gimKondo さんによる全人類が読むべき ITエンジニアの雑談Slack発オンライン読書会でした。

僕の記事は読まなくてもまっとうに生きていけますが、読んでくれると嬉しいです、

今年の2月に現職に転職し、プロジェクトの立ち上げ以来お世話になっている Framework: NestJS についてのご紹介

転職についてはこちらをどうぞ ↓

note.com

背景

わたし
- 未経験からエンジニアへキャリアチェンジ組(エンジニア歴は２年くらい)
- フロントエンドより(そうでもない)
- サーバーサイドの開発経験は Django
チーム
- 開発者 3人のうち2人がひよこ(私を含む)
- 途中で、フロントエンド寄りのスキルのメンバーがジョイン
プロダクト
- 新規Webサービス
- フロントエンドは Vue.js + TypeScript

NestJSとは

nestjs.com

TypeScript で記述された Node.js サーバーサイドアプリケーションのためのフレームワーク
DI(依存性注入) の思想から、オブジェクト同士の依存あとからを解決するため、オブジェクト間を疎結合にし、テストに優れる
実装内部のCoreな部分は Express であり、Express に明確な指針を与えてくれる

よく Angular ライクなと紹介されますが(Angularに強い影響を受けている)、当方 Angular わからないマンでもなんとか使えてるので、Angular好きな人のためのフレームワークってわけでもないです。(DIを強烈に信奉しているわけでもない)

NestJSの選定理由

インターフェースの型をフロントエンドとある程度合わせたい
サーバーサイド及びフロントエンドのコードを互いに流用できる(と思った)
開発経験豊富なベテランやExpressの開発になれた人はおらず、強烈な指針がないとすぐに負債化するのは目に見えていた
流行りそう

実際にNestJSを使ってみて何がよかったか

選定理由の3番目について一番利点を感じていて、開発経験が浅く、秀でたベテランエンジニアがいないチームでもある程度秩序をもった状態を維持できていることはとてもありがたく思ってます。

NestJSでは、Postされる値のバリデーションやレスポンスの整形などプレゼンテーション層は Controllerに、ユースケースは Service に、にとそれぞれの責務がはっきりとしているため、一つ見本的なコードがあれば、触ったことがない人でも割と簡単に新しいエンドポイントを実装する事ができます。実際に、途中で加わったメンバーも(それなりの力量はあったものの)かなり早い段階でサーバーサイドの実装ができるようになっていました。

また、Expressに秩序を与えるのと同時に、サーバーサイドフレームワークとして本質的ではないもの(DBへの接続など)に関してコアな部分は依存を持たないため、使用するライブラリーをかなり自由に選ぶことが可能です。