関連する検索をしていると、2024 年になっても、かなり多くの人が依然として Python Web フレームワークとして Flask を推奨していることに気づきました。しかし、私の考えでは、「Flask は終焉を迎えつつあり、FastAPI は未来を象徴するものである」と考えています。だからこそ私はこの記事を書いています。皆さんもディスカッションに参加し、反論をしていただければ幸いです。
Flask は Python 開発者の心の中で重要な位置を占めています。あなたが Web 開発者であれば、Flask を使用したことはあると思いますが、FastAPI にはまだ手を出したことがないかもしれません。
ここに 2 つの証拠があります:
ここで、公式の Python 開発者アンケートにおける Web フレームワークの割合の変化を見てみましょう。
2019 年には FastAPI がオプションとしてリストされてさえいなかったのが、2023 年までにそのシェアが 25% に達していたことは明らかです。 (現時点では 2023 年までのデータしかありません。)
この割合データには既存のシステムが含まれているため、Django と Flask の割合が急激に低下することはないことに注意してください。それにもかかわらず、傾向は明らかです。
Web フレームワーク分野は非常に多作であり、ほぼ毎年新しいフレームワークが登場していることは誰もが知っています。これらのフレームワークのほとんどは短命ですが、一部のフレームワークはなんとか存続します。 FastAPI は 2018 年末に誕生し、2019 年末頃からその名を轟かせ始めました。では、どうすれば 2010 年末に誕生した Flask をわずか 5 年以内に人気の点で追い越すことができたのでしょうか?次に、理解を深めるために、Python Web フレームワークと関連ソリューションの開発履歴をタイムラインに沿ってたどってみましょう。
FastAPI の作者は、Python エコシステムの開発に細心の注意を払っている開発者です。多読リンク 2 は、著者が書いた「代替、インスピレーション、比較」 (https://fastapi.tiangolo.com/alternatives/) で、FastAPI がさまざまなライブラリから引き出した参照やインスピレーションについて詳しく説明しています。この記事の開発履歴セクションでもこの作品について言及しています。原文には FastAPI の出現の背後にある理論的根拠と著者の設計概念の一部が含まれているため、原文を読むことをお勧めします。
Flask は「マイクロ」フレームワークであり、Django とはまったく異なります。少数のコア関数のみを保持し、分離するために他の関数をいくつかのライブラリ (Jinja2、Werkzeug など) に分割します。これにより開発者に十分な自由が与えられ、関連機能用のサードパーティのプラグインを簡単に作成できるようになります。ブループリント、コンテキスト、ルートや信号などを表すデコレーターなどの内部設計は、当時としてはかなり先進的でした。包括的なドキュメントと相まって、非常に初心者に優しいものとなっています。
Flask はそのシンプルさのおかげで、API の構築に非常に適しています。ただし、Flask 自体には組み込み関数が付属していないため、専用の REST フレームワークが必要です。その結果、flask-restful、Flask-RESTPlus、flask-apiといったフレームワークが次々と登場しました。さらに、REST サービスにはデータの検証、解析、仕様の要件があり、Flask-apispec が登場するまで Marshmallow、Webargs、APISpec が登場しました。ただし、この開発プロセスを通じて、DRF に匹敵する Flask REST フレームワークは実現しませんでした。
現段階で、Flask の欠点が徐々に表面化しています。
Flask の本来の強みはその柔軟性とミニマリズムにありますが、これはまた、多数のコンポーネントを社内で開発する必要があることも意味します。これには、開発と維持を担当する専任の開発者を抱える大企業か、非常に有能な個人の開発者が必要です。そうしないと、プラグインが製品品質に達することが難しくなり、Flask 用のサードパーティ プラグインが混在し、長期的なメンテナンスの保証がなくなります。前述したように、これらのライブラリの多くはすでにメンテナンスを中止しています。
そのため、現在でも、Flask を使用して API サービスを構築したい場合は、さまざまなコンポーネントを組み合わせる必要があります。すぐに更新されていない一部のコンポーネントについては、自分でトラブルシューティングを行う必要があります。ベテランなら対処できるかもしれませんが、初心者にとっては、特に最新の実践や概念を適用したい場合にはかなり困難です。
Python 3.5 以降、asyncio が将来のトレンドになりました。その結果、aiohttp、Starlette、sanic など、asyncio をネイティブにサポートするいくつかの Web フレームワークが登場しました。
この時点で、Flask は適応することに消極的でした。コミュニティは asyncio のサポートを追加するのが遅れており、Flask の元の作者は Rust の作成に切り替え、プロジェクトを 2 人のメンテナの手に委ねました (現在は 1 人だけが残っています)。
apistar や molten などの API サービスを構築するプロジェクトはすべて、FastAPI の誕生に設計のインスピレーションを与えてきました。
その後、FastAPI が誕生しました。著者は当初、良い解決策を模索していましたが、上記の状況にはそれぞれ独自の問題や限界がありました。そこで、著者はこの新しいフレームワークを作成しました。
これが記事の核心部分です。 FastAPI が Flask に代わる理由は次のとおりです。
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/ リクエスト内の項目のスキーマが明確に定義されており、各フィールドの値の型が明示的です。スキーマ記述やハードコーディングを使用する古い方法と比較して、このアプローチはより簡潔で、Python スタイルに準拠しており、IDE サポートも優れています。
現在、Pydantic はユーザーデータ検証の分野を支配しています。 FastAPI にはそれが組み込まれているため、検証プロセスが大幅に簡素化され、エラーが減少します。そのため、FastAPI 公式 Web サイトでは、このソリューションにより開発者のエラーが最大 40% 削減できると記載されています。 Python のような動的言語の場合、型チェックに mypy を使用しない場合は、Pydantic を適用することが不可欠です。
さらに、Pydantic の統合のおかげで、プロジェクトへの ORM (SQLAlchemy など) の追加が非常に簡単になります。データ検証がすでに完了しているため、リクエストから取得したオブジェクトをデータベースに直接渡すことができます。逆に、データベースから取得したオブジェクトを直接返すこともできます。
対照的に、Flask にはこの点が欠けています。
Flask の時代、コードの実行はシングルスレッドで同期していました。これは、リクエストを 1 つずつ処理する必要があり、前のリクエストが完了する前に他のリクエストが I/O 操作を待機することで時間を無駄にすることを意味しました。一方、Asyncio は最適なソリューションです。 I/O 操作を非同期にすることができるため、タスクの終了を待たずにタスクの結果を取得し、他のタスク リクエストの処理に進むことができます。
FastAPI は、同時コードと非同期コードをネイティブにサポートします。コードが正しく記述されている限り、最高の効率を達成できます。したがって、NodeJS や Go と同様の効率を備えた、現在最速の Python フレームワークとみなされています。速度とパフォーマンスが重要な場合、FastAPI が間違いなく最良の選択です。
まず WSGI について触れましょう。正式名称は「Python Web Server Gateway Interface」で、「PEP 3333」(https://peps.python.org/pep-3333/) で参照できます。これは、Web アプリケーションとサーバー間の対話のために特別に作成された Python 標準です。 PHP や Ruby を使用したことがある場合は、より理解しやすいかもしれません。 Flask は WSGI スイートである Werkzeug に依存しているため、Flask は ASGI ではなく、この古い WSGI 標準をサポートしています。
WSGI の問題は、非同期を活用してパフォーマンスと効率を向上できないことです。つまり、Django チャネルが ASGI の先駆者となりました。その正式名は「Asynchronous Server Gateway Interface」で、反復的かつほぼ完全に再設計された標準です。非同期サーバー/アプリケーション インターフェイスを提供し、HTTP、HTTP/2、および WebSocket をサポートします。 WSGI とは異なり、ASGI では各アプリケーションが複数の非同期イベントを持つことができます。さらに、ASGI は同期アプリケーションと非同期アプリケーションの両方をサポートします。古い同期 WSGI Web アプリケーションを ASGI に移行することも、ASGI を使用して新しい非同期 Web アプリケーションを構築することもできます。
結論を出す前に、5 つの用語の説明を追加しましょう:
以前は、WSGI の運用環境ソリューションは通常 Nginx Gunicorn Flask(Django) でしたが、現在では ASGI の運用環境ソリューションは Nginx Uvicorn FastAPI です。
もう一つ。 FastAPI の名前と概要から判断すると、API サービスを構築するために設計されていることは明らかです。実際、そのコアコードはまさにそれと同じです。従来の完全に自己実装されたフレームワークではなく、さまざまなフレームワークの長所を組み合わせたフレームワークであると言えます。空のシェルから始めて、必要かつ適切なコンポーネントを組み立てます。たとえば、テンプレート エンジンはありません。テンプレートのレンダリングを必要とする Web アプリケーションを構築するためにこれを使用する必要がある場合は、必要なテンプレート エンジンを選択して組み合わせることができます。もちろん、Starlette に組み込まれている Jinja2 を使用することもできます (はい、Flask にも組み込まれています)。
上で述べた FastAPI の利点だけでは、Flask が終わったと結論付けるには十分ではありません。では、なぜ私はこのような見解を持っているのでしょうか?それは主に、開発者とユーザーの間での人気によるものです。
ここでの「人気」はかなり主観的なものです。私が考える指標は次のとおりです。
これらすべての状況は、私の意見では、Flask の全盛期は過ぎ、FastAPI が新星であることを示唆しています。
最後に、Flask/FastAPI をデプロイするための理想的なプラットフォームである Leapcell を紹介します。
Leapcell は、最新の分散アプリケーション向けに特別に設計されたクラウド コンピューティング プラットフォームです。従量課金制の料金モデルにより、アイドルコストは発生しません。つまり、ユーザーは実際に使用したリソースに対してのみ料金を支払います。
WSGI/ASGI アプリケーションに対する Leapcell の独自の利点:
ドキュメントで詳細を確認してください!
Leapcell Twitter: https://x.com/LeapcellHQ
以上がフラスコは死んだのか？ FastAPI は未来ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
