yikegaya’s blog

仕事関連（Webエンジニア）について書いてます

Ruby on Rails脳でNest.jsを使いながらWeb開発フレームワークについて思ったこと

Nest.js Rails

フロントエンドReact（Remix）、バックエンドNest.jsで目標管理Webサービスを開発してみました。

github.com

1年少しRailsでバックエンド開発しておりRailsに慣れきった状態で初めてNest.js使って今回開発してみました。開発体験の感想をざっと書いてみます。

（一応）名前がややこしいですがNest.jsとはReactのフレームワークNext.jsやVue.jsのフレームワークNuxt.jsとは別物でjsでバックエンドのWebサーバを開発するためのフレームワークです。

以下ざっくり感想

Webフロントエンドはサポート外である点について

ActionViewを提供しているRailsとは違ってNest.jsはWebフロントエンドはサポートしていません。

2025年現在だとエンタープライズのプロダクトではフロントエンドのフレークワークはバックエンドと分離して構成するパターンが多数派と思われるのでエンタープライズの大規模Webサービスを開発するのであればこれで十分かと思います。

一方プログラミング初心者が一旦Webサービスを一通り実装することを目的にフレームワークを選択する場合やエンタープライズでも小規模であまりスケールさせる要件がない場合は現在でもRailsは有力な選択肢になるかと思います。

フロントエンドとバックエンドが分離するとRailsのような全部込みのフレームワークではサポート外の要件が増えるので初学者には辛いかなと。

特にユーザ認証、CORSなど諸々のクライアントとサーバ間の認証実装などセキュリティ関連の対応難易度が跳ね上がるのは大きいと個人的には思います。

ORマッパーはサポート外である点について

ActiveRecordのようなORマッパーも提供していません。

これは以下のような歴史的経緯とメリットがあるのかと考察してます

  • Ruby界隈では実質的にActiveRecordが1強ですがTypeScript界隈はそれに比べるとまだORMの選択肢が乱立している
  • Railsが開発された当時はおそらくWebサービスでRDBを使わないことはほぼなく（小規模アプリでもSQLiteくらいは使ってた？）ORMが必須状態だったが現状ではストレージをNoSQLだけで完結させるサーバレスアーキテクチャが浸透しているので分離されている

デメリットとしてはやはり別途ORマッパーをセットアップしてNest.jsのアーキテクチャ内にDB接続のロジックを組み込む必要があるので初速は遅くなると思います。

今回の個人開発ではDBはPostgresql、ORマッパーはPrismaを採用して開発してみましたがPrismaは結構ActiveRecordに近い感覚で実装できて使いやすかったかな、と思います。

ドメインロジックの扱い

RailsではHTTPリクエストはコントローラ層で受けてドメインロジックは基本的にDBのテーブルと1対1になったActiveRecordクラスを継承した1つのModelクラスで管理するのが基本です。

ただサービスが大規模になってくると複数テーブルを1度に扱う必要があるドメインロジックやテーブルと無関係なロジックが出てくるのでDBとのマッピングをせずにドメインロジックを扱えるActiveModelを継承したクラスを作ったりフレームワークの機能としては提供されていないサービスクラスを実装することでドメインロジックを整理してきます。

Nest.jsではコントローラ層でHTTPリクエストを受けてレスポンスに対応するプロバイダとしてサービスクラスに実装されたドメインロジックを提供するアーキテクチャのようです。またスキーマをバリデーションするためのDTOと呼ばれるクラスを使用します。

ここに対してORマッパーなどによるストレージサーバへのアクセスをどうドメインロジックに組み込むかはフレームワーク側では明確になっておらず実装者側で検討する必要がありそうです。

アプローチに多少違いはあるもののドメインロジックとドメインロジック外の部分をどう分離するか、ドメインロジック間の境界をどう引くかについての根本的な設計思想はそこまで大きく変わらないのではないかと思ってます。

その他のフレームワークとの比較

テンプレートエンジンによるWeb UIのサポート、ORMが提供という意味でRuby on RailsはPythonのDjango、PHPのLaravelと近しいかと思います。

対してNest.jsはHTTPリクエストの処理に特化しているという点でPythonのFastAPIやFlask、GoのGinなどに近い感覚で使えるフレームワークかと思います。

まとめ

近年Nest.jsのようなHTTPリクエストに特化したフレームワークが勢いを持っている理由としては以下のような要因があるかと思います。

  • 多くのエンタープライズ向けのサービスでWebに加えてモバイルなどWeb以外へのUI提供が必要になることが多くなりフレームワークの責務からUIを剥がす方が合理的なケースが増えてきた
  • サーバレスアーキテクチャの流行でRDBのサポートも剥がす方が合理的なケースが出てきた

一方以下のような理由で初学者にはNest.jsやFastAPIでセキュアなサービスを実装、リリースするのは辛そうなので全部込みフレームワークの需要は一定残り続けると思います

  • フロントエンドとバックエンドを別々に構成してユーザ認証を実装するのは複雑でそれなりに知識と経験が必要（Cookieなどのブラウザストレージ、暗号化、セッションの仕組み、JWTトークンの仕様、OAuth0などの認証サービスを使った実装とスクラッチ実装の比較など
  • DB接続ロジックとドメインロジックをどう分離するのがベストかは諸説あって迷いがち（クリーンアーキテクチャ、MVC、レイヤードアーキテクチャなどなど）
  • フロントエンドとバックエンドを別の構成にした場合それぞれどのサーバにデプロイしてサーバ間を同セキュアに接続するかについてはバックエンドエンジニアの責務を超えて求められるインフラエンジニア寄りの知識が増えてくる（ドメイン、IPアドレス制限やAWS、GCP、Vercel、CloudFlareなどのクラウドサービスを扱うスキル
  • 一方全部込みのフレームワークで実装したWebサービスを単純にEC2やHerokuraでデプロイしようとする場合はフレームワーク側のサポートも手厚くWeb上での情報量も多いので挫折しにくい

終わり。