32

計算を実行してグラフを生成する小さな Web インターフェイスのロング ポーリングを行う簡単な (つまり、メッセージング キューを処理するために別のサーバーをセットアップする必要がない) 方法を探しています。これは、私の Web インターフェイスが行う必要があることです。

  1. ユーザーが Web インターフェイスでグラフ/データを要求する
  2. サーバーはいくつかの計算を実行します。
  3. サーバーが計算を実行している間、計算の進行状況に応じて小さなコンテナーが更新されます (おそらく AJAX/jQuery を介して) (コンソールで print を使用して行うことと同様です (つまり、print 'calculating density function...'))。
  4. 計算が終了し、グラフがユーザーに表示されます。

計算はすべてサーバー側で行われるため、これを簡単に設定する方法がよくわかりません。明らかに、ポーリングを処理するために REST API をセットアップしたいと思うでしょう。Flask では簡単です。ただし、実際の更新を取得する方法がわかりません。この目的のためには複雑ではありますが、明らかな解決策は、メッセージング キューをセットアップし、長いポーリングを実行することです。ただし、これがこの単純なものに対する正しいアプローチであるかどうかはわかりません。

ここに私の質問があります：

  1. ファイルシステムを使用してこれを行う方法はありますか? パフォーマンスは大きな問題ではありません。AJAX/jQuery はファイルからメッセージを見つけることができますか? 進行状況を .json ファイルに保存しますか?
  2. ピクルスはどうですか？(私はピクルについてあまり知りませんが、おそらくメッセージ dict をピクルすることができ、ポーリングを処理している API によって読み取られる可能性があります)。
  3. ポーリングは正しいアプローチですか? これを処理するためのより良い、またはより一般的なパターンはありますか?

この種のことがウェブ上で一般的であることを知っているので、私は物事を複雑にしすぎていると感じています. 計算が行われている間 (たとえば、Google Analytics で)、何かが起こっていて、小さな "loading.gif" 画像が実行されているのをよく見かけます。

ご協力いただきありがとうございます！

4

2 に答える 2

47

Flask と jQuery だけを使用して、このようなアプリをいくつか作成しました。その経験に基づいて、あなたの計画は良いと思います。

  1. ファイルシステムを使用しないでください。JavaScript のセキュリティの問題/保護に遭遇します。万一、合理的な回避策が見つかったとしても、移植可能または拡張可能なものは何もありません。代わりに、Flask などの小さなローカル Web サービス フレームワークを使用してください。

  2. ピクルスにしないでください。JSON を使用します。Web アプリと REST インターフェイスの言語です。jQuery と、チャートやグラフなどを描画するための優れた jQuery ベースのプラグインは、JSON を想定しています。使いやすく、人が読める形式であり、小規模なアプリの場合、他の場所に行く理由はありません。

  3. ロングポーリングは、達成したいことには問題ありません。純粋な HTTP ベースのアプリにはいくつかの制限があります。そして、WebSockets や Socket.IO のような同様のソケットっぽいレイヤーは「未来」です。しかし、私の経験では、サーバー側の実装の良い単純な例を見つけるのは困難でした。じっと見てきました。Node.js、REDIS、およびその他のミドルウェアをセットアップする例がたくさんあります。しかし、なぜ 2 つまたは 3 つの別個のミドルウェア サーバーをセットアップする必要があるのでしょうか。ばかげている。そのため、Flask のような単純な純粋な Python Web フレームワークでのロング ポーリングは、IMO への道です。

コードはスニペットにすぎないので、ここに含めるのではなく、簡単な例をbitbucket の Mercurial リポジトリに入れました。自由に確認、コピー、または複製できます。次の 3 つの部分があります。

  • serve.pyPython/Flask ベースのサーバー
  • templates/index.htmlFlask ベースのサーバーが HTML としてレンダリングする 98% の HTML、2% のテンプレート ファイル
  • static/lpoll.jsjQuery ベースのクライアント
于 2012-06-22T18:13:30.450 に答える
14

ロングポーリングは、Web Sockets のシンプルで自然なサポートがほとんどのブラウザーに導入される前、および Flask アプリと簡単に統合される前の合理的な回避策でした。しかし、ここ 2013 年半ばには、Web ソケットのサポートは大きく前進しました。

上記の例に似ていますが、Flask と Web ソケットを統合した例を次に示します。geventおよびgevent-websocketのサーバー コンポーネント上で実行されます。

この例は、Web ソケットの傑作を意図したものではないことに注意してください。lpollより簡単に比較できるように、多くの構造が保持されています。しかし、Web アプリの応答性、サーバーのオーバーヘッド、および対話性がすぐに向上します。

Python 3.7+ の更新

最初の回答から 5 年が経過し、WebSocket の実装が容易になりました。Python 3.7 の時点で、非同期操作は主流の有用性に成熟しました。Python Web アプリは完璧なユース ケースです。JavaScript や Node.js と同じように async を使用できるようになり、"副次的な同時実行" の癖と複雑さの一部を残しています。特に、 Quartをチェックしてください。Flask の API と多くの Flask 拡張機能との互換性を保持していますが、非同期対応です。主な副作用は、WebSocket 接続を HTTP 接続と並行して適切に処理できることです。例えば：

from quart import Quart, websocket

app = Quart(__name__)

@app.route('/')
async def hello():
    return 'hello'

@app.websocket('/ws')
async def ws():
    while True:
        await websocket.send('hello')

app.run()

Quart は、Python 3.7 にアップグレードする多くの大きな理由の 1 つにすぎません。

于 2013-08-07T01:36:27.493 に答える