Little Star

• 資深大佬 : Rwing

  哈哈哈 挺神奇的插件

• 主 資深大佬 : alian

  @Rwing (ﾟ▽ﾟ)/

• 資深大佬 : WittBulter

  Github 前段时间刚推出官方版本的 Star 管理页面….
  您有点惨… https://github.com/stars

• 資深大佬 : royliu

  仅管理 star 的话为啥需要这么权限啊？我看私有仓库都要授权读写？

• 資深大佬 : xrr2016

  看起来挺好的

• 資深大佬 : xrr2016

  @royliu 要权限确实挺多的

• 主 資深大佬 : alian

  @royliu 确实不需要，前期开发没注意都加了，我改一下

• 主 資深大佬 : alian

  @WittBulter Github 这个页面好像一直有，不过最近单独抽取出来？他这个满足不了我自己的需求哈

• 資深大佬 : Latin

  私有仓库还要授权…不敢用

• 主 資深大佬 : alian

  @Latin 失误失误，已经去掉了哈

• 資深大佬 : Latin

  @alian gist 私有代码也要权限

• 主 資深大佬 : alian

  @Latin 那个后期想做给用户做数据备份，写到 gist，所以保留了。

• 主 資深大佬 : alian

  @Latin 我也去掉吧，后期改成发邮件给用户备份

• 資深大佬 : xrr2016

  建议把内容框框调大点啊，上面的头像没必要那么大。

• 主 資深大佬 : alian

  感谢反馈，我后面看看怎么调整一下

• 主 資深大佬 : alian

  @xrr2016

• 資深大佬 : justin2018

  我看着感觉字好小~~ UI 界面挺好的

• 資深大佬 : xunco

  来个暗色主题，布局微调整下

• 主 資深大佬 : alian

  @justin2018 谢谢，字我也觉得小了，后期优化一下

• 主 資深大佬 : alian

  @xunco 暗色主题可以有
• 資深大佬 : imlinhanchao

  @alian 我觉得写到 gist 保留做同步可以有。不过可以作为一个可选项，可以选择私有或公有 Gist （可能有些人觉得自己的 Star 分类公开了也没啥事儿）或邮件（给不想公开也不想授权的用户的选择）。

• 主 資深大佬 : alian

  @imlinhanchao Github 的 gist 权限没有分公开和私有，权限说明是“gist：Grants write access to gists.”哈哈，不过后期增加备份功能确实可以考虑给用户两个选择，如果用户选择 gist 备份的话再重新登陆授权，感谢建议！

• 資深大佬 : iMusic

  管理 github star 是我的一个需求，去年也找了一些方案，最后选择在本地搭建 ASTRAL，不太方便。

  这个扩展看起来确实不错，最后希望能增加一个单独的管理页面展示

  

• 資深大佬 : imlinhanchao

  @alian 其实可以不用登录授权的方式，可以用 Access Token: https://github.com/settings/tokens 。这样用户可以自由开关授权。你就依据可用授权开放功能就好了。这样自由度更高一些。

• 主 資深大佬 : alian

  @iMusic 感谢支持，单独的管理页面在路上了

• 主 資深大佬 : alian

  @imlinhanchao 恩恩，因为用户基本信息展示的关系开始还是需要授权，用户前期不用自己去生成 token 会方便一点。之前没看到 Acces token，这个确实能给用户提供很多自由度，后期功能扩展的话可以考虑这种方式，感谢(･ω･)ﾉ

• 資深大佬 : Bakumon

  建议：画面大些，或者全屏，电脑屏幕稍大点，得去盯着右上角，不太方便

• 主 資深大佬 : alian

  @Bakumon 后面有弄一个独立页面的计划，到时就会大一些了，感谢建议！

• 資深大佬 : yulang

  哇哦一直在找这种工具，试试

• 資深大佬 : okampfer

  @iMusic #23
  如果把它 docker 化，在本地部署也是比较方便的。

• 資深大佬 : okampfer

  我跟 LZ 的想法差不多，曾经我也想搞个管理 github stars 的项目，可以无限添加分类和子分类。

  最初的尝试： https://github.com/athrunsun/too-many-stars （不用认真看了，烂尾）

  起初的想法是做成一个 serverless 的 app，部署在 github pages 上，用户可以登录，添加的分类信息用保存到 yaml 然后调用 github api 写回到指定 github repo 当中，下次登录时再读取。

  问题就在于这个同步，github api 中获取 starred repos 的接口： https://api.github.com/users/athrunsun/starred?page=1&per_page=30，每次请求大概 2 秒，我 star 的 repo 有 900 多个，那么就是 30 多页共 60 多秒左右。离我们最近的 github 服务器在新加坡，如遇网络不通畅，消耗时间会更长。如果 star 的 repo 数量有好几千，那同步时间恐怕是无法接受的。

  于是我又改变想法，做成 BS 结构，在类似 Azure Devops ( https://dev.azure.com)上跑一个 CI 可以从境外同步 star 的 repo 信息到某个地方，然后 B 端再从这个地方读取 star 的 repo 信息。但这种方式自己玩玩可以，要想推广让大家都用，部署、配置门槛太高，遂放弃。

  所以我最好奇的地方就是，Little Star 的同步耗时问题是怎么解决的呢？还是说这个问题在国内无解？

• 主 資深大佬 : alian

  @okampfer per_page 设置大一点，可以减少请求。Little star 的数据并不是每次都拉取的，初始化后存本地了，并且每次操作的时候本地和服务端都会同步更新，这样就避免多次请求。数据同步问题也是困扰了我很久

• 主 資深大佬 : alian

  @okampfer 国内的环境真的差，请求随时有挂掉的风险，所以需要有很多容错的机制。为了数据问题头发都掉了好多了，换了很多方案了，而目前我 3000 多个耗时 10 几秒左右，还是可以接受的。其中踩过的坑我们应该都是感同身受了哈哈哈