Кэшируйте ответ API Github для поиска / репозиториев - PullRequest
Новая
       33

Кэшируйте ответ API Github для поиска / репозиториев

0 голосов
/ 19 марта 2019

Я хочу написать веб-приложение в рельсах для поиска в репозиториях Github.Поскольку существуют ограничения для запросов к Github API, я думаю, что это хорошая идея для кэширования ответа.Эта конечная точка search/repositories?q=search_term возвращает результаты в разбивке на страницы.Итак, я не уверен, как сделать кэширование в этом случае?

1 Ответ

0 голосов
/ 19 марта 2019

Существует много способов объединить нумерацию страниц в кеше, но все они требуют новых запросов к каждой странице в нумерации страниц.

Итак, пусть правит пользовательская интуиция. Если пользователю нужна следующая страница, дайте ему возможность нажать кнопку «следующая страница» и перейти по заголовку ссылки, предоставленному Github. Как это будет выглядеть в вашем кэше? Поскольку они предоставляют удобный параметр page=2 в конце URL-адреса, почему бы вам просто не использовать URL-адреса, запрашиваемые пользователем в качестве ключа, а значение - это ответ. 

url = "api.github.com/search/resource?q=name:cool+name"
if(get(url)) return get(url)

response = get(url)
set(url, response)
return response

Если пользователь нажимает «следующая страница», вы должны сделать этот запрос: 

url = "api.github.com/search/resource?q=name:cool+name&page=2"
if(get(url)) return get(url)

response = get(url)
set(url, response)
return response

Но видите, как процесс не меняется? Если он в кеше, отправь. Если это не так, не надо.

Почему мы не хотим рекурсивно кэшировать все страницы? Потому что люди знают лучше. Компьютеры с удовольствием кешируют 1 000 000 ответов на каждый запрос. Но что, если 99,99% людей просто ищут ответ первой страницы? Зачем тратить все это пространство? Таким образом, с нумерацией страниц всегда проще позволить людям выбирать, нужно ли им больше данных. Не пытайтесь предварительно кэшировать данные, которые могут никогда не быть использованы.

...