为何我选择用 Github issues 来写博客

对于爱写东西的人来讲，挑一个合适的博客平台是很是重要的。而做为一个 Web 开发者，咱们确定都但愿可以拥有一个高度定制化的博客平台，用以展现咱们独一无二的个性以及记录长久以来的学习工做等。与此同时，咱们也但愿这个平台可让咱们方便地发布内容，提供完整的点赞、留言等操做。在经历过 Hexo，Wordpress，自行搭建服务等一系列尝试之后，我最后选择了以 Github issues 来做为个人博客平台。

博客的基本能力

对于一个合格的博客平台来讲，它主要提供了下列几种能力：

1. 我的介绍 对于我的博客来讲，它首先要支持展现博主的我的介绍。这个我的介绍里面可能包括了头像、昵称、联系方式等基本内容，可以让读者可以对这个博客的主人有一个基本的认识。

2. 文章的撰写与展现 对一个博客来讲，最重要的就是它的内容，也就是里面的文章。一个好用的博客平台应该具有方便的撰写文章的能力，让够让用户毫无负担地撰写、编辑本身的文章。此外，还必须可以文章的信息，好比展现标题、节选、封面，建立/修改时间，评论点赞数等等。

3. 归档能力 一篇文章的撰写时间、内容标签/分类等都是不一样的，如何按照不一样的要求对这些文章进行归档整理，也是考验博客平台的能力之一。再者，当文章数量较多的时候，添加一个搜索的功能也能大大方便读者对博客的浏览。

4. 博主与读者互动的能力 仅仅只有博主一我的自嗨可能难以激发写做的动力，若是博客可以提供博主与读者互动的能力，将能有效激励博主持续创做，更能提高文章的传播度——点赞和评论功能则是互动能力中最重要的功能之一。

通过上面的几个点，基本能够知道一个博客平台，其主要功能就是“展现本身，沟通外界”。在知足这个基础的前提下，它也应该具有方便操做，高度定制化的特色。

为何不选择其余方案

在文章的开头我有提到，我曾经尝试过用 Wordpress，Hexo，自行搭建服务等途径去尝试维护博客。但这些尝试的结果均不合我意，最后无疾而终。归根结底，就是不够自由和方便。

举个例子，Wordpress 和 Hexo 都具有搭建一个主题漂亮、功能齐全的博客的能力，可是这些都必需要在它们所制定的规则下进行。若是我想 DIY 一个主题，或者加入任何我想要的新能力，都必须仔细翻阅它们的文档，找到对应的规则再尝试去实现，可谓是戴着镣铐跳舞。除此以外，要发布新的文章，动辄就要在本地跑命令行，实在是很是不优雅。更有甚者，若是但愿为文章添加评论功能，还要费一大番周折，想必体验过的人都懂。

至于自行搭建服务，可谓是既自由又方便，想要任何功能均可以本身实现。但这种方案最大的缺点是成本较高。对于人力成原本说，服务器数据库配置、域名、备案等一系列操做很是烦人，甚至还要考虑告警、负载、宕机等一堆的运维问题。折腾多了，也没什么心思往里面写文章。对于金钱成原本说，买域名，买服务器也是一笔花销，尤为是当咱们某段时间文章产出特别少的时候，总以为白养了一台服务器……

选择 Github issues

首先是 Github，而后才是 issues。

做为全球最大的代码托管平台，又刚刚被微软收入麾下，其可靠程度是很是高的，基本不用担忧存放在里面的数据会丢失（想一想看国内说没就没的网易博客，百度贴吧等）。

在 Github 上咱们能够精心编辑本身的帐户信息，包括头像、昵称、邮箱、工做单位等等。

Github issues 提供了很是方便快捷的编辑能力，尤为是贴图。它支持经过拖拽、粘贴、选择的方式上传图片，图片会存放在 user-images.githubusercontent.com 这个地方，且支持外链——这也意味着咱们能够很方便地把 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） api.github.com/user

• 获取仓库的 issues 列表（GET） api.github.com/repos/:owne…

• 获取某条 issue 的评论列表（GET） api.github.com/repos/:owne…

• 获取某条 issue 的点赞和红心等 reactions （GET） api.github.com/repos/:owne…

• 为某条 issue 提交一条评论（POST） api.github.com/repos/:owne…

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

• 为某条 issue 添加一条 reaction（POST） api.github.com/repos/:owne…

  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 的我的博客也已经上线，欢迎前来体验：

jrainlau.github.io/#/

若是你也以为不错的话，赶快给本身也搭一个基于 Github issues 的博客吧，期待与你的交流！