巨大化(Becoming Big) Becoming Big

この章は、自分のコード基盤が大きくなっているときや、自分のアプリケーションの規模を大きくしたいときの選択肢を説明します。 Here are your options when growing your codebase or scaling your application.

ソースの読み込み Read the Source.

Flaskは既存のよく使われているツールであるWerkzeug(WSGI)とJinja(テンプレート)の上に自分独自のフレームワークをどのように構築するかのデモの一部として始まり、開発されていくにつれ、幅広い人々にとって便利なものになって行きました。自分のコード基盤を成長させるとき、Flaskをただ使うだけではなく、理解してください。ソースを読み込んでください。Flaskのコードは読み込みできるように書かれています。内部APIを自分で使用できるように、ドキュメントは公開されています。Flaskは、上流ライブラリの文書化されたAPIから外れないようにしており、あなたのプロジェクトで必要になるフックになる点を探し出せるように、Flask内部のユーティリティは文書化しています。 Flask started in part to demonstrate how to build your own framework on top of existing well-used tools Werkzeug (WSGI) and Jinja (templating), and as it developed, it became useful to a wide audience. As you grow your codebase, don't just use Flask -- understand it. Read the source. Flask's code is written to be read; its documentation is published so you can use its internal APIs. Flask sticks to documented APIs in upstream libraries, and documents its internal utilities so that you can find the hook points needed for your project.

フック。Flask拡張。 Hook. Extend.

API文書には、オーバーライド、フックできる点、そして合図(Signals)がたくさんあります。requestやresponseオブジェクトのようなものに対する独自のクラスは自分で提供可能です。自分が使うAPIを掘り下げて、Flaskのリリースの中で用意されている利用可能なカスタマイズ方法を探してください。Flask拡張やユーティリティの集合へと自分のプロジェクトを再構成できるやり方を探してください。コミュニティにある多くのFlask拡張(Extensions)を探索して、もし自分が必要とするツールを探し出せない場合は自分独自のFlask拡張を構築するパターンを探してください。 The :ref:`api` docs are full of available overrides, hook points, and :ref:`signals`. You can provide custom classes for things like the request and response objects. Dig deeper on the APIs you use, and look for the customizations which are available out of the box in a Flask release. Look for ways in which your project can be refactored into a collection of utilities and Flask extensions. Explore the many :doc:`/extensions` in the community, and look for patterns to build your own extensions if you do not find the tools you need.

サブクラス Subclass.

Flaskクラスは、サブクラス用に設計された多くのメソッドを持ちます。Flaskをサブクラス化して振舞を素早く追加またはカスタマイズでき(リンク先のメソッドのドキュメントを調べてください)、アプリケーションのクラスをインスタンス化するところではどこでもそのサブクラスを使用できます。これはアプリケーション製造工場(Application Factories)を使っても問題なく機能します。例はFlaskのサブクラス化を調べてください。 The :class:`~flask.Flask` class has many methods designed for subclassing. You can quickly add or customize behavior by subclassing :class:`~flask.Flask` (see the linked method docs) and using that subclass wherever you instantiate an application class. This works well with :ref:`app-factories`. See :doc:`/patterns/subclassing` for an example.

ミドルウェアを使った包み込み(Wrap with middleware) Wrap with middleware.

アプリケーションの振り分け(Application Dispatching)章は、ミドルウェアをどのように適用するかの詳細を示します。自分のFlaskインスタンスを包み込むWSGIミドルウェアを導入して、自分のアプリケーションとHTTPサーバの間の階層で修正や変更を導入することが可能です。Werkzeugはいくつかのミドルウェアを含んでいます。 The :ref:`app-dispatch` chapter shows in detail how to apply middleware. You can introduce WSGI middleware to wrap your Flask instances and introduce fixes and changes at the layer between your Flask application and your HTTP server. Werkzeug includes several `middlewares <https://werkzeug.palletsprojects.com/middleware/>`_.

フォーク Fork.

上記の選択肢がどれも機能しない場合、Flaskをフォークしてください。Flaskのコードの大部分はWerkzeugとJinja2内にあります。これらのライブラリは仕事の大部分を担います。Flaskはこれらを一緒にくっつける糊になるだけです。すべてのプロジェクトにおいて、下支えしているフレームワークが(フレームワークの開発者が持つ仮定のために)妨げになる点があります。Flaskは該当しないかもしれませんが、フレームワークは始めるにはとても複雑なシステムで、険しい学習曲線と多くのユーザのフラストレーションを引き起こす場合があるため、これは自然なことです。 If none of the above options work, fork Flask. The majority of code of Flask is within Werkzeug and Jinja2. These libraries do the majority of the work. Flask is just the paste that glues those together. For every project there is the point where the underlying framework gets in the way (due to assumptions the original developers had). This is natural because if this would not be the case, the framework would be a very complex system to begin with which causes a steep learning curve and a lot of user frustration.

これはFlaskに固有なことではありません。欠点に対抗するために、多くの人がパッチを当て変更を加えたバージョンのFlaskを使用します。この考えはFlaskのライセンスにも反映されています。もしこのフレームワークに手を加える決定をしても、どの変更もFlaskへ戻して貢献するように課せられることはありません。 This is not unique to Flask. Many people use patched and modified versions of their framework to counter shortcomings. This idea is also reflected in the license of Flask. You don't have to contribute any changes back if you decide to modify the framework.

フォークすることのマイナス面は、その新しいフレームワークは異なるimport名を持つため、当然Flask拡張は壊れる可能性が非常に高いことです。さらに、フォーク元の変更の統合は、変更の数によっては複雑なプロセスになる可能性があります。この理由から、フォークは最後の手段とするべきです。 The downside of forking is of course that Flask extensions will most likely break because the new framework has a different import name. Furthermore integrating upstream changes can be a complex process, depending on the number of changes. Because of that, forking should be the very last resort.

プロのような規模変更(Scale like a pro) Scale like a pro.

多くのwebアプリケーションにとって、想定されるデータ入力やユーザの数の規模変更(scaling)に比べれば、コードの複雑さはより小さな問題です。Flask自身はscalingの意味では、アプリケーションのコード、使用したいデータストア、Pythonの実装およびその上で走らせるwebサーバによってのみ制限されます。 For many web applications the complexity of the code is less an issue than the scaling for the number of users or data entries expected. Flask by itself is only limited in terms of scaling by your application code, the data store you want to use and the Python implementation and webserver you are running on.

うまくscalingできるということは、例えば、もしサーバ数を2倍にすれば2倍の性能を得られるということです。うまくscalingできないということは、もし新しいサーバを追加しても、アプリケーションは性能が向上しない、もしくは第二のサーバのサポート自体されないということです。 Scaling well means for example that if you double the amount of servers you get about twice the performance. Scaling bad means that if you add a new server the application won't perform any better or would not even support a second server.

scalingに関して制限するFlaskの中の唯一の要因は、context localのproxyです。context localのproxyは、Flaskの中ではスレッド、プロセス、もしくはgreenletのいずれかとして定義される状況(context)に依存します。もし自分のサーバがスレッドもしくはgreenletを土台とはしない何らかの並列処理を使用している場合、Flaskは(context localの範囲内での)グローバルなproxyをサポートしなくなります。しかしながら、大部分のサーバはスレッド、greenlet、もしくは分離したプロセスのいずれかを使用して並列処理を達成しており、それらはすべてFlaskを下支えするWerkzeugライブラリでうまくサポートされています。 There is only one limiting factor regarding scaling in Flask which are the context local proxies. They depend on context which in Flask is defined as being either a thread, process or greenlet. If your server uses some kind of concurrency that is not based on threads or greenlets, Flask will no longer be able to support these global proxies. However the majority of servers are using either threads, greenlets or separate processes to achieve concurrency which are all methods well supported by the underlying Werkzeug library.

コミュニティを使った議論 Discuss with the community.

Flask開発者はユーザのコード基盤の大小にかかわらずフレームワークを利用できるように保っています。もし自分のやることに対して、Flaskによって引き起こされた障害が見つかった場合、メーリングリストまたはDiscordサーバで遠慮なく開発者に連絡してください。FlaskおよびFlask拡張の開発者が大きなアプリケーション向けにツールを改善する最良の方法は、ユーザからフィードバックを得ることです。 The Flask developers keep the framework accessible to users with codebases big and small. If you find an obstacle in your way, caused by Flask, don't hesitate to contact the developers on the mailing list or Discord server. The best way for the Flask and Flask extension developers to improve the tools for larger applications is getting feedback from users.