Litestarは一度チェックする価値がある

• Litestar は Python の非同期 Web フレームワークの中でも あまり知られていない逸材
• 高い拡張性 と 柔軟なアーキテクチャ により、さまざまなプロジェクトに容易に適用できる
• Pydantic など特定ライブラリに 依存しないデータモデリング を提供する
• SQLAlchemy 統合 が優れており、データベース連携と管理に強みを持つ
• 便利な認証、キャッシュ、ロギング、モニタリングなどの組み込み機能 により、実務ですぐ活用できる

---

Litestar 概要

• ここ数年、async-first・型ヒントベースの Python Web フレームワーク が注目を集める中、その一つである Litestar を選んで利用経験を積んできた
• 実際に複数のプロジェクトで Litestar をメインフレームワークとして採用する中で、その選択への確信はますます強まっている
• Python Web 開発者でも Litestar を知らない場合が多いため、この記事では主な利点と特徴を紹介する

例とフレームワーク比較

• Litestar では非常にシンプルな 単一ファイルの Web アプリケーション も簡単に書ける

  • route decorator は アプリオブジェクトに属さない独立した関数 である
  • 例のコードでは /greet?name=Bob にアクセスすると “Hi, Bob!” が返される
  • 必須パラメータが欠けている場合は自動で 400 レスポンスを返す

• Flask や FastAPI など既存の Python マイクロフレームワークと違い、Litestar はさまざまな規模のプロジェクトに自然に拡張できる構造的特徴を持つ

  • Flask や FastAPI の方式では、ルーティングデコレータがアプリオブジェクトに属しているため、複数ファイルへの分割時に循環 import 問題 が起こる可能性がある
  • 通常は下位の route registry（Flask/Quart では blueprint、FastAPI では APIRouter など）を活用する必要があるため、参入障壁が上がったり構造変更が必要になったりする
  • しかし Litestar では decorator が 独立関数 なので、単一ファイルのアプリと大規模な分散構造の間の移行が非常に簡潔である

• Litestar の 基本アーキテクチャとドキュメントの書き方 により、ルーターや機能のまとまりという概念をかなり早い段階から紹介でき、複雑な API 構成でも一貫性を保ちやすい

  • 依存性注入、権限、パスごとの config 共有など、composability が強みである
  • 同じ route を複数回登録して、環境ごとの認証・依存性適用なども可能である

Pydantic 依存から離れたモデリング

• FastAPI などはデータを Pydantic に強く依存させる

  • Pydantic は型ベースのデータ検証・シリアライズに強みがあるが、ORM（SQLAlchemy）との直接連携が難しい
  • 実務では SQLAlchemy モデルと Pydantic モデルをそれぞれ別に書かなければならない煩雑さがある

• Litestar は Pydantic だけでなく、dataclasses、msgspec、attrs、SQLAlchemy model などさまざまな型を汎用的にサポートする

  • serialization プラグインプロトコル を備えており、拡張性が高い
  • データ転送オブジェクト（DTO）の自動抽出 機能を搭載しており、元のデータクラスだけ変更すれば DTO に自動で反映される
  • 一部フィールドの除外・包含・名前マッピング・部分更新 DTO なども簡単に宣言できる
  • そのため、モデルフィールドの重複宣言や手動同期の過程で起こりがちなミスを防げる

SQLAlchemy との連携と Advanced Alchemy の紹介

• SQLAlchemy ORM は事実上の Python DB 連携標準である

  • Litestar は SQLAlchemy のスキーマ自動シリアライズ、DTO 自動化、セッション管理プラグイン、複合プラグインなど 統合性 が非常に優れている

• Advanced Alchemy ライブラリ（Litestar チームが保守）を通じて SQLAlchemy の機能が拡張される

  • database-agnostic な大規模 PK、自動タイムスタンプ、UUID キー、JSON 型、Alembic マイグレーション連携、Seed/Export など、さまざまな 品質改善 機能を提供する
  • 注目すべき機能は repository および service layer の抽象化支援 で、CRUD やページネーションなど多くのリポジトリ機能を自動提供する点である
  • Django と違って構造的ガイドが弱いフレームワークでは、repository/service layer の導入を勧められるような組織的な方式を用意している

その他の特徴と組み込みサポート機能

• Litestar は認証システム（guard 関数、ミドルウェア）、キャッシュ（stores）、ロギング、標準化された問題応答、Prometheus/OpenTelemetry ベースのメトリクス、htmx サポート などもフレームワーク内部で提供する
• 他のマイクロフレームワークと違い、一部機能の実装時に別の外部ライブラリを探したりカスタムの glue code を書いたりする必要がない
• マイクロフレームワーク の簡潔さを保ちつつ、拡張や追加機能の利用時には必要に応じてすぐ活用できる
• Django/Flask の代替というより、Java Spring Boot など他言語フレームワークの強み（初期構造や利便性など）を Pythonic に取り込むコンセプトである
• 全体として、実務の Python Web 開発において 高い生産性と構造的な利点 を持つ選択肢である

結論

• Litestar は 非同期、型ベース、柔軟な拡張性、縛りの強くないデータモデリング、優れた ORM と組み込み機能 により、Python Web 開発者なら一度は検討する価値のあるフレームワークとして浮上している
• 実際のプロジェクトで繰り返し使ってみた結果、スタートアップをはじめとするさまざまなプロジェクト環境で高い 生産性 と 保守性 を確認できた
• 開発者が次の Python Web プロジェクトを計画する際、Litestar を選択肢の一つとして考えてほしい

[minhoryang]

Python の「循環 import 問題」には、明確な解決策があるのではありませんか？ 重大な問題と見るには、少し弱い気がします。

[GN⁺]

Hacker Newsのコメント

• この1年、大規模なバックエンドプロジェクトをFastAPIで開発してきた。公式チュートリアルのスタイルどおりに始めたが、すべてのCRUDを1つのファイルに入れるFastAPI公式テンプレートや依存関係の管理方式には不便さを感じた。SQLModelを使う中でも、多態性モデルの未対応などいくつもの限界があり、コミュニティで改善PRを出しても数か月間レビューすらされないなど、保守されているのか疑わしく感じた。ドキュメントも実用的なリファレンスが不足していて、結局はソースコードまで掘るしかなかった。CRUDを素早く作るには悪くないが、複雑なシステムを作るにはフレームワークの上にもう1つフレームワークを載せるようなものなので、おすすめはしないつもりだ。明日からはLitestarへ移行する予定だ
  • FastAPIの実践的な大規模アプリ事例を学ぶなら、polarsource/polarレポジトリのサーバーコードを参考にすると役立ちそうだ。認証やテストなど、実際のスケールアウト事例がよくまとまっているので、このレポジトリの実装を追いながら学んでみようと思う
  • API中心のアプリ設計に入門しているところだが、この記事から想定していなかったアーキテクチャやツールのポイントをたくさん学べた。自分もLitestarを使ってみるつもりだ。有益な意見と記事に感謝する
  • FastAPI公式チュートリアルでSQLModelが過度に強調されているという点には同意しない。最初の画面ではSQLModelへの言及すらなく、扱われるのはリレーショナルデータベース接続の説明ページだけだ。チュートリアルで特定のORMを使うのは自然な選択で、SQLModelが合わないならユーザーが別の選択肢を選べばいいと思う。自分もチュートリアルを見てplain SQLAlchemyにした
  • Litestarのドキュメントを読んでみると、イベントシステムも内蔵されている。FastAPIでは数週間かけて別途作って使っていた機能だが、Litestarには最初から用意されている
  • Litestarにも何らかの限界はあるのではないかと思う。コミュニティ・ドキュメント・議論はFastAPIより少ないのに、それでも複雑なアプリケーションにより適していると思うのか、意見を聞きたい
• LitestarはAPIバックエンド構築に非常に優れている。実際に使っていて、強くおすすめできるほどだ。Advanced Alchemyもますます良くなっている。昔ながらのサーバーテンプレートレンダリングサイトもLitestarで十分に作れるし、HTMX用プラグインも内蔵されている。ただし、APIエンドポイント設計のためのパターンは、フォーム検証やリダイレクトなど従来型のサーバーレンダー向けエンドポイントではややぎこちない部分がある。Litestar自体には本当の意味でのフォーム処理機能がなく、個々のフォームフィールドごとのエラーを適切に扱いにくい。@post("/route", exception_handlers={...})を活用するパターンも不自然に感じる。今後、より良い組み込みツールや開発体験の改善に期待したい
  • Litestarを実際に使ったことはないが、フォーム関連の処理をすべて解決する独自デコレータ @postform のようなものを作ればいいのではないかと思う
• LitestarはPythonのWebフレームワークだ。気になる人向けに先に共有しておく
  • おかげで時間を節約できたという人もいた
• 1年以上、LitestarでJSONとテンプレートベースのHTMLを一緒に提供している。速度はFastAPIより速く、軽量でありながら認証・セッションなど必須機能がしっかり揃ったPython asyncフレームワークだ。msgspecやControllerベースのネストされたルーティング対応などが特に気に入っている。強くおすすめする
  • 自分も新規プロジェクトでFastAPIからLitestarへ切り替えたが、後悔なくうまく使えている。Litestarの基本ベースだけでも、明らかな完成度と信頼感がある
  • FastAPIを何年も使ってきたが、Litestarもぜひ一度試してみる価値がありそうだ
• FastAPIで数年間アプリケーションを開発しながら、似たような不満を感じてきた。実戦的な開発や本当のAPI品質評価という観点では、チュートリアルやサンプル中心のFastAPIドキュメントは現実とかけ離れているという評価が多い。この点が意外なほど頻繁に指摘されているのは驚きだ
  • 最近のPythonフレームワークのドキュメントはどれもJavaScriptライブラリのように「チュートリアル＋おしゃべりなブログ」といった感じで、APIの詳細やパラメータ説明などのリファレンスが不足しているのが非常に残念だ。本物のAPIリファレンス文書が必要だ。メソッドごとの詳細オプション、パラメータ整理、そしてコメント文の代わりにオプションをきちんと記載してほしい。ソースコードまで掘らないとすっきりした情報が得られない今のやり方はとても不便だ
• FastAPIも使えはするが、複雑なアプリを作るには限界が少なくない。フレームワーク設計を見ていると、15年前にJavaEEがすでに経験した問題をPythonマイクロフレームワークのエコシステムが遅れて再発見しているようで驚くことがある。Litestarはかなり良さそうだ。ストリーミングのエラーケース処理のノウハウも気になる
• FastAPIは人気だが、小さなプロジェクトならstarletteだけでも十分満足だった。全部入りではないが、シンプルなサービスには不足がない。LitestarはFastAPIやDjangoに近い守備範囲に見える
  • 最近のAPIはstarlette単独で作っているが、クリーンで簡潔で、公式ドキュメントもよくできているので、プロジェクト規模に関係なく拡張性が高い
• Litestarにはずっと関心があったが、まだ実際には使っていない。FastAPIはかなり長く使ってきたし、FastAPIで大規模コードベースの管理が難しいという評価はやや誇張されている気がする。ルーティングを複数ファイルに分けてimportし、大きなツリー構造にすれば十分拡張できた。ただし、大規模な構造化に関する公式ドキュメントのガイドが不足している点には同意する。best practiceと個人の好みに沿ってファイルをモジュールごとに分割すれば、十分な拡張性は確保できた。FastAPIでSQLAlchemyを直接使ってはいなかったので、その部分の苦労にはあまり共感できないかもしれない
• 実践的なアプリ開発で重要なポイントをよく押さえた記事だ。Litestarの設計は本当に魅力的だ。リポジトリパターンについての見解にも期待している。独立した投稿として展開してくれると嬉しい
• かなり良い記事だった。SQLAlchemyは扱いが難しく、状態も複雑で驚かされる部分が多いが、まったく使わずに開発している人がいるのか気になる
  • 最近、個人プロジェクトでpeeweeを使って開発してみたが、多くの追加機能はないものの、やるべきことはしっかりこなしてくれる
  • 従来のSQLAlchemyとLitestarのAdvanced Alchemy（これもベースはSQLAlchemyだが）には大きな違いがある。以前はpure SQLかSQLAlchemyを使っていたが、django ninjaからLitestarへ移る中で、SQLAlchemyの利用をむしろ減らしつつある
  • このプロジェクトで最も興味深い点は、SqlAlchemyの欠点をある程度補ってくれそうなところだ。DBが必要なプロジェクトを始めるたび、結局Djangoに戻ってしまう。SqlAlchemyとAlembicは、あえて耐えたい苦痛ではない
  • SQLAlchemyを使う最も現実的な方法は、モデルとAlembicでスキーマ定義とマイグレーションだけ行い、実際のクエリやトランザクション管理は自分でSQLを書くことだと思う。ORMでクエリを組み直す時間の消耗が大きすぎる
  • 主にasyncpgをよく使っている