3

モバイル Android / iPhone アプリで GooglePlaces を使用して、近くの店舗をダウンロードしています。さらに、データベースには、ユーザーに表示したいストアがあります。

現在、モバイル アプリが位置を取得するとすぐに、GooglePlaces に対して 1 つとサーバーに対して 1 つの 2 つの http リクエストを発行します。両方のリクエストが完了するとすぐに、アプリは結合されたリストを作成し、それをユーザーに表示します。両方のリクエストで合計約 50 Kb です。

サーバーへのリクエストを1つだけ行うことを考えています。次に、独自のサーバーが GooglePlaces へのリクエストを行い、2 つのリストを結合して、両方をモバイル クライアントに送り返します。利点は、モバイル アプリが 1 つのリクエストを発行するだけでよいことですが、サーバーが googleplaces に接続するときに追加のレイテンシが発生する可能性があります。

2 番目のオプションのテストには、おそらく丸 1 日かかります。他の誰かが同様の問題に遭遇しましたか? あなたは何をお勧めします？

4

1 に答える 1

3

これはトレードオフですが、同様の問題がありました。アプリは独立したリクエスト (googleplaces ではなく、他の API に対して) を作成し、最終的に単一のリクエスト モデルに変換しました。私たちにとっての利点は、アプリのリクエスト数を減らすことだけではありませんでした。

  1. 変更を余儀なくされた最大の要因は、使用していた API が比較的短期間で変更をデプロイしたことです。これにより、コードを変更してアプリを再デプロイする必要がありました。それでも、アプリが意図したとおりに動作しなくなった理由を疑問に思って、更新せずにサポート リクエストを送信したものもありました。単一要求モデルでは、これらの更新 (および関連するサポートの問題) を回避できます。アップストリーム データ プロバイダーが API で変更されると、サーバー上で内部形式への変換が処理されます。
  2. 1) に関連して、アプリを更新せずに追加のデータ ソースを組み込むことができました。既存のモデルに適合する新しいデータ ソースを見つけたら、アプリを更新せずにそれらを展開できます。

  3. リクエストの一部をサーバーにキャッシュできます。リクエストがローカルすぎる可能性があり、TOS でキャッシュが許可されているかどうかを確認する必要がありますが、結果をキャッシュすることでレイテンシの一部を軽減することができました。また、API の停止中にグレースフル デグレードすることも可能になりました。

  4. デバイスに送信する前に、データを最適化することができました。サーバー上のアプリで使用されていないことがわかっているデータ要素を除外し、xml を最適化して、ダウンロード サイズが 20% ～ 30% 減少するようにします。

于 2012-12-21T16:24:42.473 に答える