NestJSでGraphQL APIを実装したのでメリットデメリットについて話そう

GWも始まって朝早起きして開発してみた。
所要時間がだいたい3時間程度。TypeORMまわりで時間食った。

今、開発にNestJSは使用していたこともあってそっちはRESTで組んでいるので個人プロジェクトの方ではGraphQLを入れてみた。

nestjs-graphql

個人的にNestJSについて思うことをいくつか書いてみようと思う。

NestJSを使うメリット

1つ目は開発スピードが爆速ということ。
速攻でアプリ開発ができるというメリットがある。
nestで用意されているコマンドが便利。
ベースになるソースコードを生成してくれるあたり使い勝手がよい。
またCRUDくらいであればコマンド一発で作ることが可能。

2つ目はアーキテクチャがイケてる。
アーキテクチャにおいてもモジュールの用途ごとにディレクトリを切ることができるので見通しよいの構成になっている

├── todo
│   ├── todo.module.ts
│   ├── todo.resolver.ts
│   ├── todo.schema.ts
│   ├── todo.service.ts
│   └── todo.validation.ts

GraphQLではこのような構成にしたのだけれどRESTなんかでいえば、クリーンアーキテクチャの構成でも組みやすい。

3つ目はモジュールが明確。
app.modulesですべての使用モジュールを呼び込んでひとまとめにすることができる。その点で何が使用されているのかも新しく入ってきたエンジニアがわかるのでよいと思う。

NestJSを使うデメリット

1つ目、柔軟性はない
express.jsのような柔軟性はない。
NestJSでexpress.jsを兼用して開発することも可能だが、それならexpress.jsを使ったほうがいい。
ディレクトリ構成が決まっているので自由なアーキテクチャでの開発はできない。

2つ目、大規模開発には不向きな気がする
最初の設計が悪かったということもあるかもしれないのだけれど、経験として。
どちらかといえばNestJSはクイックな開発、小規模アプリ開発に向いている。1つ目で述べたようにアーキテクチャの柔軟性はないので大規模開発においてはexpress.jsのようにある程度柔軟性のあるフレームワークをおすすめしたい。

例えば、DDDで組みたい時なんかはディレクトリ構成を自由に扱えない分、ファイル単位で名前を決めなければいけない。

├── todo
│   ├── todo.repository.ts
│   ├── todo.usecase.ts
│   ├── todo.domain.ts
│   ├── todo.response.ts
│   └── todo.validation.ts

メリットでイケてると書きましたがそれが悪くなることもあるわけです。
見通しはよいものの、ディレクトリ単位で切れない制約は少し面倒に思います。

3つ目
モジュールの依存関係が非常にわかりづらい。
エラーをみてもどこに依存しているのかというのがわかりづらく大規模開発になってファイル数が増えたときなんかでどこに依存しているのかわからなくなることがある。(これは単に自分が悪いのかもしれないが)
また、ファイル名を複数形にしなければモジュール依存が解決できないなど暗黙のルールで面倒くさい部分がある。

まとめ

NestJSでGraphQL APIを実装してみたのだけれど、やはり何か小規模なモノを素早く開発したいと思ったときなんかはすごくよいと思った。
クイックに開発したい人はやってみるとよいと思います。

結論からしてNode.jsはまだexpress.js一択のような気がします。
Koaもよいですが、express.jsほどnpmが存在しているわけではないですし、情報資産に関してもexpress.jsが優っています。

自分はまだFastifyを扱ったことがないのでこの辺今度やってみようかなと思ってます。

関連記事