久しぶりにGASじゃない話。
と言うか、フロントエンドでもなく、今日はバックエンドの話。
FoalTSが私の中で熱いという話をしたいと思います。
巷ではNestJSの方が人気かと思いますが、、、
フレームワークの選定基準
まずは、私がFoalTS熱いと感じた経緯についてお話しします。
Webアプリを開発する際に、どのフレームワークを使おうか模索している中で重要な観点は以下でした。
- Node + TypeScriptだと、言語のキャッチアップがいらない
- APIとUIが疎結合な設計思想
- APIのレスポンスをフロントエンド側で型安全に扱える仕組みがある
Node + TypeScriptだと、言語のキャッチアップがいらない
これは単に私のスキルセットの都合です。
APIとUIが疎結合な設計思想
Ruby on RailsのようなAPIとUIが密に結合するような形ではなく、APIを作るためのフレームワークとUIを作るためのフレームワークは別々にしたい、ということです。（APIモードは別ですが）
これは、私がUI側のフレームワークを生のReactやNext.jsで扱いたかったからというのが大きいです。
APIのレスポンスをフロントエンド側で型安全に扱える仕組み
UIからfetchやaxiosを使用してAPIを直接叩くと、もちろんですがレスポンスの型はanyになります。
例えば、APIの仕様変更に伴うUIの実装変更をしなければいけない場合などに、実装漏れが発生しやすくなると思います。
型安全にレスポンスを扱うことができれば、こういったことは防ぎやすくなります。
FoalTSの特徴
そこでFoalTSですよ。
私が思うFoalTSのいいところは下記です。
- 純粋なAPI開発フレームワーク
- TypeScript前提
- ORMもTypeORMがデフォルトで組み込まれている
- 実装の内容を、openapi形式でAPI仕様のドキュメントを出力できる
純粋なAPI開発フレームワーク
これはそのままです。
TypeScript前提
これもそのままです。
TypeORMがデフォルトで組み込み
巷ではPrismaが熱そうですが、TypeORMも結構実績ありそうだったので、ORMの技術選定にそこまで苦労しなくて済むというのは私にとっていいことでした。
また、デフォルトで組み込みなので、ORMの設定がある程度最初からセッティングされているのも楽ですね。ここらへんがNestJSよりもFoalTSの方が私好みになった要因です。
openapi形式でAPI仕様のドキュメントを出力
この特徴が一番熱いです。
openapiでAPIの仕様書を出力することができれば、openapi-generatorで型定義とAPIをコールするためのクライアントコードを出力することができます。
これによって、型安全にAPIをコールすることが可能となります。
終わりに
次は、実際に開発フローをブログに書いていけたらと思います。
[追記]
開発フローのブログ書いてみた。
