如何在Rails应用中缓存Github API的search/repositories分页响应？

嘿，这个问题我之前帮不少开发者解决过，用Rails处理Github分页API的缓存其实思路很清晰，我给你拆解下具体方案：

因为Github的search/repositories接口返回的分页结果是和搜索词、页码强绑定的——同一个关键词的第1页和第2页数据完全独立，不同关键词的同页码数据也毫无关联。所以我们的缓存策略必须把这两个维度都包含进去，才能精准命中对应分页的缓存数据。

1. 设计合理的缓存键 #

为了避免搜索词里的特殊字符（比如空格、符号）破坏缓存键格式，建议用CGI.escape对搜索词做转义，再拼接页码。示例缓存键格式：

"github_repos/#{CGI.escape(search_term)}/page/#{page}"

如果以后API响应格式有变动，还可以给缓存键加个版本号（比如"v1/github_repos/..."），这样更新版本后旧缓存会自动失效，不用手动清理。

2. 用Rails缓存包裹API调用 #

Rails自带的Rails.cache.fetch方法完美适配这个场景——它会先检查缓存里有没有对应键的数据，有就直接返回；没有就执行块里的API请求，然后把结果存入缓存。示例代码：

def fetch_github_repos(search_term, page = 1)
  cache_key = "github_repos/#{CGI.escape(search_term)}/page/#{page}"
  # 设置1小时过期，平衡数据新鲜度和API调用次数
  Rails.cache.fetch(cache_key, expires_in: 1.hour) do
    # 用Faraday发送API请求（也可以用Octokit gem更便捷）
    response = Faraday.get("https://api.github.com/search/repositories") do |req|
      req.params['q'] = search_term
      req.params['page'] = page
      req.params['per_page'] = 30 # 自定义每页展示数量，最多100
      # 一定要加Github Token！无token只有60次/小时限额，有token能到5000次
      req.headers['Authorization'] = "token #{ENV['GITHUB_TOKEN']}"
    end

    # 只有请求成功时才返回解析后的JSON
    response.success? ? JSON.parse(response.body) : nil
  end
end

3. 缓存分页元数据 #

Github API的响应头里包含了关键的分页信息：

• X-Total-Count：总结果数
• Link：包含下一页、上一页、最后一页的链接

这些元数据也应该单独缓存，不然每次分页都要调用API拿头信息，浪费限额。示例：

def fetch_github_repos_metadata(search_term)
  cache_key = "github_repos/#{CGI.escape(search_term)}/metadata"
  Rails.cache.fetch(cache_key, expires_in: 1.hour) do
    response = Faraday.head("https://api.github.com/search/repositories") do |req|
      req.params['q'] = search_term
      req.headers['Authorization'] = "token #{ENV['GITHUB_TOKEN']}"
    end

    if response.success?
      {
        total_count: response.headers['X-Total-Count'].to_i,
        link_header: response.headers['Link']
      }
    else
      nil
    end
  end
end

前端分页时，直接从缓存取总页数、总结果数，不用再碰API。

• 选择合适的缓存存储：开发环境用默认的内存缓存没问题，但生产环境强烈建议用Redis——内存缓存重启就会丢失数据，Redis支持持久化，还能处理更复杂的缓存操作。
• 按需缓存，避免预加载：不要为了“提前准备”就批量缓存所有分页数据，这样会浪费API调用次数。用户访问哪一页，就缓存哪一页，最经济高效。
• 灵活的缓存失效：如果对数据实时性要求高，可以监听Github的Webhook（比如仓库更新事件），触发对应关键词的缓存失效。不过这个复杂度较高，一般设置1-2小时的过期时间就足够大多数场景了。

• 一定要处理API错误：缓存未命中时，如果API调用失败（比如限额用完、网络问题），要返回友好的错误提示，不要让应用崩溃。
• 遵守Github API规则：即使有缓存，也不要恶意爬取数据，比如循环请求所有分页，这样可能会被封号。
• 用Octokit简化开发：如果不想自己写HTTP请求，可以用官方推荐的octokit.rb gem，它封装了很多Github API的细节，分页处理更便捷。

内容的提问来源于stack exchange，提问作者Bapta Arjun