star-history源码阅读:Github的stargazers接口与分页机制

更新日期: 2024-05-23阅读: 7.7k标签: 源码

Github的stargazers接口

Github官方提供了一系列REST api(现在有向graphql上迁移的趋势),通过REST API,可以获得许多Github上的信息,以此为基础,我们可以构建各式各样的APP,star-history这个项目也是这样建立起来的

Github虽然没有提供直接查看项目star历史的功能,但是却提供了stargazers接口,这个接口有两种形式

  1. 查看star了一个项目的所有用户
  2. 同上,并且加入该用户star该项目的时间

这二者共用同一个rest url,不同的是:

方法2需要在HTTP请求头中加入Accept: application/vnd.github.v3.star+json

其rest url和返回的json格式分别是

GET /repos/:owner/:repo/stargazers
# 没有时间
[
{
"login": "octocat",
"id": 1,
"node_id": "MDQ6VXNlcjE=",
"avatar_url": "https://github.com/images/error/octocat_happy.gif",
"gravatar_id": "",
"url": "https://api.github.com/users/octocat",
"html_url": "https://github.com/octocat",
"followers_url": "https://api.github.com/users/octocat/followers",
"following_url": "https://api.github.com/users/octocat/following{/other_user}",
"gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
"starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
"subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
"organizations_url": "https://api.github.com/users/octocat/orgs",
"repos_url": "https://api.github.com/users/octocat/repos",
"events_url": "https://api.github.com/users/octocat/events{/privacy}",
"received_events_url": "https://api.github.com/users/octocat/received_events",
"type": "User",
"site_admin": false
}
]

GET /repos/:owner/:repo/stargazers
Header:
Accept: application/vnd.github.v3.star+json
# 有star时间
[
{
"starred_at": "2011-01-16T19:06:43Z",
"user": {
"login": "octocat",
"id": 1,
"node_id": "MDQ6VXNlcjE=",
"avatar_url": "https://github.com/images/error/octocat_happy.gif",
"gravatar_id": "",
"url": "https://api.github.com/users/octocat",
"html_url": "https://github.com/octocat",
"followers_url": "https://api.github.com/users/octocat/followers",
"following_url": "https://api.github.com/users/octocat/following{/other_user}",
"gists_url": "https://api.github.com/users/octocat/gists{/gist_id}",
"starred_url": "https://api.github.com/users/octocat/starred{/owner}{/repo}",
"subscriptions_url": "https://api.github.com/users/octocat/subscriptions",
"organizations_url": "https://api.github.com/users/octocat/orgs",
"repos_url": "https://api.github.com/users/octocat/repos",
"events_url": "https://api.github.com/users/octocat/events{/privacy}",
"received_events_url": "https://api.github.com/users/octocat/received_events",
"type": "User",
"site_admin": false
}
}
]


Github接口的分页策略

对于stargazers接口,一个仓库很可能有数万甚至数十万个用户star过,如果我们在一次请求
GET /repos/:owner/:repo/stargazers
中,就将所有的信息全部都拿出来,会导致:

  • 网络IO和内存IO负荷过大
  • 不灵活,也许有些接口调用方并不想要全部的数据,只想要部分的,这样的请求IO就全部浪费了

为此,Github的很多API都引入了分页机制

分页机制中,比较重要的有几点:

  • 如何知道一个url的资源被分成了多少页?
  • 如何知道目前是哪一页?
  • 如何知道一个url的资源在一页上有多少个?
  • 如何获取一个url任意一页的资源?

我们先来看看Github的REST API是如何接受和提供分页信息的

接受分页信息

对于每一个url,我们可以在后面加上page和per_page参数:

  • per_page参数指定了一页上有多少个资源
    • 这个参数可以没有,不同的url接口会有不同的默认值,有的是30,有的是100,具体靠阅读文档
    • 并不是所有的url接口都接受这个参数,有些url接口不接受,具体靠阅读文档
  • page参数指定了需要拿哪一页的资源


提供分页信息

在HTTP响应中,Github接口加入一个响应头Link,这个响应头的样式大概是

# 注意这个请求没有加上page参数,也能获得Link响应头
GET https://api.github.com/search/code?q=addClass+user%3Amozilla

# HTTP响应的响应头
Link: <https://api.github.com/search/code?q=addClass+user%3Amozilla&page=15>; rel="next",
<https://api.github.com/search/code?q=addClass+user%3Amozilla&page=34>; rel="last",
<https://api.github.com/search/code?q=addClass+user%3Amozilla&page=1>; rel="first",
<https://api.github.com/search/code?q=addClass+user%3Amozilla&page=13>; rel="prev"

其中rel表示的是url和当前url的关系:

  • prev,前一页的url
  • next,下一页的url
  • last,最后一页的url,也就是总页数
  • first,第一页的url

疑问的解答

所以我们之前的数个疑问就可以得到解答

  • 如何知道一个url的资源被分成了多少页?
    • 首先不带page参数进行请求,而后通过响应头,提取出last对应的url中的page参数即可
  • 如何知道目前是哪一页?
    • 当前url的page参数就是当前页数
    • 响应头中的next对应的url中的page参数是下一页
  • 如何知道一个url的资源在一页上有多少个?
    • 查看文档,会有默认值
    • 查看文档,如果url接口接受per_page参数,就可以自行设置(注意可能会有最大值限制)
  • 如何获取一个url任意一页的资源?
    • 加入page参数


获取star历史的思路

了解了Github的stargazers接口及分页策略,我们就可以来分析一下获取star历史的方法:

  1. 调用stargazers接口,要带star日期的
  2. 根据star日期进行排序
  3. 统计出star发生改变的时间(也就是某个用户star了仓库的时间)和当时的star数目(就是排序后的索引值)
  4. 以改变的时间作为横轴,改变当时的star数目作为纵轴,绘制图像

这样来看,基本上是没错的,但是还要考虑一点

如果一个仓库有数千数万数十万star,我们就要绘制数千数万数十万的点吗?

可以当然是可以的,但是这么做,对于高star的项目,内存和网络消耗过大,处理时间过长,项目初期,不利于我们开发和调试

所以我们可以利用分页机制进行取样

比如,我们选定取样点数为20,那么,

  • 对于star数目不足20的项目,
    • 我们获取所有的信息,并绘制出所有的点
  • 对于star数目高于20的项目(假设star数为N),
    • 我们获取0, N/20, 2N/20, 3N/20, …, N时的时间
    • 然后以这二十个时间点和star数,绘制20个点即可

上面描述的是如何取样,那么取样分页有什么关系呢?

那就是——我们不需要获取总star数目,我们只需要获取总页数

  • 对于一个stargazers接口页数为N的项目
    • 我们获取0, N/20, 2N/20, 3N/20, …, N页上最早的时间
    • 然后以这二十个时间点和star数(页编号 * 每页资源数目),绘制20个点即可


代码分析

事实上,项目代码中也是这么操作的(事实上刚才的思路是我从代码中倒推出来的,尬笑)

generateUrls.js中

const getConfig = {
headers: {
Accept: 'application/vnd.github.v3.star+json',
},
};

export default async function(repo) {
const initUrl = `https://api.github.com/repos/${repo}/stargazers`;
const res = await axios.get(initUrl, getConfig).catch(e => {
//...
})
//
}

这表明我们使用的是stargazers的带时间的接口

const link = res.headers.link;
if (!link) {
//...
} else {
const pageNumArray = /next.*?page=(\d*).*?last/.exec(link);
const pageNum = pageNumArray[1];
let samplePageUrls = [];
let pageIndexes = [];
if (pageNum <= sampleNum) {
for (let i = 2; i <= pageNum; i++) {
pageIndexes.push(i);
samplePageUrls.push(initUrl + '?page=' + i);
}
} else {
for (let i = 1; i < sampleNum; i++) {
let pageIndex = Math.round(i / sampleNum * pageNum);
pageIndexes.push(pageIndex);
samplePageUrls.push(initUrl + '?page=' + pageIndex);
}
}
//...
return {
samplePageUrls, pageIndexes,
};
}

显然这一段代码是通过响应头Link,使用正则表达式提取出总页数,然后取样sampleNum个点

getStarHistory.js中

export default async function(repo) {
const {samplePageUrls, pageIndexes} = await generateUrls(repo).catch(e => {
console.log(e); // throw don't work
});
const getArray = samplePageUrls.map(url => axios.get(url, getConfig));
const resArray = await Promise.all(getArray).catch(e => {
console.log(e); // throw don't work
});
const starHistory = pageIndexes.map((p, i) => {
return {
date: resArray[i].data[0].starred_at.slice(0, 10),
starNum: 30 * (p - 1),
};
});
console.log(starHistory);
return starHistory;
}

这一段代码

  1. 通过generateUrls.js的接口获取所有采样的url接口,而后进行请求
  2. 请求后获得每一页最小的时间,并把最小的时间和当页代表的star数组合起来返回

这样,就得到了一个项目的star历史

原文来自:https://blog.csdn.net/fitzleopard/article/details/106689640

链接: https://fly63.com/article/detial/12711

Js中的 forEach 源码

在日常 Coding 中,码农们肯定少不了对数组的操作,其中很常用的一个操作就是对数组进行遍历,查看数组中的元素,然后一顿操作猛如虎。今天暂且简单地说说在 JavaScript 中 forEach。

微信小程序代码源码案例大全

克隆项目代码到本地(git应该都要会哈,现在源码几乎都会放github上,会git才方便,不会的可以自学一下哦,不会的也没关系,gitHub上也提供直接下载的链接);打开微信开发者工具;

Node 集群源码初探

随着这些模块逐渐完善, Nodejs 在服务端的使用场景也越来越丰富,如果你仅仅是因为JS 这个后缀而注意到它的话, 那么我希望你能暂停脚步,好好了解一下这门年轻的语言,相信它会给你带来惊喜

Vue源码之实例方法

在 Vue 内部,有一段这样的代码:上面5个函数的作用是在Vue的原型上面挂载方法。initMixin 函数;可以看到在 initMixin 方法中,实现了一系列的初始化操作,包括生命周期流程以及响应式系统流程的启动

vue源码解析:nextTick

nextTick的使用:vue中dom的更像并不是实时的,当数据改变后,vue会把渲染watcher添加到异步队列,异步执行,同步代码执行完成后再统一修改dom,我们看下面的代码。

React源码解析之ReactDOM.render()

React更新的方式有三种:(1)ReactDOM.render() || hydrate(ReactDOMServer渲染)(2)setState(3)forceUpdate;接下来,我们就来看下ReactDOM.render()源码

React源码解析之ExpirationTime

在React中,为防止某个update因为优先级的原因一直被打断而未能执行。React会设置一个ExpirationTime,当时间到了ExpirationTime的时候,如果某个update还未执行的话,React将会强制执行该update,这就是ExpirationTime的作用。

扒开V8引擎的源码,我找到了你们想要的前端算法

算法对于前端工程师来说总有一层神秘色彩,这篇文章通过解读V8源码,带你探索 Array.prototype.sort 函数下的算法实现。来,先把你用过的和听说过的排序算法都列出来:

jQuery源码之extend的实现

extend是jQuery中一个比较核心的代码,如果有查看jQuery的源码的话,就会发现jQuery在多处调用了extend方法。作用:对任意对象进行扩;’扩展某个实例对象

vuex源码:state及strict属性

state也就是vuex里的值,也即是整个vuex的状态,而strict和state的设置有关,如果设置strict为true,那么不能直接修改state里的值,只能通过mutation来设置

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!