8 つの偉大な小さな Python Web フレームワーク

Python の便利さと多様性は、IT ライフのほぼすべての歩みにおいてソフトウェアを構築するために使用されていることを意味します。そして、あなたが推測するように、Python は小さいものから大きいものまで、Web フレームワークにおけるたくさんの選択肢と自由度をあなたに与えます。結局のところ、すべてのWebプロジェクトが企業規模である必要はありません。ほとんどは、仕事を成し遂げるのに十分な大きさであるべきで、それ以上ではありません。この記事では、シンプルさ、軽量化、およびタイトなフォーカスを強調する、最もよく知られた Python フレームワークの 8 つを調査します。

Bottle
CherryPy
Falcon
Pyramid
Sanic

Bottle

Bottle は、他の「マイクロフレームワーク」よりもさらにコンパクトで簡潔なため、一種のミニ Flask と見なされることがあります。その最小限のフットプリントのために、Bottle は他のプロジェクトに含めるか、REST API のような小さなプロジェクトを迅速に提供するために理想的です。 (Flask については後述します。)

Bottle のコードベース全体は 1 つのファイルに収まり、外部依存はまったくありません。それでも、Bottle には、外部の手助けに頼らずに一般的な種類の Web アプリケーションを構築するのに十分な機能が備わっています。

URL を関数にマッピングする Bottle のルーティングシステムは、Flask とほとんど同じ構文を持っています。パスのセットもハードワイヤードに限定されず、動的に作成することができます。リクエストとレスポンスデータ、Cookie、クエリ変数、POST アクションからのフォームデータ、HTTP ヘッダー、およびファイルアップロードはすべて、Bottle のオブジェクトによってアクセスおよび操作することが可能です。たとえば、ファイルのアップロードでは、命名規則がターゲットファイルシステムと衝突する場合、ファイル名を変更する必要はありません (Windows ではスラッシュが名前に含まれているなど)。

Bottle には、独自のシンプルな HTML テンプレートエンジンが搭載されています。繰り返しますが、最小限のものではありますが、テンプレート化エンジンは必要不可欠なものをすべて備えています。テンプレートに含まれる変数は、デフォルトで安全な HTML でレンダリングされます; 文字どおりに再現するために、どの変数が安全であるかを示す必要があります。もし、BottleのテンプレートエンジンをJinja2のような別のものに交換したい場合は、Bottleを使えば手間なく交換できます。私は、Bottle にバンドルされているシンプルなテンプレートシステムを好みます。それは高速で、その構文は気取らず、過度の困難なしにコードとテンプレートテキストを混在させることができます。迅速なテストのために独自の組み込みミニサーバーが付属していますが、一般的な WSGI や WSGI 互換の幅広い HTTP サーバー、そして必要であれば古い CGI もサポートします。重要なものはすべて、ひとつの (長いとはいえ) Web ページに収まっています。

Flask と同様に、手動またはプラグインによって Bottle の機能を拡張することができます。

Flaskと同様に、手動またはプラグインによってBottleの機能を拡張できます。BottleプラグインはFlaskほど多くはありませんが、さまざまなデータベース層との統合や基本ユーザー認証など、便利な要素があります。非同期サポートについては、Bottle は aiohttp/uvloop などの非同期で実行する既存のサーバーアダプターの 1 つを使用できますが、async/await はネイティブにはサポートされていません。

Bottle の最小主義の結果の 1 つは、いくつかのアイテムが単に存在しない、ということです。 CSRF (クロスサイトリクエストフォージェリ) 保護のような機能を含むフォーム検証は含まれていません。高度なユーザーインタラクションをサポートする Web アプリケーションを構築したい場合、そのサポートを自分で追加する必要があります。

Bottle のもうひとつの問題は、開発が止まっていることです。とはいえ、Bottle は引き続き保守されており、その開発リリースは実運用に使用可能なままです。開発者は、Python のレガシーエディションをサポートしない新しいバージョンを提供するつもりです。

CherryPy

CherryPy は何らかの形でほぼ 20 年間存在していますが、当初からの特徴である最小主義と優雅さを失ってはいません。

CherryPy の背後にある目標は、Web ページを提供するために必要な最低限のものしか含まれていないことに加え、できる限り「Web フレームワーク」のようにではなく、他の種類の Python アプリケーションのように感じることです。 HuluやNetflixのようなサイトは、CherryPyが非常に控えめなベースを提供するため、実運用でCherryPyを使用しています。 CherryPy は、マルチスレッドサーバーアダプターをサポートするために、フードの下でプールされたスレッドを使用します。

CherryPy では、Web アプリケーションをコアロジックから分離しておくことができます。アプリケーションの関数を CherryPy が提供する URL またはルートにマッピングするには、オブジェクトの名前空間が提供したい URL に直接マッピングされるクラスを作成します。例えば、ウェブサイトのルートは “index” という名前の関数で提供されます。それらの関数に渡されるパラメーターは、GET または POST メソッドによって提供される変数を処理するために使用されます。

CherryPy が含むビットは、低レベルの構成要素として機能することを意図しています。セッション識別子とクッキーの処理は含まれていますが、HTML テンプレートは含まれていません。 Bottle のように、CherryPy は静的ファイル提供のためにディスク上のディレクトリにルートをマップする方法を提供します。

CherryPy はしばしば、機能をネイティブに提供するのではなく、サポートするために既存のサードパーティ・ライブラリに依存します。例えば、WebSocketアプリケーションはCherryPyによって直接サポートされていませんが、ws4pyライブラリを通してサポートされています。

CherryPyのドキュメントには、プログラムのさまざまな側面に関する便利なチュートリアルウォークスルーが含まれています。他のフレームワークのチュートリアルとは異なり、完全なエンドツーエンドのアプリケーションを案内してくれるわけではありませんが、それでも有用です。ドキュメントには、バーチャルホストでの展開、Apache と Nginx を介したリバースプロキシ、および他の多くのシナリオに関する便利なメモが付属しています。

Falcon

もしあなたが REST ベースの API を構築していて他のことはしていないなら、ファルコンはあなたのために作られたものです。リーンかつ高速で、標準ライブラリを超える依存関係はほとんどなく、ファルコンは REST API に必要なものすべてを提供し、それ以上のものはありません。 2019 年にリリースされた Falcon 2.0 では、Python 2.x のサポートがなくなり、少なくとも Python 3.5 が必要です。

Falcon が「軽くて細い」というラベルを獲得した理由の大部分は、フレームワーク内のコードの行数とはあまり関係がありません。それは、Falcon がアプリケーションにそれ自身の構造をほとんど課さないからです。ファルコンのアプリケーションがしなければならないことは、どの関数がどのAPIエンドポイントにマッピングされるかを示すことだけです。エンドポイントからJSONを返すには、ルートを設定し、Pythonの標準ライブラリからjson.dumps関数経由でデータを返すだけでよいのです。非同期のためのサポートはまだ Falcon に上陸していませんが、Falcon 3.0 でそれを実現するための作業が進行中です。

Falcon はまた、箱から出してそのまま使えるデフォルトを採用しているので、設定のために少しいじる必要があるだけです。たとえば、明示的に宣言されていないルートに対しては、デフォルトで404が発生します。クライアントにエラーを返したい場合は、フレームワークにバンドルされているいくつかの例外 (たとえば HTTPBadRequest) を発生させるか、汎用の falcon.HTTPError 例外を使用します。ルートの前処理または後処理が必要な場合、Falcon はそれらのためのフックも提供します。

Falcon の API への注力は、従来の HTML ユーザーインターフェイスで Web アプリケーションを構築するためのものがここにはほとんどないことを意味しています。たとえば、フォーム処理関数や CSRF 保護ツールはあまり期待しないでください。とはいえ、ファルコンはその機能を拡張するためのエレガントなオプションを提供しますので、より洗練されたアイテムを構築することができます。前述のフッキングメカニズムの他に、Falcon のすべての API をラップするために使用できるミドルウェアを作成するためのインターフェイスが見つかります。

Falcon のドキュメントは他のフレームワークと比較して細身ですが、それはカバーするものが少ないからです。ユーザーガイドには、すべての主要な機能の正式なステップバイステップのウォークスルーと、注釈付きまたは注釈なしのサンプルコードを見ることができるクイックスタートのセクションが含まれています。 API エンドポイントをすばやく作成するために構築され、動作も高速です。

FastAPI は、高速ネットワーキング・コアの Starlette プロジェクトを使用しますが、FastAPI を使用するのに Starlette の内部について知る必要はありません。どの関数がどのルートを処理するかを示すためにデコレーターを使用し、そして、自動的に JSON に変換されるディクショナリを返します。たとえば、いくつかのエンドポイントから HTML/XML を返したい場合、単にカスタム Response オブジェクトを返すことによってそれを行うことができます。カスタム・ミドルウェアを追加したい場合は、ASGI標準に従ったものであれば何でもポンと入れることができます。

FastAPI は Python のタイプヒンティングを使用して、ルートが受け入れるデータの種類に制約を与えます。たとえば、タイプ Optional を持つルートがある場合、FastAPI は整数以外のすべてのサブミットを拒否します。エンドポイントにデータ検証コードを追加する必要はありません。タイプヒントを使用し、FastAPI に作業をさせることができます。たとえば、ネイティブの HTML テンプレートエンジンはありませんが、そのギャップを埋めるサードパーティ製ソリューションには事欠きません。データベース接続についても同様ですが、ドキュメントには、特定の ORM (例: Peewee) を FastAPI の非同期動作で動作するように誘導する方法についての詳細が記載されています。 Flask はよく確立された、よく理解されたフレームワークであり、使いやすく、非常に安定しています。軽量なWebプロジェクトや基本的なREST APIにFlaskを使用して失敗することはほぼ不可能ですが、より大きなものを構築しようとすると、重い荷物に直面するでしょう。

Flask の主な魅力は、エントリへの低い障壁です。基本的な「hello world」アプリは、Pythonの10行未満でセットアップ可能です。しかし、Jinja2は(Mustacheのような)他の多くのテンプレートエンジンと交換することができますし、自分で作ることもできます。

シンプルさの名の下に、Flaskはデータ層やORMなどの巧妙なものを省き、フォームバリデーションなどの規定も提供していません。しかし、Flask は、キャッシュ、フォーム処理と検証、およびデータベース接続などの多くの一般的なユースケースをカバーする、数十もある拡張機能によって拡張することができます。このリーンバイデフォルトの設計により、最小限の機能で Flask アプリケーションのエンジニアリングを開始し、必要なときに必要な部分のみをレイヤーで追加することが可能です。クイックスタートドキュメントでは、シンプルな Flask アプリケーションのデフォルトの選択肢の重要性を説明しながら、あなたを始めるための素晴らしい仕事をしていますし、API ドキュメントは良い例で満たされています。また、Flash snippets のコレクションも優れており、オブジェクトが存在する場合はそれを、存在しない場合は 404 エラーを返す方法など、特定のタスクを達成する方法のクイックアンドダーティの例です。

Flask は 2018 年にマイルストーンの 1.0 リリースを行い、 Python 2.6 と Python 3.3 が最小サポートバージョンで、多くの動作がようやく定められました。 FlaskはPythonの非同期構文を明示的にサポートしていませんが、その要求を満たすためにQuartというAPI互換性のあるFlaskのバリエーションがスピンオフしています。

Pyramid

小さくて軽い Pyramid は、既存の Python コードを REST API として公開したり、開発者が重い作業のほとんどを行う Web プロジェクト用のコアを提供するなどのタスクによく向いています。「アプリケーションが小さいうちは足かせにならず、大きくなっても邪魔になりません。」

Pyramidの最小主義を表現する良い方法は「free of policy」で、これは他のWebフレームワークに対してPyramidがどのように構成されているかを論じたドキュメントのセクションで使われている用語です。基本的に、「フリー・オブ・ポリシー」とは、どのデータベースやどのテンプレート言語を使用するかはPyramidの関心事ではない、ということを意味します。 BottleやFlaskと同様に、Pyramidアプリケーションは、フレームワーク自体のファイルを除けば、単一のPythonファイルで構成することができます。単純なワンルートAPIであれば、数十行のコードしか必要ありません。そのほとんどは、from … importステートメントやWSGIサーバーのセットアップなどの定型文です。

デフォルトで、PyramidはWebアプリケーションで一般的ないくつかのアイテムを含んでいますが、それらは完全なソリューションとしてではなく、つなぎ合わせるためのコンポーネントとして提供されています。たとえば、ユーザーセッションのサポートには、CSRF 保護機能まで付いています。しかし、ログインやアカウント管理といったユーザーアカウントのサポートは、このパッケージの一部ではありません。自分で開発するか、プラグインで追加する必要があります。フォーム処理やデータベース接続も同様です。

Pyramid には、以前の Pyramid プロジェクトからテンプレートを作成し、以前の作業を再利用する方法も用意されています。これらのテンプレートは「scaffolds」と呼ばれ、簡単なルーティングといくつかのスターター HTML/CSS テンプレートで Pyramid アプリを生成します。バンドルされているscaffoldには、サンプルのスタータープロジェクトと、人気のあるPythonライブラリSQLAlchemyを介してデータベースに接続するプロジェクトが含まれています。

Pyramid の細いテストとデバッグのツールは、トリックを行います。 Pyramid のアプリに debugtoolbar 拡張機能をバンドルすると、すべての Web ページにクリック可能なアイコンを表示し、エラー発生時の詳細なトレースバックを含むアプリの実行に関する詳細情報を生成することができます。また、ロギングとユニットテストもあります。

Pyramid のドキュメントは優れています。基本的なクイックツアーやチュートリアルスタイルのウォークスルーに加え、コミュニティによって寄稿されたチュートリアルのセットや、一般的なレシピのクックブックが用意されています。後者には、Google App Engine から Nginx まで、多数のターゲット環境のためのデプロイメントテクニックが含まれています。

Pyramid は Python 2 と Python 3 の両方をサポートしますが、Python 3 の非同期構文は使用しません。 Pyramid で非同期を利用したい場合は、aiopyramid プロジェクトを参照してください。

Sanic

スピードとシンプルさのために設計された Sanic は Python 3.6 以上で動作し、Python の async/await 構文 (Python 3.5 で有効) を使用して、効率的に Web アプリケーションを作成できます。

flask や Bottle と同様、基本的な Sanic “hello world” は約 10 行で、ほとんどは import や他の定型文から成っています。主な違いは、アプリケーションルートは async def 関数として宣言する必要があり、非同期コード内でこれらの関数を呼び出すには await を使用する必要があることです。

Sanic が接続と応答を処理するために使用するメカニズムの多くは、馴染みのあるものでしょう。リクエストとレスポンスは、アップロードされたファイル、フォーム、JSON オブジェクト、ヘッダーなど、見慣れたプロパティを持つオブジェクトに過ぎません。 Sanic は、ルートのグループを記述し、高レベルのインターフェイスを介してそれらを管理できるようにするオブジェクトである「ブループリント」でこれに対処します。各ルートを明示的に記述したり、変数で過剰なルートを使用する代わりに、いくつかのブループリントを記述して、アプリでルートがどのように動作するかを一般的に記述できます (例: /object/object_id/action)。ブループリントは共通のミドルウェアを持つことができ、一部のルートに管理機能を適用し、他のルートには適用しない場合に便利です。

Sanic は、HTTP 以外のプロトコルでも機能します。 WebSocket エンドポイントでは、異なるデコレーターと少し多めの内部ロジック (応答の待機と処理など) が必要なだけです。

Sanic は、データベース接続や HTML テンプレートなどの機能を意図的に除外していますが、これらの機能を追加するために使用される機能 (ミドルウェア、集中アプリケーション構成など) は保持しています。 Tornado は、非常に多くのネットワーク接続を開き、それを維持するサービスの作成に適しています。つまり、WebSocket や長いポーリングを含むものです。 Tornado 6.0 は Python 3.5 以上を必要とし、Python 2 のサポートを完全に打ち切ります。

Bottle や Falcon のように、Tornado はその中心目的から外れる機能を省いています。 Tornado は HTML やその他の出力を生成するための組み込みのテンプレートシステムを持ち、国際化、フォーム処理、クッキー設定、ユーザー認証、および CSRF 保護のための機構を提供します。しかし、フォーム検証や ORM のような、主にユーザー向け Web アプリケーションのための機能は残していない。

Tornado は、非同期ネットワーキングを詳細に制御する必要があるアプリケーションにインフラを提供することにおいて優れている。たとえば、Tornado は組み込みの非同期 HTTP サーバーだけでなく、非同期 HTTP クライアントも提供します。したがって、Tornado は、Web スクレイパーや bot など、他のサイトに並行して問い合わせを行い、返されたデータに基づいて動作するアプリケーションを構築するのに適している。 Tornado は、DNS リゾルバなどのユーティリティやサードパーティの認証サービスへの低レベル TCP 接続およびソケットへのアクセスを提供し、WSGI 標準を通じて他のフレームワークとの相互運用をサポートします。

Tornado は、非同期動作のための Python のネイティブな機能を活用し、補完する。 Python 3.5 を使用している場合、Tornado は組み込みの async および await キーワードをサポートし、アプリケーションの速度を向上させることを約束します。

Tornado は、非同期コルーチン間のイベントを調整するための同期プリミティブ – マフォア、ロック、などのライブラリを提供します。 Tornado は通常シングルスレッドで実行されるため、これらのプリミティブはスレッドの名前と同じものではないことに注意してください。しかし、複数のソケットやコアを活用するために Tornado を並列プロセスで実行したい場合、そのためのツールが利用可能です。

Tornado のドキュメントは、フレームワークの各主要概念およびモデルの主要な API をすべて網羅しています。サンプルアプリケーション (ウェブクローラー) も含まれていますが、これは主に Tornado のキューイングモジュールのデモのためのものです。

Free Press