关于爱写东西的人来讲，挑一个适宜的博客平台是异常主要的。而作为一个 Web 开辟者，我们肯建都愿望能够具有一个高度定制化的博客平台，用以展现我们举世无双的特性以及纪录长久以来的进修事情等。与此同时，我们也愿望这个平台能够让我们轻易地宣布内容，供应完整的点赞、留言等操纵。在经历过 Hexo，Wordpress，自行搭建效劳等一系列尝试今后，我末了挑选了以 Github issues 来作为我的博客平台。

博客的基本才能

关于一个及格的博客平台来讲，它主要供应了以下几种才能：

1. 个人引见
   关于个人博客来讲，它首先要支撑展现博主的个人引见。这个个人引见内里能够包含了头像、昵称、联系体式格局等基本内容，能够让读者能够对这个博客的主人有一个基本的熟悉。
2. 文章的撰写与展现
   对一个博客来讲，最主要的就是它的内容，也就是内里的文章。一个好用的博客平台应当具有轻易的撰写文章的才能，让够让用户毫无累赘地撰写、编辑本身的文章。另外，还必须能够文章的信息，比方展现题目、节选、封面，建立/修正时刻，批评点赞数等等。
3. 归档才能
   一篇文章的撰写时刻、内容标签/分类等都是差别的，怎样根据差别的请求对这些文章举行归档整顿，也是磨练博客平台的才能之一。再者，当文章数目较多的时刻，增加一个搜刮的功用也能大大轻易读者对博客的阅读。
4. 博主与读者互动的才能
   仅仅只要博主一个人自嗨能够难以引发写作的动力，假如博客能够供应博主与读者互动的才能，将能有用鼓励博主延续创作，更能提拔文章的流传度——点赞和批评功用则是互动才能中最主要的功用之一。

经由上面的几个点，基本能够晓得一个博客平台，其主要功用就是“展现本身，沟通外界”。在满足这个基本的前提下，它也应当具有轻易操纵，高度定制化的特性。

为何不挑选其他计划

在文章的开首我有提到，我曾尝试过用 WordPress，Hexo，自行搭建效劳等门路去尝试保护博客。但这些尝试的效果均分歧我意，末了无疾而终。归根结柢，就是不够自在和轻易。

举个例子，Wordpress 和 Hexo 都具有搭建一个主题美丽、功用完整的博客的才能，然则这些都必须要在它们所制订的划定规矩下举行。假如我想 DIY 一个主题，或许到场任何我想要的新才能，都必须细致翻阅它们的文档，找到对应的划定规矩再尝试去完成，可谓是戴着枷锁舞蹈。除此之外，要宣布新的文章，动辄就要在当地跑命令行，实在是异常不文雅。更有甚者，假如愿望为文章增加批评功用，还要费一大番周折，想必体验过的人都懂。

至于自行搭建效劳，可谓是既自在又轻易，想要任何功用都能够本身完成。但这类计划最大的瑕玷是本钱较高。关于人力本钱来讲，效劳器数据库设置、域名、备案等一系列操纵异常烦人，以至还要斟酌告警、负载、宕机等一堆的运维题目。折腾多了，也没什么心机往内里写文章。关于款项本钱来讲，买域名，买效劳器也是一笔花消，尤其是当我们某段时刻文章产出迥殊少的时刻，总以为白养了一台效劳器……

挑选 Github issues

首先是 Github，然后才是 issues。

作为环球最大的代码托管平台，又刚刚被微软收入麾下，其牢靠水平是异常高的，基本不必忧郁寄存在内里的数据会丧失（想想看国内说没就没的网易博客，百度贴吧等）。

在 Github 上我们能够经心编辑本身的账户信息，包含头像、昵称、邮箱、事情单位等等。

Github issues 供应了异常轻易快捷的编辑才能，尤其是贴图。它支撑经由过程拖拽、粘贴、挑选的体式格局上传图片，图片会寄存在 https://user-images.githubuse… 这个处所，且支撑外链——这也意味着我们能够很轻易地把 issue 的内容转载到其他的平台。

在 Github issues 内里，能够为某条 issue 增加点赞、爱心等互动标签（Reactions），也能够设置分类标签（Labels），更能够给 issue 增加批评（Comment）。

最为主要的是 Github 供应了一套满足了绝大部分需求的 API，席卷了 REST 和 GraphQL 的挪用体式格局，这才是 Github 能够成为我们博客平台的大杀器，这个接下来会细致申明。

不难看出，Github issues 具有着前文说起的一个博客平台所应具有的种种才能。接下来我们将以 Github issues 作为博客平台的治理后端，以 API 来完成和客户端的数据交互。

生成的前后端星散

关于 Github API 的受权和调试，能够查阅我的另一篇文章
《基于 Github API 的图床 Chrome 插件开辟全纪录》。

我们运用 Github issues 作为博客平台，也就是相当于治理后端。我们在治理后端内里撰写文章，设置标签，复兴批评，然后经由过程 API 挪用把数据传送给客户端。

几个比较经常使用的 v3 API 以下：

• 猎取登录用户信息（GET）
  https://api.github.com/user
• 猎取堆栈的 issues 列表（GET）
  https://api.github.com/repos/:owner/:repo/issues
• 猎取某条 issue 的批评列表（GET）
  https://api.github.com/repos/:owner/:repo/issues/:issue_number/comments
• 猎取某条 issue 的点赞和红心等 reactions （GET）
  https://api.github.com/repos/:owner/:repo/issues/:issue_number/reactions

• 为某条 issue 提交一条批评（POST）
  https://api.github.com/repos/:owner/:repo/issues/:issue_number/comments

  Name	Type	Description
  body	string	Required. The contents of the comment.

• 为某条 issue 增加一条 reaction（POST）
  https://api.github.com/repos/:owner/:repo/issues/:issue_number/reactions

  Name	Type	Description
  content	string	Required. The reaction type to add to the issue.

固然你也能够运用 v4 的 GraphQL 接口，也是异常的轻易，感兴趣的能够自行研讨。

治理后端直接用现成的 Github issues 页面，那末客户端则运用 Github 为开辟者免费供应的静态页面布置效劳 Github pages。要运用这个效劳，只需要开通一个堆栈，然后在堆栈的 Settings 内里找到 Github pages 并翻开即可，默许会以 Master 分支的根目次作为静态资本目次，我们只需要把客户端的静态资本直接安排在这里就好。

开通了 Github pages 今后，便能够经由过程其供应的 URL 直接在阅读器里访问到博客了，而博客的数据则完整加载自 Github API。

经由过程已受权的接口，还许可提交批评等功用：

结语

总结一下，Github issues 供应了一个博客平台所需的的各项基本才能，与 Github 的牢靠性， API 的全面性，Github pages 的便利性连系在一起，都异常合适作为一个博客平台来运用。我基于 Github issues 的个人博客也已上线，迎接前来体验：

https://jrainlau.github.io/#/

假如你也以为不错的话，连忙给本身也搭一个基于 Github issues 的博客吧，期待与你的交换！