すごく良い投稿だね！実際のアプリケーションに役立つ重要な詳細に触れてる。Litestarのデザインが大好きなんだ。 > それに、リポジトリやサービスレイヤーの悪い使い方がたくさんあると思うから、みんな避けた方がいいよね。でも、それはちょっと脱線だから、別の投稿にした方がいいかも。リポジトリパターンの大ファンとして、この投稿を楽しみにしてるよ。

これはPythonのウェブフレームワークだよ。クリックする前にもっと知りたい人のために。

これを書いてくれてありがとう。ここ数年FastAPIでアプリを開発してきて、似たような不満があるんだ。FastAPIのドキュメントが素晴らしいっていう態度がどれだけ一般的か、驚かされることが多いよ。チュートリアルやおもちゃの例が実際の開発やAPIの測定からどれだけ離れているかを考えるとね。

もう1年以上Litestarを使ってるけど、JSONとテンプレートHTMLの両方を提供してる。すごくバランスの取れたPythonの非同期フレームワークで、速さ（FastAPIより速い）や軽量さを保ちながら、認証やセッションなどの機能も十分に備えてる。msgspecのファーストクラスサポートと、ネストされたルーティング用のControllerクラスが気に入ってる。めっちゃおすすめだよ。

これを書いてくれてありがとう。ここ1年ほどFastAPIで大きなバックエンドを構築していて、いろんな苦労を経験したよ。最初は標準の「チュートリアル」スタイルを使ってたけど、公式テンプレートがCRUD操作を全部1つのファイルにまとめてるのを見たときは、ちょっと引いたね（前にRailsやSpringをやってたから）。依存関係の管理の仕方も…正直、あまり快適じゃなかったよ。それからSQLModelの問題が出てきた。著者はFastAPIのドキュメントでそれを強く推してるけど（正直、ドキュメントはひどいと思う。ドキュメントを探してるときは、ドキュメントが欲しいんだ、派手なチュートリアルじゃなくて）、ORMとして（はい、SQLAlchemyの上にあるレイヤーだって知ってるけど）ポリモーフィックモデルもサポートしてないし、コミュニティからのPRも何ヶ月もレビューなしで放置されてることがある（もうメンテされてるのかも分からない）。大きなプロジェクトを作るためにFastAPIを選んだのは自分の責任だと思うけど、かなり使った後（コードも読んだし、再度言うけどドキュメントが極めて貧弱だから）真剣なプロジェクトにはおすすめしないよ。確かに、クイックなCRUDを作りたいならSQLModelとFastAPIを使ってもいいけど、複雑なアプリケーションには向いてないからね（少なくとも、俺が不幸にもやったように、上にフレームワークを書く必要がある）。だから、この投稿の著者には大感謝！明日目が覚めたらLitestarに移行するつもりだよ。

FastAPIが注目されてるのは分かるけど、普通のStarletteも結構使えるよ。確かに全部の機能が揃ってるわけじゃないけど、小さくてシンプルなものが必要なら、十分に役立つ。比較すると、LitestarはFastAPIやDjangoに近い感じがする。

LitestarはAPIバックエンドを作るのに素晴らしいと思う。大好きだし、使ってるし、いいことしか言えない。Advanced Alchemyも順調に進んでるみたい。もちろん、Litestarは昔ながらのサーバーでテンプレートをレンダリングするサイトもサポートしてるし、HTMXのリクエストとレスポンス用のプラグインもある。実際、APIエンドポイントにうまく対応するパターンが、昔ながらの「フォームを検証してリダイレクト、またはエラーで再レンダリング」するエンドポイントの邪魔になることがある。特に、Litestarには「本当の」フォームサポートがないから、検証はAPIコールのスキーマミスマッチをフラグするためのもので、複数の個別エラーフィールドをフラグするためのものじゃない。@post("/route", exception_handlers={...})を使うのは、これらのエンドポイントにはちょっと不便だね。もっと良いツールやDXがあれば嬉しいな。

いいまとめだね！Litestarのことはたまに聞くけど、まだ試したことはない。試してみるべきかな。ここ数年、FastAPIをかなり使ってきたけど、OPの言ってる「大きなコードベースでFastAPIが使いにくい」ってのは誇張されてると思う。ルートを複数のファイルに分けて、それぞれにルートオブジェクトを持たせて、インポートして大きな階層を作るのはそんなに難しくないし、ちゃんと機能してる。確かに、大きなFastAPIのコードベースをどう構造化するかについては、十分なドキュメントがないかもしれないけど、ベストプラクティスと自分の好みを混ぜて、モジュールに分けて、定数やエラー、ルート、スキーマ、CRUDなどの特定のファイルに分ければ、ちゃんとスケールできるよ。FastAPIでSQLAlchemyを使ったことはないけど、仕事ではそれが意味をなさないデータストアに接続してるから、もしかしたら偏見があるかも。

Connexionも一度見てみる価値あると思う。スペックファースト開発を採用してるから、大きな組織や公開APIにとっては大きなメリットだし、いろんなサーバーフレームワークに接続できるよ。（昔はメンテナーだったけど、もう何年も触ってないな。）

だから、Pythonでデータベースを使ったウェブアプリを作るなら、Djangoを使わない限り、ほぼ確実にSQLAlchemyを使うことになるよ。自分はSQLAlchemyよりDjangoのORMの方が好きだけど、他の人はどう思ってるのか気になるな。ウェブ以外のプロジェクトでもDjangoのORMを使ったことがあるけど、ちょっと手間がかかるんだよね。もしDjangoのORMがもっとスタンドアロンで使いやすかったら、もっと多くの人が使うと思う。