FastAPIインプレッション
仕事で3ヶ月ほど使っての感想
Pros
ビルトインでOpenAPIドキュメントが自動生成される体験はとてもいい
他のフレームワークでも何らかの方法で採用して欲しい
Pythonビルトインの関数は質が良いのであまりユーティリティ系の外部ライブラリを必要としない点は良い
lodashとかそういった類の
Pythonで決め打ちで使いたいライブラリがあって他言語にポートや代替物が無いなら悪くない
ML系など
単にただ他のAPIを叩くためのWrapperなどならFastAPIである必要はないなと(OpenAI等)
Cons
WebServerとして使うにはあまりMatureな感じがしない
gunicornとかuvicornとか
gunicornはタイムアウトがアバウトだったり謎の落とし穴がある(やはりとりあえず前段にnginxをかませておくというのは何のWAF使うにしてもあり)
Unopinionatedなところ
つまりこれを使え、ここにこれを置けというざっくりとした指針が公式にないこと。どういった方針にし、どういった依存を使うかは全てチーム、プロジェクト次第ということになる
それ故適用範囲が広いとも言えるが逆に言えばスキルをトランスファー出来ないということにもなる
それぞれのライブラリが特定のフレームワーク専用という感じでもないのでintegrationする際に不格好な感じになる
pytest, sqlalchemy等
sqlalchemyはFastAPIだけでなく別のWAFでも使える汎用的なORMライブラリだが、そのせいでややフレームワークレベルでの深いintegrationに欠ける
セッションの取り回しは自分で考える必要あるなど
そのせいでセッションリークなど注意する必要があるし大体自分で実装するとバグが出る
テスト周りの設計も自分で都度考える必要がありpytest, sqlalchemy, factoryなど自分でテストの取り回しを考える必要がある
これもフレームワークと深くintegrationしているわけではないので統一感のない感じになる
公式で推奨しているようなディレクトリ構造等もなくFastAPI自体は薄いフレームワークを志向しているようなので、これ自体で何十もエンドポイントを生やすのはあまり想定していないユースケースかもしれない
ミニマル志向
多くて10個以内のそれぞれ単一機能のエンドポイントだとうまくワークしそうな感じはある。それ以上はFlask, Djangoの方がMatureでうまくいくと思う
ハイパフォーマンスだと言われているが世の中のリアルアプリケーションはDBへほぼアクセスするので別にFastAPI自体がハイパフォーマンスである必要はない
よく考えられてはいるもののやはりカチッと型にはめるようなタイプではないのでFastAPI自体で膨大なロジックを組むというのはミスマッチだと思う
ここから別のエンドポイントへ接続したりバックグラウンドの細々として処理を行うBFF的な使い方がよいと思う(FastAPIがDBを前提としないという点もそういった点もある気がする)
FastAPIのいい点として非同期処理をシンプルにasync awaitで書けるという点があるので
多数のバックエンドの待ち合わせ場所としてやTypeが使えることでglueがしやすくなっていると思う
グルー(glue) として使うフレームワークとしては結構よい
単純な配列処理のしやすさ(map, reduce, filter)やビルトインメソッドでの文字列処理のしやすさなど
Python自体でロジックをいっぱい書く必要があるならDjangoやFlaskの方がよいと思う
DBアクセスが存在するアプリケーションの時点でFastAPIのメリットはそこまでない
ユースケースとしては多数の並行処理を扱ったりWebsocketのようなリアルタイム性のあるアプリケーションが必要な場合がいい
そういったエンドポイントは比較的限られているのでやはり全てにおいてFastAPIというのはやはりアンチパターンで、特定のパフォーマンスを必要とするDBアクセスを必要としないエンドポイントでFastAPIというのが適切な気がする
例えばWebsocketでいいねをブロードキャストするとか. 並行してEmail送信のためのキューに書き込むとか