Webフレームワークは強力なツールです。 彼らは、webサイトやApiを構築する共通の側面を抽象化し、より少ない労力でより豊かで安定したアプリケーションを構築することができます。
Pythonでは、さまざまなwebフレームワークが利用できます。 いくつかは、大規模な生態系やコミュニティと実績のあるお気に入りです。 他の人は、ニッチなユースケースや特定の種類の開発に優れています。 それでも、他の人は、考慮すべき説得力のある新しい理由を持つ新進気鋭です。 オプションを探索し、あなたのために最高の仕事を見つけるために読んでください。
興味のあるものが既にわかっている場合は、以下のリンクを使用してスキップしてください。
- ニーズに合ったフレームワークを選択する方法
- フルスタックフレームワーク対マイクロフレームワーク対 非同期フレームワーク
- Pythonのフルスタックフレームワーク
- PythonのためのMicroframeworks
- Pythonのための非同期フレームワーク
- Pythonのための非同期フレームワーク
- どのPythonウェブフレームワークがあなたのために最適ですか?
あなたが決定する助けをしたい場合は、また、私たちの推奨事項の概要にまっすぐにスキップすることができます。
- あなたのニーズに適したフレームワークを選択する方法
- フルスタックフレームワークとマイクロフレームワークと非同期フレームワーク
- フルスタックPythonフレームワーク
- Django
- ピラミッド
- Web2Py
- ターボギア
- マソナイト
- Python用のMicroframeworks
- Flask
- ボトル
- H3:CherryPy
- Falcon
- pythonの非同期フレームワーク
- Sanic
- FastAPI
- スターレット
- どのPython webフレームワークが最適ですか?このリストから明らかなように、多くの良いオプションがあります。 実際、Pythonには他にも多くのフレームワークがあります-この記事では、2020年に検討する価値があると考えられるフレームワークだけに意図的に制限しました。開始するには良い場所は、我々はこの記事の冒頭で述べた基準です。
あなたのニーズに適したフレームワークを選択する方法
フレームワークは、さまざまな問題を解決し、より良い彼らの意図された観客にサービスを提供するためにトレードオフを行うように設計されています。 誰もが同じ目標を持っていた場合、我々は唯一のフレームワークを必要とするだろう! フレームワークを評価する際には、いくつかの重要な考慮事項が含まれます。
- あなたが構築しているものの最終的なサイズと複雑さは何ですか?
- 独自のライブラリ、構成、アプリケーション構造を選択することを好むか、事前に選択したオプションのよりキュレーションセットをしたいですか?
- あなたのプロジェクトにとってパフォーマンスはどのように重要ですか?
- アプリケーションを開発してデプロイできるようにするには、どのくらいの速さが必要ですか?
- あなたのアプリケーションはどれくらいの期間、そして何人の開発者がそれに取り組む可能性がありますか?
さらに、潜在的な選択肢のために利用可能なドキュメントの品質と、プロジェクトの周りのコミュニティのサイズを考慮してください。あなたのオプションを探るように、これらの側面を念頭に置いてください-それらの多くがあります!
あなたの選択肢を探るように、これらの面 プロジェクトの寿命に応じて、フレームワークがあなたと一緒に成長する可能性があるかどうかも検討してください。 それはあなたの適用のためのよい適合今そして将来でであるか。
フルスタックフレームワークとマイクロフレームワークと非同期フレームワーク
Pythonフレームワークは、大きく三つのキャンプ、フルスタックフレームワーク、マイクロフレームワーク、非同期フレームワークに分けることができます。
フルスタックフレームワークは、一般的に、より大きな、フル機能のアプリケーションを構築することに焦点を当てており、箱から出して共通の機能の多 複雑なものを迅速に構築したい場合や、すべての選択肢を自分で行わずにアプリケーションをまとめる方法について合理的なデフォルトが必要な フルスタックフレームワークは、一般的に、データベースとの通信、ビューのテンプレート化、キューの管理、バックグラウンドジョブ、および大規模なアプリケーショ
Microframeworksは、一般的に機能の小さなコアを提供することに焦点を当てており、他の機能のために追加するライブラリや技術について、開発者が独自の選 これには、アプリケーション設計をより詳細に制御できるという利点があり、アプリケーションのパフォーマンスが向上する可能性があります。 彼らは通常、開発者が独自のデータベース抽象化層と他のライブラリを選択する必要があります。 Microframeworksは、より小さく、より狭く焦点を絞ったアプリケーション、API開発、またはパフォーマンスがより重要なアプリケーションに最適です。
非同期フレームワークは、非常に多数の同時接続を許可することにより、高いレベルのパフォーマンスを提供することに焦点を当てています。 Geventのような非同期対応のサーバーと組み合わせることで、ほとんどの同期フレームワークの同時実行性を大幅に向上させることができますが、ネイティブの非同期フレームワークは完全に非同期スタックでさらに一歩進んでいます。 一般的に、非同期フレームワークは、プログラミングスタイルでより厳密に必要とし、プラグインのセットがより限定されています。 非同期フレームワークは、特定の機能を非常に大量に提供する必要がある場合に最適です。
フルスタックPythonフレームワーク
Django
DjangoはPythonのための最も人気のあるフルスタックフレームワークです。 これは、複雑なwebアプリを構築するときに非常に生産的であることのために当然の評判を持っています。 “期限のある完璧主義者のためのwebフレームワーク”と呼ばれる、その焦点は、一般的なケースのための十分に文書化されたオプションを使用して急速な開Djangoは10年以上(2006年の最初のリリース)存在しており、成熟しており、包括的で、十分に文書化されており、非常に大規模なコミュニティを持っています。 これは、開発者のために多くの決定を下すことを意味する独断的なフレームワークです。 このアプローチの利点は、開発をより迅速に開始すること、単に機能する”祝福された”統合、および使用するライブラリの代わりにプロジェクトのカス さらに、Djangoプロジェクトは非常に似ている傾向があるため、開発者は新しいプロジェクトをすばやく立ち上げ、チームは一貫して努力を整理することが
Djangoは、データベースを操作するための独自のobject-relational mapper(ORM)、認証と承認への標準的なアプローチ、自動的に生成された管理インターフェイス(ラピッドプロトタイピングに役立ちます)、統合されたキャッシュなど、箱から出して多くを提供しています。
小規模および大規模なプロジェクトに適しており、Djangoは合理的な負荷のためにうまくスケーリングすることができ、Instagram、Mozilla、Washington Postを含む多くのトラフィッ Djangoにはバージョン3.0で非同期機能があり、バージョン3.1では非同期ビューとミドルウェアが登場しています。
伝統的にフルスタックのwebアプリケーションに焦点を当てていますが、DjangoはAPI専用のバックエンドアプリケーションの開発にも適しています。 DjangoでREST ApiとGraphQL Apiの両方を迅速に構築するための成熟した統合が存在します。
結論
結論
: 事実上の標準正当な理由のために、DjangoはPythonのための支配的なフルスタックフレームワークです。 すぐに始めるのに優れ、スケーリングの実績があるDjangoは、多くのプロジェクトに最適です。 Djangoが許可する以上のカスタマイズを希望する場合は、Pyramidとmicroframeworksを検討してください。 非常に高い同時実行性が必要な場合は、非同期フレームワークを調べます。
ピラミッド
Pyramidは別の一般的なフルスタックフレームワークです。 Pylonsプロジェクトにルーツを持ち、Djangoと同じくらい開発中であり、非常に成熟したオプションでもあります。 Djangoとは対照的に、Pyramidはあまり独断的ではありません。 これは、プロジェクトをブートストラップするためのルーティング、レンダラー、およびコマンドラインツールを提供しますが、あなたのプラグインの広範なセッ
その基本的な柔軟性により、Pyramidは、フルスタックフレームワークとマイクロフレームワークのどちらかを決定しようとしている場合は、良い中間地点です。 Pyramidを使用すると、Djangoよりも小さく始めて、必要に応じてコードベースの複雑さを増やすことができます。 このようなライブラリサポートの柔軟性は、特殊な要件がある場合や、Djangoがうまく統合できないシステムと頻繁にインタフェースしている場合に重要
ピラミッドは、専用のファンベースとその成長としてあなたが行く性質と基本的な柔軟性に感謝アクティブなコミュニティを持っています。 ピラミッドと行けば、部品をupfront選ぶと余分仕事を期待しなさい。 しかし、あなたにとって重要な開発の側面を恒久的に加速することができれば、これは長期的には十分に費やされる時間になる可能性があります。結論:柔軟性と制御性の強力な組み合わせは、PyramidをいくつかのプロジェクトのためのDjangoの魅力的な代替にします。
Web2Py
web2pyは、独自のwebベースのIDE、デバッガ、および展開コントロールを備えた、開発の容易さに焦点を当てたフルスタックフレームワークです。 Ruby on RailsとDjangoに触発され、MVC(Model View Controller)の設計に従いました。
このプロジェクトは教育ツールとして始まり、賢明なデフォルトを持つ共通の機能に重点を置いています。 これは、ほとんどのフレームワークよりもはるかに簡単な学習曲線を持っており、インストールして開始することは非常に簡単です。 ドキュメントは素晴らしいですし、機能の負荷は、スケジューラ、2FAヘルパー、および自動的に生産の欠陥によって移入されます素敵な発券システムを含
web2pyはDjangoや他のフレームワークよりも小さいコミュニティですが、非常にフレンドリーなコミュニティです。 チュートリアルやリソースの多くが利用可能です。
結論
結論
: Web開発を試している新しいプログラマや開発者に最適です。 新しい大規模な商業プロジェクトのためのない大きい適合。
ターボギア
“あなたとスケールするフレームワーク”として請求され、TurboGearsを使用すると、単一のファイル(microframeworkのような)のように簡単にアプリケーションを起動したり、管理 この意味では、Pyramidに似ており、より多くの制御/カスタマイズの利点がありますが、アプリをどのように構造化し、どのライブラリを統合するかを決定すTurboGearsのデフォルトのORMは優れたSQLAlchemyです。 TurboGearsには、ルーティングの処理方法とデフォルトのテンプレートソリューションに興味深い違いがあります。 ほとんどのフルスタックフレームワークとは異なり、ルーティングは正規表現をコントローラにマッピングするのではなく、オブジェクト階層を介して処理されます(マッピングは別のオプションとして使用できます)。 TurboGearsのデフォルトのテンプレートシステムは、XSLTに触発された言語であるKajikiです。ボトムライン:TurboGearsは、小さなプロジェクトから大きなものに多くの制御でうまくスケールします。 但し、ピラミッドは柔軟性の同じような範囲を提供し、おそらくほとんどの人々のためのよりよい選択である。
マソナイト
Masoniteは、Djangoと同様の設計哲学を持つ比較的新しい(2017年)フレームワークですが、いくつかの一般的な問題点を改善することを目指しています。 これは、拡張されたコードの足場、ルーティングミドルウェア、および電子メール送信、S3アップロード、およびキューイングのためのビルトインのサポートを提供しています。
Masoniteのアーキテクチャは非常に拡張性が高く、統合された機能は印象的です。 ドキュメントは良いですし、サポートのためのアクティブなSlackチャンネルがあります。 ActiveRecordに基づく独自のORM、Oratorを使用します。
新しいフレームワークとして、Masoniteのコミュニティは小さいが成長しています。 それは積極的に改善され、好きなことがたくさんあります。 その小さなマインドシェアを考えると、それはMasoniteに精通している開発者を見つけることは困難ですが、追加のアウトオブボックスの機能があなたのニー
ボトムライン:新しい候補、Masoniteは、電子メール管理、クラウドへのファイルのアップロード、および支払い処理のような一般的なタスクを箱から出して簡
Python用のMicroframeworks
Flask
Flaskは、webアプリとマイクロサービスの両方に非常に人気のあるソリューションです。 もともとRubyフレームワークSinatraに触発されたFlaskは、コアセットの機能(要求処理、ルーティング、WSGIコンプライアンス、テンプレート)を提供することに焦点を当て、必要な
その結果、アプリケーションを起動するのは非常に簡単です。 あなたはわずか数行で動作するwebアプリケーションを構築することができます:
from flask import Flask, escape, requestapp = Flask(__name__)@app.route('/')def hello(): name = request.args.get("name", "World") return f'Hello, {escape(name)}!'
Flaskは、ストレージ、データベースの相互作用、認証と承認、セキ 選択肢の統合と設定には時間がかかりますが、アプリは段階的に構築でき、アプリケーションが使用しないもののライブラリとコードは含まれません。
Flaskアプリは通常、単一のファイルで起動しますが、非常に大きくなるように拡張することができます。 Flaskアプリを配置するための一般的なパターンがあり、flaskはより大きなアプリケーションをよりモジュール化して管理しやすくする方法としてブループリントも提供しています。 結論:非常に柔軟性があり、Flaskはユーザー向けのwebアプリ、Api、およびマイクロサービスにも適しています。 FlaskはPythonのための最も人気のあるマイクロフレームワークです。
ボトル
BottleはFlaskと同様の構文を持っています(実際には1年前になります)が、python標準ライブラリの外部に依存関係のない単一のファイルとして配布され これにより、ライブラリのインストールが困難な場所を含め、どのような環境でも簡単に実行できます。 また、依存関係の管理は些細なことであり、小規模なプロジェクトには最適です。
from bottle import route, run, template@route('/hello/<name>')def index(name): return template('<b>Hello {{name}}</b>!', name=name)run(host='localhost', port=8080)
機能セットはFlaskと非常に似ていますが、アクティブなコミュニティははるかに小さいです。 利用可能なプラグインもより制限されています。 さらに、チュートリアルが少なく、コード例やヘルプを見つけるのが難しくなる可能性があります。
Bottleは主に非常に小さなコードベースを持つアプリを対象としており、物事が複雑になるにつれてコード組織をスケーリングするための明確なパスを持 シンプルさが焦点です。 依存関係が少ないと、展開が大幅に簡素化されます(ちょうど固執しますbottle.py あなたのプロジェクトディレクトリ内)と、より迅速にプロトタイプから本番アプリにあなたを取得します。
結論
結論
: 複雑な依存関係を管理することが困難な個人的なプロジェクト、小さなアプリ、または展開シナリオに最適です。
H3:CherryPy
CherryPyは、独自のファンを持つ別の成熟したマイクロフレームワーク(2002年以降)です。 FlaskとBottleとの大きな違いの1つは、CherryPyがオブジェクト指向であり、可能な限り「pythonic」であることに焦点を当てていることです。 別の言い方をすれば、CherryPyはwebアプリを書くことを可能な限り一般的なpythonコードを書くのと同じようにすることを目指しています。 例を見てみましょう:Flaskの関数ベースのアプローチとは対照的に、アプリはクラスとして定義されていることがわかります。 また、ルーティング自体はオブジェクトベースです。`@cherrypy`デコレータは、どのオブジェクトメソッドをルートに変換する必要があるかをマークし、Flaskでデコレータはルート自体を定義します。 開発者の中には、この形式の暗黙的なルーティングを好む人もいれば、難しいと感じる人もいます。
CherryPyの強みの一つは、フレームワークにバンドルされているwebサーバーです。 これは、高速で、本番環境に対応した、HTTP/1です。1に準拠し、スレッドプールされ、任意のPython WSGIアプリケーションで使用できます。 実際、一部の開発者はCherryPyのwebサーバーを使用して他の(CherryPy以外の)WSGIアプリを実行しています。
CherryPyには、セッション管理、認証、静的コンテンツハンドラー、キャッシュ、プロファイリングなど、多くの組み込み機能も含まれています。 プラグインは、拡張ポイントの豊富なセットをタップすることが可能です。
CherryPyのコミュニティはFlaskのコミュニティよりもはるかに小さく、プラグインのコミュニティが小さく、チュートリアルが少ないなどです。
結論
結論
: あなたがオブジェクト指向の開発スタイルを好むなら、一見の価値があります。
Falcon
Falconは、REST Apiとマイクロサービスを構築するためのパフォーマンスに焦点を当てたフレームワークです。 速度に焦点を当てているため、Falconはルーティング、ミドルウェア、フック、強力なエラー/例外処理、およびWSGIヘルパーなどの限られた機能セットを提供し、単体テストを容易にします。
Falconはユーザー向けアプリに関心を持ち、RESTエンドポイントを介してJSONを提供することに焦点を当てています。 このコード例のREST動詞(GET)に注意してください:p>
import falconclass QuoteResource: def on_get(self, req, resp): """Handles GET requests""" quote = { 'quote': ( "I've always been more interested in " "the future than in the past." ), 'author': 'Grace Hopper' } resp.media = quoteapi = falcon.API()api.add_route('/quote', QuoteResource())
そのチューニングと特異焦点を考えると、Falconは根本的に高速です(20-75x!)非常に基本的な要求のベンチマークでDjangoとFlaskよりも。 Falconの他の強力な側面は、慣用的なHTTPエラー応答(Apiを構築するときの一般的な痛みのポイント)と簡単な例外処理です。 PyPy上で動作し、CPython上でCythonをサポートしています。
Falconのアイデアが好きですが、よりフル機能のソリューションが必要な場合は、バージョン管理、自動ドキュメント、型駆動の自動検証を追加するFalconの上に構築されたフレームワークであるHugを見てみましょう。結論:パフォーマンスの高いREST/JSON Apiを構築したい場合は、Falconが適している可能性があります。
pythonの非同期フレームワーク
Sanic
Sanicは比較的新しい(2016年の最初のリリース)非同期webフレームワークとサーバーであり、”高速に行くために書かれた”。
このリストにあるフルスタックとマイクロフレームワークのほとんどは十年以上前から存在していますが、Python3.5+にasyncioが追加されたことで、全く新しい世代の高性能な非同期フレームワークへの扉が開かれました。 Sanicは、この新世代で最も確立された選択肢の1つです。
Sanicの構文はFlaskとかなり似ており、エンドツーエンドの非同期サポートが追加されています。
from sanic import Sanicfrom sanic.response import jsonapp = Sanic()@app.route("/")async def test(request): return json({"hello": "world"})if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)
強力なルーティング機能、ミドルウェア、ストリーミング、WebSocketサポート、cookie管理、ルートバージョン管理、静的ファイル提供などを備えています。 Sanicは、Websocketのような長寿命の接続を処理する必要がある場合や、APIから高レベルの同時実行性が必要な場合に自然に適しています。
非同期フレームワークでは、Pythonでの非同期プログラミングについて、関連する警告、複雑さ、デバッグの課題について頭を包む必要があります。 完全な非同期APIのパフォーマンスが本当に必要かどうかを評価するのに時間を割く価値がありますが、そうすれば、Sanicは一見の価値があります!
結論
結論
: 高度にパフォーマンスの高い非同期Apiを開発するための成熟した確立されたオプション
FastAPI
FastAPIはSanic(2019年初頭の最初のリリース)よりも新しいですが、勢いが速くなっています。 RESTまたはGraphQL Apiの構築に優れており、同期要求、非同期要求、ストリーミング、websocketを処理できます。
また、認証と承認、データ検証、JSONシリアル化のサポートが組み込まれており、OpenAPI標準に従った自動APIドキュメントが機能しています。
from fastapi import FastAPIapp = FastAPI()@app.get("/")def read_root(): return {"Hello": "World"}@app.get("/items/{item_id}")def read_item(item_id: int, q: str = None): return {"item_id": item_id, "q": q}
FastAPIの機能セットは本当に印象的であり、柔軟性と開発の容易さの組み合わせでスイートスポットに当たります。 これは非常に慎重に設計されており、開発中のバグを減らすために型ヒントと依存性注入を広く活用しています。 さらに、FastAPIのドキュメントとエディタのサポートは優れています。FastAPIの構文はFlaskと非常によく似ているため、既存のFlaskコードベースを完全に非同期のソリューションに移行する場合に適しています。
結論
結論
: 上昇しているフレームワークであるFastAPIは、次の非同期プロジェクトのために探索する価値があります。
スターレット
Starletteは軽量なASGIフレームワークとツールキットであり、プリミティブとモジュール化された統合を提供し、任意の程度の制御でアプリケーションを構築
ASGIはWSGIの後継であり、非同期対応のwebサーバー、フレームワーク、およびアプリケーション間の標準インターフェイスを提供します。 ASGIは同期操作と非同期操作の両方をサポートし、ASGIにはWSGI下位互換性の実装が含まれていることに注意してください。
フレームワークとして、StarletteはWebSocketサポート、GraphQLサポート、インプロセスバックグラウンドタスク、セッションとcookieのサポート、CORS、GZip、静的ファイルなど、さまざまな機能 また、ツールキットの特定の部分を選んで選択し、個別に各部分を使用することができます。
Starletteは最初のツールキットであるため、フレームワークとしての使用は、別々に公開された懸念で、より構成的に感じることができます。
from starlette.applications import Starlettefrom starlette.responses import JSONResponsefrom starlette.routing import Routeasync def homepage(request): return JSONResponse({'hello': 'world'})app = Starlette(debug=True, routes=)
FastAPIは実際にStarletteの上に構築され、構文の利便性と追加機能を追加しています。 ほとんどのチームにとって、Fastapiはおそらく始めるのに適した場所ですが、Starletteは最大の制御と強力なプリミティブセットを提供します。ボトムライン:あなた自身の非同期ツールで金属の近くで作業したい場合は、Starletteは始めるのに最適な場所です。
Tornadoは、asyncio機能がPythonに組み込まれる前に作成された、古い非同期webフレームワークです。 もともとFriendFeedによって作成され、2009年に最初にリリースされたTornadoは、Pythonで何万ものオープン接続にスケーリングするための実証済みのソリューションです。
Tornadoのコアは、強力な基盤となるネットワークライブラリを持つ高度にカスタマイズ可能なアプリケーシ これは、ルーティング、テンプレート、セッションとクッキーの管理、ネイティブWebSocketのサポート、セキュリティ機能が含まれており、異なるデータストアのためのオプ これはDjangoのようなものよりもフル機能ではありませんが、典型的なmicroframeworkよりも多くの機能が組み込まれています。 Tornadoは、要求ハンドラクラスに動詞スタイルのメソッドを使用するため、よりオブジェクト指向の開発スタイルに適しています:
import tornado.ioloopimport tornado.webclass MainHandler(tornado.web.RequestHandler): def get(self): self.write("Hello, world")def make_app(): return tornado.web.Application()if __name__ == "__main__": app = make_app() app.listen(8888) tornado.ioloop.IOLoop.current().start()
トルネードは、堅牢なコミュニティで、積極的に改善され、維持され続けています。 これは、facebook、Quora、および他の人が生産アーキテクチャで使用しています。 Tornado6+は内部でasyncioを使用し、Python3.5+を必要としますが、Tornado5はPython2.7以降で使用できます。 Python3.5以降で実行されているTornado非同期コルーチンは、ネイティブの`async’/’await`構文を使用します。 以前のバージョンでは、Tornadoは同様の機能を持つジェネレータ構文を提供しています。 特に、TornadoにはTwistedの成熟したブリッジがあり、Tornadoの上にTwistedアプリとライブラリの両方を実行することができます。
結論:大量の同時リクエストにスケーリングするための実績のある解決策、Tornadoは、強力なコミュニティで確立されたオプションが必要な場合、古いコー
どのPython webフレームワークが最適ですか?このリストから明らかなように、多くの良いオプションがあります。 実際、Pythonには他にも多くのフレームワークがあります-この記事では、2020年に検討する価値があると考えられるフレームワークだけに意図的に制限しました。開始するには良い場所は、我々はこの記事の冒頭で述べた基準です。
開始するには良い場所は、我々はこの記事の冒頭で述べた基準です。
あなたの目標は何ですか? あなたは、新しい何かを試して実証済みの技術で迅速に何かを構築したり、新しいスキルを学ぶために探していますか? どのように多くの人々があなたのコードベースで動作し、どのくらいの時間が周りになりますか? これらはすべて正しい選択に関する有用な手がかりです。
誰にとっても完璧なフレームワークはありませんが、ここではいくつかの一般的な提案があります。
- リソースを見つけやすい十分に確立されたソリサニック
- あなたが初心者のプログラマであるか、単にweb開発を行うことを学んでいる場合、web2pyまたはBottleはフレンドリーで簡単な方法で始めることができます
- 新しいアイデアややり方で最新のフレームワークを探索したい場合は、MasoniteとFastAPIをチェックしてください
この記事が役に立つか、あなたが同意しないか、改善すべきだと思うものを見ましたか。 私達に知らせてください、私たちはあなたのフィードバックを大切に!