現在、従来のリクエスト/レスポンススタイル（クライアントはモバイルアプリケーション）で動作するFlaskを使用したAPIを開発しました。このAPIは、リモートサーバー上のApacheを使用してホストされます。私たちがしたいのは、（チャットアプリのように）サーバーとクライアントの間のリアルタイム接続を統合することです。これは私が立ち往生したところです。私はここでフレームワークの選択をする必要があります。 TornadoをFlaskで使用するのは良い選択ではありません。なぜなら、Tornadoは非ブロックでFlaskがブロックしているからです。この場合、何が最良の選択でしょうか？フラスコAPIのリアルタイム接続を統合するための最良の選択肢は何でしょうか？
今日のWebアプリケーションのリアルタイム機能を提供するデフォルトのソリューションは、Webソケット（Google Flask + Websocketをご利用ください）です。同時実行性が問題である場合（つまり、多くの永続的な同時接続）、WebSocketを処理するソフトウェアの「チェーン」は非ブロッキングでなければなりません。フラスコはgevent（Pythonのstdlibの非ブロックモンキーパッチ）をサポートしていますので、フラスコを使用し続けることができますが、常にnon-blockingなので、リバースプロキシとしてnginxを使用する方が良いでしょう。たとえば、nginx + gevent +フラスコは非ブロック設定を提供します。
個人的には、私はトルネードが大好きですが、すでにFlaskで長い道のりを歩いていれば、あなたのアプリケーションに別のフレームワークを導入することには消極的です。
ここでは 'Celery'を使うのがいいでしょうか？つまり、接続のためにエンドポイントを公開することができ、リクエストごとに 'Celery'タスクを呼び出すことができます。たとえば、メッセージを送信する場合は、そのためのタスクがあり、プッシュ通知を使用してメッセージを配信できますか？ – MrPyCharm
Celeryは、通常はWebアプリケーションの外部で実行される非同期タスクプロセッサです。したがって、別々のタスクプロセスを採用することが合理的であれば、リアルタイムユースケースの種類（たとえば、同時実行性、IO帯域幅、CPUスループットなど）によって異なります。 –
間違ったアイデアかもしれませんが、 "あなた自身で書き込みをしてください！"、あなたはリアルタイムで考えています。決してpython 'network-module'は' socket'より高速です！ – dsgdfg
あなたは 'socket'を使うべきですか？最初から書き込むべきですか？私はあなたのコメントを正しく理解できませんでした。 – MrPyCharm
はい、新しいものを書いてください！ほとんどのアプリケーション情報は、「最小、高速、安全」、「最小」が重要な理由は何ですか？ 「高速RAM（DDR3）のためのメインボードを購入する」というよりSDRAMより速く決めるのではなく、「技術」は何かを間違った選択にしている。 – dsgdfg