Flaskは死んだ？FastAPIが未来か？

関連する検索をしていると、2024年になってもまだ多くの人がPythonのウェブフレームワークとしてFlaskを推奨していることに気づきます。しかし、私の考えでは、「Flaskは衰退に向かっており、FastAPIが未来を代表している」と考えています。だからこそ、この記事を書いています。皆様が議論に参加し、反論を提示することを歓迎します。

Flask vs FastAPI

FlaskはPython開発者の心の中で重要な位置を占めています。あなたがウェブ開発者であれば、Flaskを使ったことがある可能性が高いと思いますが、FastAPIに手を出したことがないかもしれません。

ここに2つの証拠があります。

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

次に、公式Pythonの開発者アンケートにおけるウェブフレームワークの割合の変化を見てみましょう。

2019年には、FastAPIは選択肢としてリストされていませんでしたが、2022年までにそのシェアは25%に達しました。（現在、2022年までのデータしかありません。）

この割合データは既存のシステムを含んでいるため、DjangoとFlaskの割合が急速に低下することはないことに注意してください。それでも、傾向は明らかです。

ウェブフレームワークの分野は非常に多産であり、ほぼ毎年新しいフレームワークが登場することをご存知でしょう。これらのフレームワークのほとんどは短命ですが、一部は生き残ることができます。FastAPIは2018年末に誕生し、2019年末頃からその名を知られるようになりました。それでは、わずか5年で、2010年末に誕生したFlaskを人気で追い抜くことができたのでしょうか？次に、より良い理解のために、Pythonのウェブフレームワークと関連ソリューションの開発の歴史をタイムラインに沿って辿ってみましょう。

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

FastAPIの作者は、Pythonエコシステムの開発に非常に注意を払っている開発者です。拡張読書リンク2は、作者によって書かれた「代替案、インスピレーションおよび比較」(https://fastapi.tiangolo.com/alternatives/)であり、FastAPIがさまざまなライブラリから得た参照またはインスピレーションについて詳しく説明しています。この記事の開発履歴セクションもこの作品を参照しています。FastAPIの出現の背後にある理由と、作者のデザインコンセプトのいくつかを含むため、原文を読むことをお勧めします。

Flask

Flaskは「マイクロ」フレームワークであり、Djangoとは全く異なります。ごくわずかなコア機能のみを保持し、切り離すために、他の機能をいくつかのライブラリ（Jinja2、Werkzeugなど）に分割します。これにより、開発者は十分な自由を得て、関連機能のサードパーティ製プラグインを簡単に作成できます。ブループリント、コンテキスト、ルートを表すデコレータ、シグナルなどの内部設計は、当時としては非常に高度でした。包括的なドキュメントと相まって、非常に初心者向けです。

Flask REST Frameworks

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

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

Flaskの元々の強みはその柔軟性とミニマリズムにありますが、これはまた、多数のコンポーネントを社内で開発する必要があることを意味します。これには、開発と維持のための専任の開発者を持つ大企業、または非常に有能な個々の開発者のいずれかが必要です。そうでない場合、プラグインが製品品質に達することは難しく、Flaskのサードパーティ製プラグインが混在し、長期的なメンテナンスが保証されません。前述のように、これらのライブラリの多くはすでにメンテナンスを停止しています。

そのため、今日でもFlaskでAPIサービスを構築する場合、さまざまなコンポーネントを組み合わせる必要があります。迅速に更新されていない一部のコンポーネントについては、自分でトラブルシューティングを行う必要があります。ベテランは対応できるかもしれませんが、特に最新のプラクティスとコンセプトを適用したい初心者にとっては、かなり大変です。

Asyncioエコシステム

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

当時、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またはdataclassの書き方のように見えるかもしれませんが、実際には、PythonのネイティブType Hints構文を使用してフィールドの型をアノテーションしています。たとえば、上記の例では、/items/リクエストのItemのスキーマが明確に定義されており、各フィールドの値の型が明示的です。スキーマ記述やハードコーディングを使用する古い方法と比較して、このアプローチはより簡潔で、Pythonスタイルに準拠しており、IDEのサポートが向上しています。

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

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

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

非同期設計

Flaskの時代では、コードの実行はシングルスレッドで同期的でした。これは、リクエストを1つずつ処理する必要があり、他のリクエストは前のリクエストが完了するまでI/O操作を待つために時間を無駄にすることを意味します。一方、Asyncioは最適なソリューションです。I/O操作を非同期にすることで、タスクが完了するのを待たずにタスクの結果を取得し、他のタスクリクエストの処理に進むことができます。

FastAPIは、同時実行および非同期コードをネイティブにサポートしています。コードが正しく記述されている限り、最高の効率を達成できます。したがって、現在最速のPythonフレームワークと見なされており、NodeJSまたはGoと同等の効率です。速度とパフォーマンスが不可欠な場合、FastAPIは間違いなく最良の選択肢です。

ASGIのネイティブサポート

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

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

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

ASGI Toolkit: ASGI関連の機能を実装するライブラリ（URLルーティング、リクエスト/レスポンスオブジェクト、テンプレートエンジンなど）。この記事では、主にStarletteを指し、Flaskの依存関係であるWerkzeugに対応します。
ASGI Web Framework: ASGI仕様を実装するウェブフレームワーク（FastAPIなど）。一方、FlaskとDjangoはWSGIを実装するウェブフレームワークです。これらのフレームワークは、開発者がアプリケーションを作成するために設計されており、使いやすいインターフェイスを備えています。開発者は、必要に応じてビジネスロジックを入力するだけです。初期のフレームワークは、ほとんどがASGIツールキットを内部的に実装していましたが、後のフレームワークは通常、適切なツールキットを組み合わせています。たとえば、FlaskはWerkzeug（独自のもの）を使用し、FastAPIはStarlette（他のものから）を使用します。
Web Application: ウェブフレームワークを使用して作成されたアプリケーションは、ウェブアプリケーションです。通常、ウェブフレームワークには、開発とデバッグのために起動できるテストサーバーが付属しています。パフォーマンスと安定性が懸念されない場合は、ブラウザで開発アドレスにアクセスしてこのアプリケーションにアクセスできます。
Web Server: 現実の世界は予想以上に複雑です。ウェブアプリケーションが本番環境にデプロイされた後、リクエストの負荷分散、静的ファイルの提供、アクセス制御、リバースプロキシなどの要件を考慮する必要があり、高いパフォーマンス要件もあります。ウェブフレームワークの組み込みウェブサーバーはこれらの要件をまったく満たすことができないため、専門のウェブサーバーが必要です。現在、Nginxが主流の選択肢です。
ASGI Server: ASGIサーバーは、ウェブサーバーとウェブアプリケーション間のブリッジとして機能します。ASGIサーバーもASGI仕様に準拠していますが、その主なタスクはリクエストの転送のパフォーマンス要件を満たすことであるため、主にASGIの「G」（ゲートウェイ）の部分を処理します。そのコードは、開発者がウェブアプリケーションのビジネスおよびルーティングロジックを記述するのに適していません。現在、最も有名なASGIサーバーはUvicornであり、WSGIサーバーGunicornに元々付属していたuvicorn.workers.UvicornWorkerもオプションです。これらは本番環境での推奨される使用法です。

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

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

Flaskが死んだと言われる理由

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

ここでの「人気」は、むしろ主観的です。私が考えることができる指標は次のとおりです。

コミュニティ活動(https://github.com/pallets/flask/issues): たとえば、プロジェクトのissueとプルリクエストの数を見てください。Flaskには1桁の数字しかなく、FastAPIとはまったく異なるリーグにあります。これは実際には、プロジェクトがもはや活発ではないことを反映しています。プロジェクトが活発であれば、古いユーザーはより多くのニーズを持つでしょう。質問をしなくなったら、彼らは去ったことを意味します。そして、新しいユーザーは必ずあらゆる種類の問題を抱えるでしょう。詳細なドキュメントがあっても、質問をし、コードに貢献するために来るユーザーはまだたくさんいるはずです。そのような状況の欠如は、ユーザーが少ないことを示しています。
議論の熱: ブログ投稿、Stack Overflow、およびその他のウェブサイトでの問い合わせや議論の人気です。最近Flaskについて書いている人は非常に少ないことは明らかです。
開発の反復頻度(https://github.com/pallets/flask/pulls): コミット記録を見ると、Flaskにはバグを修正することがある1人のメンテナーしかおらず、主要な機能開発はありません。
キー人物の影響: Flaskの背後にいるキー人物、プロジェクトのイニシエーターは、長い間プロジェクトに参加していません。プロジェクトの貢献記録によると、Armin Ronacherが最後に開発に貢献したのは6年前です。

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

最後に、Flask/FastAPIのデプロイに最適なプラットフォームであるLeapcellを紹介します。

Leapcellは、最新の分散アプリケーション専用に設計されたクラウドコンピューティングプラットフォームです。従量課金制の価格モデルにより、アイドルコストが発生しないため、ユーザーは実際に使用するリソースに対してのみ支払います。