Предложение по созданию прокси API через API автозаполнения Google Адресов - PullRequest
0 голосов
/ 10 ноября 2018

Я разработчик мобильных приложений и начал использовать API Google Place для предложения автозаполнения, чтобы найти места в моем приложении. Но я заметил, что Google Places API становится дорогостоящим при масштабировании. Итак, я сделал некоторую оптимизацию на мобильной стороне следующим образом: -

  1. Ограничить автозаполнение не менее 3 символов
  2. Пороговым значением для вызова API для автозаполнения является разница в 500 миллисекунд между двумя набранными символами
  3. Выполнить локальное кэширование результатов с помощью механизма LRU

Со всей этой оптимизацией клиентская сторона хороша. Но теперь я также думаю оптимизировать и со стороны API бэкенда. Для этой оптимизации я создам оболочку для автозаполнения API google мест с кэшированием на стороне сервера. В соответствии с Руководством Google этот период кэширования будет иметь продолжительность 30 дней.

Мне нужна помощь, чтобы понять, как я могу спроектировать это? Например, какая комбинация клавиш и значений мне нужна для хранения предложений автозаполнения? Должен ли я использовать Redis или Hazelcast? Я пишу свой Backend на Java с сервером aws, используя архитектуру микро-сервисов. Любое уже реализованное решение, где я могу изучить и изучить.

Пожалуйста, помогите, поскольку я новичок в разработке Backend.

1 Ответ

0 голосов
/ 10 ноября 2018

Прежде чем идти по этому пути, провели ли вы анализ затрат, чтобы выяснить, стоит ли это того? Имейте в виду, что теперь это код, который вам нужно поддерживать, а облачная инфраструктура требует некоторого ухода и поддержки. т. е. в своем анализе цен не забывайте учитывать свое время для расчета затрат. Это все еще финансово стоит?

Не зная объема ваших транзакций, похоже, что вы провели немало бесплатной оптимизации на стороне клиента. Если вы добавите оптимизацию на стороне сервера, вы фактически добавите вызов из облака в облако и увеличите время ожидания для различных используемых вами сервисов AWS. Вы в порядке, принимая удар производительности?

Если вы все еще считаете, что это стоит того, я бы порекомендовал путь по безсерверному маршруту, используя API Gateway -> Lambda -> DynamoDB. Это сохранит ваши расходы относительно низкими, поскольку у Lambda довольно щедрый бесплатный уровень. Если вам нужна более высокая производительность, вы всегда можете вставить Redis через Elasticache в стек позже.

Что касается того, что вам нужно сохранить, вы, вероятно, захотите кэшировать различные входные данные, которые вводит пользователь, вместе с информацией, возвращаемой из API мест. Например, вы, вероятно, захотите захватить строку поиска, информацию о местоположении, а затем любое из полей, которые вы хотите (например, place_id, icon, creation_hours и т. Д.); в основном то, что вы используете сегодня. Это будет очень похоже на ваш кэш LRU.

...