4

誰かがピザ サーバーにピザのリストを問い合わせたいと考えているとします。この個人は単純に

 GET /pizzas
 ;=> ["cheese", "extra cheese", "broccoli"]

pedestal -appのデータ モデルとメッセージでは、クライアント サーバー通信をどのように設計すればよいかわかりません。数分間のハンモックがもたらした可能性は次のとおりです。

  1. 効果消費者
    • メッセージを HTTP リクエストに変換します
    • [{:type :add :topic [:pizzas] :value "cheese"} ...]結果を (例えば に)変換します
    • メッセージをキューに入れる
  2. サーバー上の専用リソース( 「/edn」など) 。
    • 台座メッセージを受け入れます
    • 正しい関数にディスパッチする
    • 生データで応答します（つまり、[「チーズ」、「エクストラチーズ」、「ブロッコリー」]）
    • effect-consumer 変換で結果をメッセージに戻す
  3. ルートを使用する専用リソース。#2と同じですが、
    • リクエストの変更
    • ルートテーブルの別のエントリに転送する
  4. 両面にメッセージ、
    • メッセージを関数呼び出しに変換するサーバー
    • 結果をメッセージに戻すサーバー
    • これらのメッセージをキューに追加するクライアント

アプローチ #2 と #4 を使用すると、インターセプターのすべての利点をバイパスして失うように思えます。アプローチ 2 では、ルーティング ロジックを 2 倍にする必要があります。アプローチ #4 では、ペデスタル クライアントに対応するために大量のコードも生成する必要があります。

オプション #1 と #3 の方が優れているように見えますが、#3 はハックの匂いがし、#1 は方向性が間違っています。

どうやってやってるの？

ありがとう！

4

1 に答える 1

0

台座については知りませんが、リング/コンポジュールなどで働いています。

ring.middleware.jsonリングを使用すると、 使用したり、ページを配置ring.middleware.json/wrap-json-responseしたり、ページを簡単にラップしたりできring.middleware.json/wrap-json-paramsます。次に、受信 json データがパラメーターに解析され、json を次のように返すことができます。

(ring.util.response/response ["cheese", "extra cheese", "broccoli"])

ライブラリがこれらの種類の動作をサポートしていない場合は、リングなどから関連するコードを抽出できる可能性があります。

于 2013-12-06T01:39:40.110 に答える