Flaskは終わり？FastAPIが未来？

私が関連検索をしている間に、2024年にもかかわらず、多くの人が依然としてFlaskをPythonのウェブフレームワークとして推薦していることに気づきました。しかし、私の見解では、「Flaskは衰退しつつあり、FastAPIが未来を代表している」のです。それが、この記事を書く理由です。皆さんの討論や反論を歓迎します。

FlaskとFastAPI

FlaskはPython開発者の間で重要な地位を占めています。もしあなたがウェブ開発者なら、きっとFlaskを使ったことがあると思いますが、FastAPIに手を出したことがないかもしれません。

以下に2つの証拠を挙げます：

1. 過去1、2年間の新しい注目のPythonウェブ開発関連プロジェクトで、ウェブ開発を含むものはほぼすべてFastAPIを採用しています。
2. 2024年12月25日現在、GitHub上でFastAPIのスター数（78.9k）はすでにFlaskのスター数（68.4k）を超えています。

では、Pythonの公式開発者調査におけるウェブフレームワークの割合の変化を見てみましょう：

明らかに2019年にはFastAPIは選択肢にも載っていませんでしたが、2022年にはそのシェアは25%に達しています。（現在、2022年までのデータしかありません。）

この割合データには既存システムも含まれており、DjangoやFlaskの割合は急速には下がりません。しかし、傾向は明確です。

私たちは皆、ウェブフレームワークの分野が非常に多産で、ほぼ毎年新しいフレームワークが登場することを知っています。これらのフレームワークの多くは短命ですが、一部は存続します。FastAPIは2018年末に生まれ、2019年末頃から名を馳せ始めました。では、どうして2010年末に生まれたFlaskを、たった5年間で人気で追い抜くことができたのでしょうか？次に、Pythonウェブフレームワークと関連ソリューションの開発史を時系列に沿って辿って、よりよく理解してみましょう。

ウェブフレームワーク（プラグイン、ツール）の進化

FastAPIの作者はPythonエコシステムの開発に非常に注意深い開発者です。拡張読み込みリンク2は作者による「Alternatives and Comparison」(https://fastapi.tiangolo.com/alternatives/)で、FastAPIが様々なライブラリから得た参照やインスピレーションについて詳細に説明しています。この記事の開発史の部分もこれを参照しています。オリジナルのテキストを読むことをお勧めします。そこにはFastAPIが登場した理由や作者のいくつかの設計コンセプトが含まれています。

Flask

Flaskは「マイクロ」フレームワークで、Djangoとは大きく異なります。それはほんの少数のコア機能しか保持せず、他の機能をいくつかのライブラリ（Jinja2、Werkzeugなど）に分離しています。これは開発者に十分な自由度を与え、関連機能のためのサードパーティプラグインを簡単に書くことができます。ルートを表すための青写真、コンテキスト、デコレータ、シグナルなどの内部設計は、当時としてはかなり先進的でした。加えて包括的なドキュメントがあり、初心者にも非常に使いやすいです。

Flask RESTフレームワーク

Flaskのシンプルさのおかげで、APIの構築に非常に適しています。しかし、Flask自体には組み込み機能がありませんので、専用のRESTフレームワークが必要です。その結果、flask-restful、Flask-RESTPlus、flask-apiなどのフレームワークが次々と登場しました。また、RESTサービスでは、データ検証、解析、仕様が必要とされ、それがMarshmallow、Webargs、APISpecの登場を引き起こし、最終的にFlask-apispecが登場しました。しかし、この開発の過程で、DRFに匹敵するFlask RESTフレームワークは現れませんでした。

この段階で、Flaskの欠点が徐々に明らかになってきました。

Flaskの元々の強みは柔軟性とミニマリズムですが、これは同時に多くのコンポーネントを社内で開発する必要があることを意味します。これには、専任の開発者を持つ大企業か、非常に有能な個人開発者が必要です。そうでなければ、プラグインを本番品質にするのは難しく、Flask用のサードパーティプラグインは良莠不斉で、長期的な保守が保証されません。先に述べたように、それらのライブラリの多くはすでに保守が中止されています。

だから、今日でもFlaskでAPIサービスを構築しようとする場合、まだ様々なコンポーネントを組み合わせる必要があります。更新が遅れているコンポーネントについては、自分でトラブルシューティングをしなければなりません。経験者なら対応できるかもしれませんが、初心者にとってはかなり難しく、特に最新の実践やコンセプトを適用しようとするときにはそうです。

アシンクイオエコシステム

Python 3.5以降、asyncioが未来のトレンドとなりました。その結果、asyncioをネイティブサポートするいくつかのウェブフレームワークが登場しました。例えば、aiohttp、Starlette、sanicです。

このとき、Flaskは適応に消極的でした。コミュニティはasyncioのサポートを追加するのが遅く、Flaskの元作者はRustの開発に移行し、プロジェクトは2人のメンテナー（今では1人しか残っていません）の手に委ねられました。

apistarやmoltenのようなAPIサービス構築プロジェクトは、すべてFastAPIの誕生に設計インスピレーションを提供しました。

FastAPI

そして、FastAPIが生まれました。作者は元々良いソリューションを探し求めていましたが、上記の状況はそれぞれ独自の問題や制限がありました。そこで、作者はこの新しいフレームワークを作り出しました。

なぜFastAPIが際立つのか

これが記事の核心部分です。以下の理由が、FastAPIがFlaskを置き換えることができる理由です。

Pydanticによるユーザーデータ検証

API開発の過程で、データフォーマットの検証、解析、シリアライズは日常的な操作です。長年にわたり、複数のソリューションが登場しており、現在ではPydanticが最も人気のある選択肢です：

from fastapi import FastAPI
from pydantic import BaseModel


class Item(BaseModel):
    name: str
    description: str | None = None
    price: float
    tax: float | None = None


app = FastAPI()


@app.post("/items/")
async def create_item(item: Item):
    return item

一見すると、このコードはORMやデータクラスの書き方に似ているかもしれませんが、実際にはPythonのネイティブな型ヒント構文を使ってフィールドタイプを注釈付けています。例えば、上記の例では、/items/リクエストのItemのスキーマが明確に定義されており、各フィールドの値のタイプが明示されています。スキーマ記述やハードコードを使った古い方法と比べて、このアプローチはより簡潔で、Pythonスタイルに沿っており、IDEサポートもより良いです。

現在、Pydanticはユーザーデータ検証の分野を支配しています。FastAPIにはこれが組み込まれており、検証プロセスが大幅に簡素化され、エラーが減少します。それが、FastAPI公式サイトがこのソリューションによって開発者のエラーを最大40%削減できると述べている理由です。Pythonのような動的言語では、mypyを使わない場合、Pydanticを適用することは不可欠です。

さらに、Pydanticの統合のおかげで、プロジェクトにORM（例えばSQLAlchemy）を追加することが非常に簡単になりました。リクエストから得られたオブジェクトは、すでにデータ検証が完了しているため、直接データベースに渡すことができます。逆もまた同じで、データベースから取得したオブジェクトも直接返すことができます。

対照的に、Flaskはこの点で不足しています。

非同期設計

Flaskの時代には、コードの実行は単一スレッドで同期的でした。これは、リクエストが1つずつ処理されなければならず、前のリクエストが完了するまで、他のリクエストはI/O操作の待機で時間を無駄にすることを意味していました。一方、Asyncioは最適な解決策です。それはI/O操作を非同期にすることができ、タスクが終了するのを待たずにタスクの結果を取得し、その後他のタスクのリクエストを処理することができます。

FastAPIはネイティブで並行および非同期コードをサポートしています。コードが正しく書かれていれば、最高の効率を達成することができます。そのため、現在では最速のPythonフレームワークの1つと見なされており、NodeJSやGoと同程度の効率を備えています。速度とパフォーマンスが重要な場合、FastAPIは間違いなく最良の選択肢です。

ASGIのネイティブサポート

まず、WSGIについて触れましょう。その正式名称は「Python Web Server Gateway Interface」で、「PEP 3333」(https://peps.python.org/pep-3333/)に記載されています。これは、ウェブアプリケーションとサーバーの間の相互作用のために特別に書かれたPythonの標準です。もしPHPやRubyを使ったことがあれば、理解しやすいかもしれません。FlaskはWerkzeugに依存しており、WerkzeugはWSGIスイートなので、Flaskはこの古いWSGI標準をサポートしており、ASGIはサポートしていません。

WSGIの問題点は、非同期性を利用してパフォーマンスと効率を高めることができないことです。そこで、Django channelがASGIを開拓しました。その正式名称は「Asynchronous Server Gateway Interface」で、反復的でほぼ完全に再設計された標準です。それは非同期のサーバー/アプリケーションインターフェースを提供し、HTTP、HTTP/2、WebSocketをサポートしています。WSGIとは異なり、ASGIは各アプリケーションが複数の非同期イベントを持つことを許容します。さらに、ASGIは同期アプリケーションと非同期アプリケーションの両方をサポートしています。古い同期的なWSGIウェブアプリケーションをASGIに移行することもできますし、ASGIを使って新しい非同期ウェブアプリケーションを構築することもできます。

結論を出す前に、5つの用語の説明を加えましょう：

1. ASGIツールキット：ASGI関連の機能（URLルーティング、リクエスト/レスポンスオブジェクト、テンプレートエンジンなど）を実装するライブラリ。この記事では主にStarletteを指しており、これはFlaskの依存ライブラリであるWerkzeugに対応しています。
2. ASGIウェブフレームワーク：ASGI仕様を実装するウェブフレームワーク（例えばFastAPI）で、FlaskやDjangoはWSGIを実装するウェブフレームワークです。これらのフレームワークは、開発者がアプリケーションを書くために設計されており、使いやすいインターフェースを備えています。開発者は必要に応じてビジネスロジックを埋め込むだけです。初期のフレームワークは多くの場合、内部でASGIツールキットを実装していましたが、後のフレームワークは通常、適切なツールキットを組み合わせます。例えば、FlaskはWerkzeug（独自のもの）を使用し、FastAPIはStarlette（他のもの）を使用します。
3. ウェブアプリケーション：ウェブフレームワークを使って作成されたアプリケーションがウェブアプリケーションです。通常、ウェブフレームワークにはテストサーバーが付属しており、開発とデバッグのために起動することができます。パフォーマンスと安定性が問題でなければ、すでにブラウザで開発用アドレスにアクセスしてこのアプリケーションを訪問することができます。
4. ウェブサーバー：現実世界は予想よりも複雑です。ウェブアプリケーションが本番環境にデプロイされた後、リクエストのロードバランシング、静的ファイルの配信、アクセス制御、逆プロキシなどの要件が考慮される必要があり、また高性能の要件もあります。ウェ�布フレームワークの組み込みサーバーはこれらの要件を全く満たすことができませんので、専用のウェブサーバーが必要です。現在、Nginxが主流の選択肢です。
5. ASGIサーバー：ASGIサーバーはウェブサーバーとウェブアプリケーションの間の橋渡しをする役割を果たします。ASGIサーバーもASGI仕様に準拠していますが、その主なタスクはリクエストを転送するパフォーマンス要件を満たすことであり、主にASGIの「G」（ゲートウェイ）部分を担当しています。そのコードは、開発者がウェブアプリケーションのビジネスとルーティングロジックを書くのには親切ではありません。現在、最も有名なASGIサーバーはUvicornであり、元々WSGIサーバーであるGunicornからのuvicorn.workers.UvicornWorkerも選択肢の1つです。これらは本番環境で推薦される使用方法です。

過去、WSGIの本番環境のソリューションは通常、Nginx + Gunicorn + Flask(Django)でしたが、現在、ASGIの本番環境のソリューションはNginx + Uvicorn + FastAPIです。

もう1点。FastAPIの名前と紹介から判断すると、それはAPIサービスを構築するために設計されたことは明らかです。実際、そのコアコードもまさにその通りです。それは、従来の完全に自己実装されたフレームワークではなく、むしろ様々なフレームワークの強みを組み合わせたフレームワークと言えます。空の殻から始めて、必要で適切なコンポーネントを組み立てます。例えば、それはテンプレートエンジンを持っていません。もし本当にテンプレートレンダリングが必要なウェブアプリケーションを構築する必要があれば、必要なテンプレートエンジンを選択して組み合わせることができます。もちろん、Starletteに組み込まれているJinja2（はい、Flaskにも組み込まれています）を使うこともできます。

なぜFlaskが死んだと言われるのか

上記のFastAPIの利点だけでは、Flaskが死んだと結論付けるには不十分です。では、なぜ私がこの見解を持っているのでしょうか？それは主に開発者とユーザーの間の人気にかかっています。

ここでの「人気」はかなり主観的です。私が思いつく指標は以下の通りです：

1. コミュニティの活動 (https://github.com/pallets/flask/issues) ：プロジェクトのイシュー数とプルリクエスト数を例にとりましょう。Flaskのイシュー数は1桁の数しかなく、FastAPIとは全く違う次元です。これは実際、プロジェクトがもはや活発でないことを側面から反映しています。もしプロジェクトが活発であれば、古いユーザーはより多くのニーズを持つはずです。もし彼らが質問を提出しなくなったら、それは彼らが離れたことを意味します。そして新しいユーザーは必ず様々な問題を抱えるはずです。詳細なドキュメントがあっても、多くのユーザーが質問に来てコードを寄稿するはずです。そのような状況が不足していることは、ユーザーが少ないことを示しています。
2. 議論の盛り上がり：つまり、ブログ記事、Stack Overflowなどのサイトでの質問と議論の人気です。最近、Flaskについて書いている人が非常に少ないことは明らかです。
3. 開発の繰り返し頻度(https://github.com/pallets/flask/pulls) ：コミット記録を見ると、Flaskは1人のメンテナーしかおらず、時折バグを修正するだけで、主要な機能開発は行われていません。
4. 重要人物の影響力：Flaskの背後にいる重要人物、プロジェクトの発起人は、もう長い間プロジェクトに参加していません。プロジェクトの貢献記録によると、Armin Ronacherは6年前に最後に開発に貢献して以来、参加していません。

私の見解では、これらすべての状況は、Flaskの全盛期が過ぎ去り、FastAPIが新興の星であることを示唆しています。

最後に、Flask/FastAPIをデプロイするのに理想的なプラットフォームを紹介しましょう：Leapcell。

Leapcellは、現代の分散アプリケーション向けに特別に設計されたクラウドコンピューティングプラットフォームです。その従量制の価格モデルは、アイドルコストが発生しないことを保証しており、ユーザーは実際に使用したリソースに対してのみ支払うことになります。

LeapcellのWSGI/ASGIアプリケーションに対するユニークな利点：

1. 多言語サポート

• JavaScript、Python、Go、またはRustでの開発をサポートします。

2. 無制限プロジェクトの無料デプロイ

• 使用量に基づいてのみ課金。リクエストがない場合、課金は発生しません。

3. 比類のないコストパフォーマンス

• 従量制で、アイドル料金はありません。
• 例えば、25$で694万件のリクエストをサポートし、平均応答時間は60ミリ秒です。

4. 簡素化された開発者体験

• 直感的なユーザーインターフェースで簡単に設定可能。
• 完全自動化されたCI/CDパイプラインとGitOps統合。
• リアルタイムのメトリクスとログで、実行可能な洞察を提供します。

5. 簡単なスケーラビリティと高性能

• 自動スケーリングで、高い並列性を簡単に処理できます。
• オペレーションオーバーヘッドはゼロで、開発者は開発に集中できます。

Docsで詳細を学びましょう。

LeapcellのTwitter：https://x.com/LeapcellHQ