FoalTSを使ってみた。これは熱いフレームワークだ。

FoalTS

久しぶりに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
Elegant and complete Node.Js web framework based on TypeScript.

私が思うFoalTSのいいところは下記です。

  • 純粋なAPI開発フレームワーク
  • TypeScript前提
  • ORMもTypeORMがデフォルトで組み込まれている
  • 実装の内容を、openapi形式でAPI仕様のドキュメントを出力できる

純粋なAPI開発フレームワーク

これはそのままです。

TypeScript前提

これもそのままです。

TypeORMがデフォルトで組み込み

巷ではPrismaが熱そうですが、TypeORMも結構実績ありそうだったので、ORMの技術選定にそこまで苦労しなくて済むというのは私にとっていいことでした。
また、デフォルトで組み込みなので、ORMの設定がある程度最初からセッティングされているのも楽ですね。ここらへんがNestJSよりもFoalTSの方が私好みになった要因です。

openapi形式でAPI仕様のドキュメントを出力

この特徴が一番熱いです。
openapiでAPIの仕様書を出力することができれば、openapi-generatorで型定義とAPIをコールするためのクライアントコードを出力することができます。

GitHub - OpenAPITools/openapi-generator: OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec ...

これによって、型安全にAPIをコールすることが可能となります。

終わりに

次は、実際に開発フローをブログに書いていけたらと思います。

[追記]
開発フローのブログ書いてみた。

FoalTS + openapi-generatorで型安全なAPI開発
この前はFoalTSについて紹介しました。この記事では実際に開発フローを紹介していきたいと思います。基本的には公式のチュートリアルに沿っていきますが、最後の方で、「型安全」について触れたいと思います。記事執筆時点での環境です$ no...
タイトルとURLをコピーしました