代替案、インスピレーション、比較

FastAPI のインスピレーションとなったもの、代替案との比較、およびそれらから学んだこと。

はじめに

FastAPI は、他の人々の過去の努力がなければ存在しなかったでしょう。

その作成を刺激した多くのツールが以前に作成されてきました。

私は数年間、新しいフレームワークの作成を避けてきました。最初に、私は多くの異なるフレームワーク、プラグイン、およびツールを使用して、FastAPI でカバーされているすべての機能を解決しようとしました。

しかし、ある時点で、これらのすべての機能を提供し、以前のツールから最高のアイデアを取り入れ、それらを可能な限り最適な方法で組み合わせ、以前には利用できなかった言語機能（Python 3.6+ 型ヒント）を使用する何かを作成する以外に選択肢はありませんでした。

以前のツール

Django

最も人気のあるPythonフレームワークであり、広く信頼されています。Instagramのようなシステムを構築するために使用されます。

比較的にリレーショナルデータベース（MySQLやPostgreSQLなど）と密接に結合しているため、NoSQLデータベース（Couchbase、MongoDB、Cassandraなど）をメインのストレージエンジンとして使用するのは非常に簡単ではありません。

これはバックエンドでHTMLを生成するために作成されたものであり、最新のフロントエンド（React、Vue.js、Angularなど）または（IoTデバイスのような）他のシステムが通信するAPIを作成するためのものではありません。

Django REST Framework

Django REST frameworkは、Djangoを基盤として使用し、API機能を向上させるためのWeb APIを構築するための柔軟なツールキットとして作成されました。

Mozilla、Red Hat、Eventbriteを含む多くの企業で使用されています。

これは自動APIドキュメントの最初の例の1つであり、これが具体的にFastAPI の「探求」を刺激した最初のアイデアの1つでした。

注意

Django REST Frameworkは、Tom Christieによって作成されました。彼は、FastAPI の基盤となるStarletteとUvicornの同じクリエイターです。

「FastAPI のインスピレーション」

自動APIドキュメントWebユーザーインターフェイスを備える。

Flask

Flaskは「マイクロフレームワーク」であり、データベース統合やDjangoにデフォルトで付属する多くのものは含まれていません。

このシンプルさと柔軟性により、NoSQLデータベースをメインのデータストレージシステムとして使用するなどのことが可能です。

非常にシンプルなため、習得するのは比較的直感的ですが、ドキュメントはある時点でやや技術的なものになります。

また、データベース、ユーザー管理、またはDjangoにプリビルドされている多くの機能のいずれかを必ずしも必要としない他のアプリケーションにもよく使用されます。ただし、これらの機能の多くはプラグインで追加できます。

このパーツの分離と、必要なものを正確にカバーするために拡張できる「マイクロフレームワーク」であることは、私が維持したかった重要な機能でした。

Flaskのシンプルさを考えると、APIを構築するのに適しているように思えました。次に探すのは、Flask用の「Django REST Framework」でした。

「FastAPI のインスピレーション」

マイクロフレームワークであること。必要なツールとパーツを組み合わせて簡単に使用できるようにすること。

シンプルで使いやすいルーティングシステムを備えていること。

Requests

FastAPI は実際には Requests の代替ではありません。両者のスコープは大きく異なります。

実際には、Requests を FastAPI アプリケーションの内部で使用するのが一般的でしょう。

しかし、それでも、FastAPI は Requests からかなりの影響を受けています。

Requests は API と対話するためのライブラリ（クライアントとして）であり、FastAPI は API を構築するためのライブラリ（サーバーとして）です。

これらは、多かれ少なかれ、反対側の端にあり、互いに補完し合います。

Requests は非常にシンプルで直感的な設計で、使いやすく、適切なデフォルト設定を備えています。同時に、非常に強力でカスタマイズ可能です。

そのため、公式ウェブサイトで述べられているように

Requests は、これまでで最もダウンロードされた Python パッケージの1つです。

その使い方は非常に簡単です。例えば、GETリクエストを行うには、次のように記述します。

response = requests.get("http://example.com/some/url")

FastAPI の対応する API パス操作 は次のようになります。

@app.get("/some/url")
def read_url():
    return {"message": "Hello World"}

requests.get(...) と @app.get(...) の類似点を見てください。

「FastAPI のインスピレーション」

• シンプルで直感的な API を持つこと。
• HTTP メソッド名（操作）を直接、分かりやすく直感的な方法で使用すること。
• 適切なデフォルト設定を持ちながら、強力なカスタマイズが可能であること。

Swagger / OpenAPI

Django REST Framework から私が望んでいた主な機能は、API ドキュメントの自動生成でした。

その後、Swagger という、JSON（または JSON の拡張である YAML）を使用して API をドキュメント化する標準があることが分かりました。

そして、Swagger API 用のウェブユーザーインターフェースが既に作成されていました。そのため、API の Swagger ドキュメントを生成できるようになれば、このウェブユーザーインターフェースを自動的に使用できるようになるでしょう。

ある時点で、Swagger は Linux Foundation に渡され、OpenAPI に名前が変更されました。

そのため、バージョン 2.0 について話すときは「Swagger」と言うのが一般的で、バージョン 3 以降では「OpenAPI」と言うのが一般的です。

「FastAPI のインスピレーション」

カスタムスキーマではなく、API 仕様のオープンスタンダードを採用し、使用すること。

そして、標準ベースのユーザーインターフェースツールを統合すること

• Swagger UI
• ReDoc

これら2つは、非常に人気があり安定しているため選ばれましたが、簡単な検索をすると、OpenAPI の代替ユーザーインターフェースが多数見つかります（これらは FastAPI で使用できます）。

Flask REST framework

いくつかの Flask REST フレームワークがありますが、それらを調査するために時間と労力を費やした結果、多くが廃止または放棄されており、解決されていない問題がいくつかあり、不適切であることが分かりました。

Marshmallow

API システムに必要な主な機能の1つは、データの「シリアライゼーション」です。これは、コード（Python）からのデータを取り出し、ネットワーク経由で送信できるものに変換することです。たとえば、データベースからのデータを含むオブジェクトを JSON オブジェクトに変換したり、datetime オブジェクトを文字列に変換したりするなどです。

API に必要なもう1つの大きな機能は、データ検証です。これは、データが特定のパラメータに基づいて有効であることを確認することです。たとえば、あるフィールドが int であり、ランダムな文字列ではないことなどです。これは、受信データに特に役立ちます。

データ検証システムがないと、コードですべてのチェックを手動で行う必要があります。

これらの機能は、Marshmallow が提供するために構築されたものです。これは素晴らしいライブラリであり、私は以前に何度も使用しました。

しかし、これは Python の型ヒントが存在する前に作成されました。そのため、すべての スキーマ を定義するには、Marshmallow が提供する特定のユーティリティとクラスを使用する必要があります。

「FastAPI のインスピレーション」

データ型と検証を自動的に提供する「スキーマ」を定義するためにコードを使用すること。

Webargs

API に必要なもう1つの大きな機能は、受信リクエストからのデータの 解析 です。

Webargs は、Flask を含むいくつかのフレームワーク上でこれを提供するために作成されたツールです。

データ検証には、内部で Marshmallow を使用します。そして、同じ開発者によって作成されました。

これは素晴らしいツールであり、FastAPI を持つ前は私もよく使用していました。

情報

Webargs は、同じ Marshmallow 開発者によって作成されました。

「FastAPI のインスピレーション」

受信リクエストデータの自動検証を持つこと。

APISpec

Marshmallow と Webargs は、検証、解析、シリアライゼーションをプラグインとして提供します。

しかし、ドキュメントはまだ不足しています。そこで APISpec が作成されました。

これは多くのフレームワーク用のプラグインです（Starlette 用のプラグインもあります）。

その仕組みは、各ルートを処理する関数のドキュメンテーション文字列内に YAML 形式を使用してスキーマの定義を記述するというものです。

そして、OpenAPI スキーマを生成します。

これが、Flask、Starlette、Responder などでの仕組みです。

しかし、ここでも Python 文字列（大きな YAML）の中にマイクロシンタックスがあるという問題が発生します。

エディターはそれほど役に立ちません。また、パラメータまたは Marshmallow スキーマを変更して、その YAML ドキュメンテーション文字列も変更するのを忘れると、生成されたスキーマは古くなります。

情報

APISpec は、同じ Marshmallow 開発者によって作成されました。

「FastAPI のインスピレーション」

API のオープンスタンダードである OpenAPI をサポートすること。

Flask-apispec

これは、Webargs、Marshmallow、APISpec を結び付ける Flask プラグインです。

Webargs と Marshmallow からの情報を使用して、APISpec を使用して OpenAPI スキーマを自動的に生成します。

これは素晴らしいツールであり、非常に過小評価されています。そこにある多くの Flask プラグインよりもはるかに人気があるはずです。ドキュメントが簡潔すぎて抽象的であることが原因かもしれません。

これにより、Python ドキュメンテーション文字列の中に YAML（別の構文）を記述する必要がなくなりました。

この Flask、Flask-apispec と Marshmallow と Webargs の組み合わせは、私が FastAPI を構築するまでのお気に入りのバックエンドスタックでした。

これを使用したことで、いくつかの Flask フルスタックジェネレーターが作成されました。これらは、私（およびいくつかの外部チーム）がこれまで使用してきた主なスタックです。

• https://github.com/tiangolo/full-stack
• https://github.com/tiangolo/full-stack-flask-couchbase
• https://github.com/tiangolo/full-stack-flask-couchdb

そして、これらの同じフルスタックジェネレーターが、FastAPI プロジェクトジェネレーターのベースになりました。

情報

Flask-apispec は、同じ Marshmallow 開発者によって作成されました。

「FastAPI のインスピレーション」

シリアライゼーションと検証を定義する同じコードから、OpenAPI スキーマを自動的に生成すること。

NestJS (および Angular)

これは Python ですらありません。NestJS は、Angular に触発された JavaScript（TypeScript）NodeJS フレームワークです。

Flask-apispec でできることと多少似たことを実現します。

Angular 2 に触発された統合依存性注入システムを備えています。 「インジェクタブル」を事前登録する必要があります（私が知っている他のすべての依存性注入システムと同様）。そのため、冗長性とコードの繰り返しが増えます。

パラメータは TypeScript 型（Python の型ヒントに似ています）で記述されているため、エディターのサポートは非常に優れています。

しかし、TypeScript データは JavaScript へのコンパイル後に保持されないため、型に依存して検証、シリアライゼーション、およびドキュメントを同時に定義することはできません。このため、およびいくつかの設計上の決定により、検証、シリアライゼーション、および自動スキーマ生成を取得するには、多くの場所にデコレータを追加する必要があります。そのため、非常に冗長になります。

ネストされたモデルをうまく処理できません。したがって、リクエストの JSON ボディが、ネストされた JSON オブジェクトである内部フィールドを持つ JSON オブジェクトである場合、適切にドキュメント化および検証することはできません。

「FastAPI のインスピレーション」

優れたエディターサポートのために Python 型を使用すること。

強力な依存性注入システムを持つこと。コードの繰り返しを最小限に抑える方法を見つけること。

Sanic

これは、asyncio に基づく最初の非常に高速な Python フレームワークの1つでした。Flask に非常に似ているように作られました。

「技術的な詳細」

デフォルトの Python asyncio ループの代わりに、uvloop を使用しました。それが非常に高速になった理由です。

現在、オープンベンチマークで Sanic よりも高速である Uvicorn と Starlette に明らかに影響を与えました。

「FastAPI のインスピレーション」

驚異的なパフォーマンスを実現する方法を見つけること。

そのため、FastAPI は Starlette に基づいています。これは、利用可能な最速のフレームワーク（サードパーティのベンチマークによってテスト済み）であるためです。

Falcon

Falcon は、別の高性能 Python フレームワークであり、最小限に抑えられ、Hug のような他のフレームワークの基礎として機能するように設計されています。

これは、2つのパラメータ（1つは「リクエスト」、もう1つは「レスポンス」）を受け取る関数を持つように設計されています。次に、リクエストから「読み取り」、レスポンスに「書き込み」を行います。この設計のため、標準の Python 型ヒントを関数パラメータとして使用して、リクエストパラメータとボディを宣言することはできません。

そのため、データ検証、シリアライゼーション、およびドキュメントは、自動的にではなく、コードで行う必要があります。または、Hug のように Falcon 上のフレームワークとして実装する必要があります。この同じ区別は、パラメータとして1つのリクエストオブジェクトと1つのレスポンスオブジェクトを持つという Falcon の設計に触発された他のフレームワークでも発生します。

「FastAPI のインスピレーション」

優れたパフォーマンスを得る方法を見つけること。

Hug（Hug は Falcon に基づいているため）と共に、FastAPI が関数で response パラメータを宣言するように触発しました。

ただし、FastAPI ではオプションであり、主にヘッダー、クッキー、代替ステータスコードを設定するために使用されます。

Molten

FastAPI の構築の初期段階で Molten を発見しました。そして、それは非常に似たアイデアを持っています

• Python の型ヒントに基づく。
• これらの型からの検証とドキュメント。
• 依存性注入システム。

Pydantic のようなデータ検証、シリアライゼーション、ドキュメントのサードパーティライブラリを使用していません。独自のものを使用しています。そのため、これらのデータ型定義はそれほど簡単には再利用できません。

もう少し冗長な構成が必要です。また、WSGI（ASGI の代わりに）に基づいているため、Uvicorn、Starlette、Sanic などのツールによって提供される高パフォーマンスを利用するように設計されていません。

依存性注入システムでは、依存関係の事前登録が必要であり、依存関係は宣言された型に基づいて解決されます。そのため、特定の型を提供する複数の「コンポーネント」を宣言することはできません。

ルートは、他の場所で宣言された関数を使用して1か所で宣言されます（エンドポイントを処理する関数のすぐ上に配置できるデコレータを使用するのではなく）。これは、Flask（および Starlette）が行う方法よりも、Django が行う方法に近いです。コード内の比較的密接に結合されたものを分離します。

「FastAPI のインスピレーション」

モデル属性の「デフォルト」値を使用して、データ型の追加の検証を定義します。これにより、エディターのサポートが向上し、以前は Pydantic では利用できませんでした。

実はこれが、Pydanticの一部の更新を促し、同じ検証宣言スタイルをサポートするきっかけとなりました（この機能はすべてPydanticで既に利用可能です）。

Hug

Hugは、Pythonの型ヒントを使用してAPIパラメータの型を宣言する最初のフレームワークの1つでした。これは素晴らしいアイデアであり、他のツールも同様のことを行うように促しました。

標準のPython型ではなく、宣言にカスタム型を使用していましたが、それでも大きな進歩でした。

また、API全体をJSONで宣言するカスタムスキーマを生成した最初のフレームワークの1つでもありました。

OpenAPIやJSON Schemaのような標準に基づいたものではなかったため、Swagger UIなどの他のツールと統合するのは簡単ではありませんでした。しかし、これも非常に革新的なアイデアでした。

興味深く、珍しい機能があります。同じフレームワークを使用して、APIとCLIの両方を作成できます。

同期Python Webフレームワークの以前の標準（WSGI）に基づいているため、Websocketなどの他のことは処理できませんが、それでも高いパフォーマンスを発揮します。

情報

Hugは、Pythonファイル内のimportを自動的にソートする優れたツールであるisortの作成者であるTimothy Crosleyによって作成されました。

「FastAPIにインスピレーションを与えたアイデア」

HugはAPIStarの一部にインスピレーションを与え、APIStarと並んで最も有望なツールの一つでした。

Hugは、FastAPIがPythonの型ヒントを使用してパラメータを宣言し、APIを自動的に定義するスキーマを生成するインスピレーションとなりました。

Hugは、FastAPIがヘッダーとクッキーを設定するために、関数にresponseパラメータを宣言するインスピレーションとなりました。

APIStar (<= 0.5)

FastAPIを構築することを決める直前に、APIStarサーバーを見つけました。それには私が探していたものがほぼすべて含まれており、優れたデザインでした。

私がこれまで見た中で、パラメータとリクエストを宣言するためにPythonの型ヒントを使用したフレームワークの最初の実装の1つでした（NestJSやMoltenよりも前）。Hugとほぼ同時期に見つけました。しかし、APIStarはOpenAPI標準を使用していました。

いくつかの場所で、同じ型ヒントに基づいて、自動データ検証、データシリアル化、OpenAPIスキーマ生成が行われました。

ボディスキーマの定義はPydanticのような同じPythonの型ヒントを使用していませんでした。Marshmallowに少し似ていたため、エディターのサポートはそれほど良くありませんでしたが、それでもAPIStarは利用可能な最高のオプションでした。

当時、最高のパフォーマンスベンチマークを持っていました（Starletteにのみ追い抜かれています）。

当初は自動APIドキュメントWeb UIがありませんでしたが、Swagger UIを追加できることは知っていました。

依存性注入システムがありました。他のツールと同様に、コンポーネントの事前登録が必要でした。それでも、素晴らしい機能でした。

セキュリティ統合がなかったため、Flask-apispecに基づいたフルスタックジェネレーターで持っていたすべての機能を置き換えることができなかったため、フルプロジェクトで利用することはできませんでした。その機能を追加するプルリクエストを作成するプロジェクトのバックログがありました。

しかしその後、プロジェクトの焦点は変わりました。

作成者がStarletteに集中する必要があったため、API Webフレームワークではなくなりました。

現在、APIStarは、Webフレームワークではなく、OpenAPI仕様を検証するためのツールセットです。

情報

APIStarは、Tom Christieによって作成されました。彼は以下のものを開発した人物でもあります。

• Django REST Framework
• Starlette（FastAPIの基礎となっているもの）
• Uvicorn（StarletteとFastAPIで使用）

「FastAPI のインスピレーション」

Exist。

同じPython型で複数のこと（データ検証、シリアル化、ドキュメント）を宣言するアイデアは、同時に優れたエディターサポートを提供し、素晴らしいアイデアであると考えました。

同様のフレームワークを長い間探し、多くの異なる代替案をテストした後、APIStarが利用可能な最良の選択肢でした。

その後、APIStarはサーバーとしての存在を停止し、Starletteが作成され、そのようなシステムにとってより優れた新しい基盤となりました。それがFastAPIを構築するための最終的なインスピレーションでした。

FastAPIは、APIStarの「精神的な後継者」であり、これまでのすべてのツールの学習に基づいて、機能、型システム、その他の部分を改善および強化していると考えています。

FastAPIで使用されているもの

Pydantic

Pydanticは、Pythonの型ヒントに基づいてデータ検証、シリアル化、ドキュメント（JSON Schemaを使用）を定義するためのライブラリです。

これにより、非常に直感的になります。

Marshmallowに匹敵しますが、ベンチマークではMarshmallowよりも高速です。また、同じPythonの型ヒントに基づいているため、エディターのサポートが優れています。

「FastAPIはこれを使用して」

すべてのデータ検証、データシリアル化、自動モデルドキュメント（JSON Schemaに基づく）を処理します。

その後、FastAPIはそのJSON Schemaデータを取得し、他のすべての処理に加えて、OpenAPIに配置します。

Starlette

Starletteは、軽量なASGIフレームワーク/ツールキットであり、高性能なasyncioサービスを構築するのに理想的です。

非常にシンプルで直感的です。拡張が容易で、モジュール式のコンポーネントを持つように設計されています。

以下を備えています。

• 非常に印象的なパフォーマンス。
• WebSocketのサポート。
• インプロセスバックグラウンドタスク。
• 起動およびシャットダウンイベント。
• HTTPXで構築されたテストクライアント。
• CORS、GZip、静的ファイル、ストリーミング応答。
• セッションとCookieのサポート。
• 100％のテストカバレッジ。
• 100％型アノテーション付きコードベース。
• 少ないハード依存関係。

Starletteは現在、テストされた中で最速のPythonフレームワークです。フレームワークではなくサーバーであるUvicornにのみ追い抜かれています。

Starletteは、すべての基本的なWebマイクロフレームワーク機能を提供します。

しかし、自動データ検証、シリアル化、またはドキュメントは提供しません。

それが、FastAPIがその上に加える主なものの1つであり、すべてPythonの型ヒント（Pydanticを使用）に基づいています。それに加えて、依存性注入システム、セキュリティユーティリティ、OpenAPIスキーマ生成などがあります。

「技術的な詳細」

ASGIは、Djangoコアチームメンバーによって開発されている新しい「標準」です。まだ「Python標準」（PEP）ではありませんが、そのプロセス中です。

それにもかかわらず、すでにいくつかのツールによって「標準」として使用されています。これにより、Uvicornを他のASGIサーバー（DaphneやHypercornなど）に切り替えたり、python-socketioのようなASGI互換ツールを追加したりできるため、相互運用性が大幅に向上します。

「FastAPIはこれを使用して」

すべてのコアWeb部分を処理します。上に機能を追加します。

クラスFastAPI自体は、クラスStarletteから直接継承します。

したがって、Starletteでできることはすべて、基本的にステロイドを使ったStarletteであるFastAPIで直接行うことができます。

Uvicorn

Uvicornは、uvloopとhttptools上に構築された高速ASGIサーバーです。

Webフレームワークではなく、サーバーです。たとえば、パスによるルーティング用のツールは提供していません。これは、Starlette（またはFastAPI）のようなフレームワークが上に追加するものになります。

StarletteとFastAPIに推奨されるサーバーです。

「FastAPIは以下として推奨します」

FastAPIアプリケーションを実行するためのメインWebサーバー。

--workersコマンドラインオプションを使用して、非同期マルチプロセスサーバーを持つこともできます。

詳細については、デプロイメントセクションを参照してください。

ベンチマークと速度

Uvicorn、Starlette、FastAPIの違いを理解し、比較するには、ベンチマークに関するセクションを確認してください。