大きくなる
コードベースを拡張するとき、またはアプリケーションをスケーリングするときのオプションは次のとおりです。
ソースを読んでください。
Flaskは、既存のよく使用されるツールであるWerkzeug（WSGI）とJinja（テンプレート）の上に独自のフレームワークを構築する方法を示すために部分的に開始され、開発されるにつれて、幅広いユーザーに役立つようになりました。 コードベースを拡張するときは、Flaskを使用するだけでなく、理解してください。 ソースを読んでください。 Flaskのコードは読むために書かれています。 そのドキュメントは公開されているため、内部APIを使用できます。 Flaskは、アップストリームライブラリのドキュメント化されたAPIに固執し、プロジェクトに必要なフックポイントを見つけることができるように、その内部ユーティリティをドキュメント化します。
針。 拡張する。
API ドキュメントには、利用可能なオーバーライド、フックポイント、およびシグナルが満載です。 リクエストオブジェクトやレスポンスオブジェクトなどのカスタムクラスを提供できます。 使用するAPIをさらに深く掘り下げ、Flaskリリースですぐに利用できるカスタマイズを探します。 プロジェクトをユーティリティとFlask拡張機能のコレクションにリファクタリングできる方法を探してください。 コミュニティ内の多くの拡張機能を探索し、必要なツールが見つからない場合は、独自の拡張機能を構築するためのパターンを探してください。
サブクラス。
Flaskクラスには、サブクラス化用に設計された多くのメソッドがあります。 Flaskをサブクラス化し（リンクされたメソッドのドキュメントを参照）、アプリケーションクラスをインスタンス化する場所でそのサブクラスを使用することにより、動作をすばやく追加またはカスタマイズできます。 これは、アプリケーションファクトリでうまく機能します。 例については、サブクラス化フラスコを参照してください。
ミドルウェアで包みます。
Application Dispatching の章では、ミドルウェアを適用する方法について詳しく説明しています。 WSGIミドルウェアを導入してFlaskインスタンスをラップし、FlaskアプリケーションとHTTPサーバーの間のレイヤーに修正と変更を導入できます。 Werkzeugには、いくつかのミドルウェアが含まれています。
フォーク。
上記のオプションのいずれも機能しない場合は、Flaskをフォークします。 Flaskのコードの大部分は、WerkzeugとJinja2内にあります。 これらのライブラリが作業の大部分を実行します。 フラスコはそれらを接着する単なるペーストです。 すべてのプロジェクトについて、基礎となるフレームワークが邪魔になるポイントがあります（元の開発者が持っていた仮定のため）。 これが当てはまらない場合、フレームワークは最初は非常に複雑なシステムになり、学習曲線が急になり、ユーザーのフラストレーションが大きくなるため、これは当然のことです。
これはFlaskに固有のものではありません。 多くの人々は、欠点に対処するために、フレームワークのパッチを適用して変更したバージョンを使用しています。 このアイデアは、Flaskのライセンスにも反映されています。 フレームワークを変更することにした場合、変更を元に戻す必要はありません。
もちろん、フォークの欠点は、新しいフレームワークのインポート名が異なるため、Flask拡張機能が機能しなくなる可能性が高いことです。 さらに、アップストリームの変更を統合することは、変更の数によっては複雑なプロセスになる可能性があります。 そのため、フォークは最後の手段になるはずです。
プロのようにスケーリングします。
多くのWebアプリケーションでは、コードの複雑さは、予想されるユーザー数やデータエントリのスケーリングよりも問題ではありません。 Flask自体は、アプリケーションコード、使用するデータストア、および実行しているPython実装とWebサーバーによるスケーリングに関してのみ制限されます。
適切なスケーリングとは、たとえば、サーバーの数を2倍にすると、パフォーマンスが約2倍になることを意味します。 スケーリングが悪いということは、新しいサーバーを追加した場合、アプリケーションのパフォーマンスが向上しないか、2番目のサーバーをサポートしないことを意味します。
コンテキストローカルプロキシであるFlaskのスケーリングに関する制限要因は1つだけです。 それらは、Flaskでスレッド、プロセス、またはグリーンレットのいずれかとして定義されているコンテキストに依存します。 サーバーがスレッドやグリーンレットに基づかないある種の同時実行性を使用している場合、Flaskはこれらのグローバルプロキシをサポートできなくなります。 ただし、サーバーの大部分は、スレッド、グリーンレット、または個別のプロセスのいずれかを使用して並行性を実現しています。これらはすべて、基盤となるWerkzeugライブラリで十分にサポートされているメソッドです。
コミュニティと話し合います。
Flask開発者は、大小のコードベースを持つユーザーがフレームワークにアクセスできるようにします。 Flaskが原因で障害が発生した場合は、メーリングリストまたはDiscordサーバーの開発者に遠慮なく連絡してください。 FlaskおよびFlask拡張機能の開発者が大規模なアプリケーションのツールを改善するための最良の方法は、ユーザーからのフィードバックを取得することです。
